3 ms·

RAII is all about making the compiler do what the "disciplined" C code is already doing manually. As mentioned elsewhere in this thread, a common C coding style

RAII is all about making the compiler do what the "disciplined" C code is already doing manually. As mentioned elsewhere in this thread, a common C coding style and idiom is to goto to the end of your scope, where all the free calls go. The resulting behavior is pretty close to RAII. The argument in favor of RAII is that it's a lot less error prone to let the compiler write that part for you. A fine goal of course, but I feel like this post is overstating it or perhaps conflating it with something else (eg. The aside about trying to convince the GPU API maintainer that the issues they hit are also affecting drivers written in C may have little or nothing to do with rust or RAII)

flohofwoe 2y ago
The problem is that since cleanup with RAII is so 'simple', you tend to forget about it, and then you're suddenly in a situation where destroying a single object results in a cascade of thousands of other tiny destructions. So now you actually need to think about a proper memory management strategy (even though you have automatic memory management) and will eventually arrive at arenas as the solution, and once you're there, suddenly RAII doesn't look so essential anymore (if you only have a handful of arena lifetimes to track instead of thousands of individual object lifetimes, manual memory management becomes trivial too). E.g. just as with garbage collection, RAII is a solution to a problem that shouldn't exist in the first place (having to track the individual lifetimes of thousands of tiny individual objects with complex interdependencies). When I switched from 'mainly C++' back to 'mainly C' about 8 years ago, I *did* think that I would miss RAII the most, turns out it was a non-issue (the main thing is to stop thinking about programs as individual objects interacting with each other).
- imtringued 2y ago
  I'm sorry, but I'm not really seeing it. How is that different from calling <struct_name>_free(<struct_name> *p)? That can trigger a cascade of thousands of other tiny destructions. There is no difference. The only argument I see against RAII is that a kernel would be better off with explicit drop() calls, but that is about it. >E.g. just as with garbage collection, RAII is a solution to a problem that shouldn't exist in the first place (having to track the individual lifetimes of thousands of tiny individual objects with complex interdependencies). Okay, but I sure hope you are aware that this is a fringe opinion shared by very few people. The people who need to track the individual lifetimes of thousands of tiny individual objects with complex interdependencies do in fact need that "power". E.g. the average webapp or webserver and C is a non-starter for anything that is internet connected. If I were to switch to C, the thing I would miss the most is the absence of antagonistic compilers.
  - flohofwoe 2y ago
    > How is that different from calling <struct_name>_free(<struct_name> *p)? That can trigger a cascade of thousands of other tiny destructions. You don't call 'struct_free(obj)' (there isn't even such a function), instead you call 'arena_reset(arena)' once. Stop thinking about individual object lifetimes, start thinking about arenas as 'lifetime buckets' :) > I sure hope you are aware that this is a fringe opinion shared by very few people It's really not a fringe opinion in areas of the industry where performance matters (like video game development).
    - SuperV1234 2y ago
      > You don't call 'struct_free(obj)' (there isn't even such a function), instead you call 'arena_reset(arena)' once. Stop thinking about individual object lifetimes, start thinking about arenas as 'lifetime buckets' :) Yes, so you can use RAII for the arena if needed. The problem is not RAII itself, is where it is applied. And having a manual "arena_reset" function instead of a RAII-based "Arena" abstraction is objectively inferior as anyone could forget to call "arena_reset" while RAII would enforce the clean-up.
    - asveikau 2y ago
      That depends heavily on what you're working with. If it's POD types then ok. But a lot of things fit into the destructor paradigm. Note it's not just memory. The R in RAII is for resource, not memory.
- UncleMeat 2y ago
  You can detect this case with profiling or other tools and then adjust it when appropriate. Having a less error-prone solution for the common case and then doing something else when necessary is a great approach to software design so long as you don't run into the "something else" too often that you end up with two common idioms rather than one common idiom and some clear exceptions.
- SuperV1234 2y ago
  > RAII is a solution to a problem that shouldn't exist in the first place (having to track the individual lifetimes of thousands of tiny individual objects with complex interdependencies) That's not what RAII is at all. You're projecting an extreme use case on the whole feature. You can use RAII to clean-up the arena at once without forgetting to do so. To manage the lifetime of a socket or mutex. No one is forcing you to go full-OOP individual-allocation design when RAII is available, that's just terrible programming in general.
- KerrAvon 2y ago
  This isn't an inherent problem with RAII; it's a design/architecture problem. Not every object needs a destructor; if free() is a bottleneck, you have other serious problems that you need to address. Also, arena-type approaches aren't free; you can run into serious safety problems with a large object graph, because the pointers _will_ escape containment and become stale and you won't realize it.

flohofwoe 2y ago

The problem is that since cleanup with RAII is so 'simple', you tend to forget about it, and then you're suddenly in a situation where destroying a single object results in a cascade of thousands of other tiny destructions. So now you actually need to think about a proper memory management strategy (even though you have automatic memory management) and will eventually arrive at arenas as the solution, and once you're there, suddenly RAII doesn't look so essential anymore (if you only have a handful of arena lifetimes to track instead of thousands of individual object lifetimes, manual memory management becomes trivial too). E.g. just as with garbage collection, RAII is a solution to a problem that shouldn't exist in the first place (having to track the individual lifetimes of thousands of tiny individual objects with complex interdependencies). When I switched from 'mainly C++' back to 'mainly C' about 8 years ago, I *did* think that I would miss RAII the most, turns out it was a non-issue (the main thing is to stop thinking about programs as individual objects interacting with each other).

imtringued 2y ago
I'm sorry, but I'm not really seeing it. How is that different from calling <struct_name>_free(<struct_name> *p)? That can trigger a cascade of thousands of other tiny destructions. There is no difference. The only argument I see against RAII is that a kernel would be better off with explicit drop() calls, but that is about it. >E.g. just as with garbage collection, RAII is a solution to a problem that shouldn't exist in the first place (having to track the individual lifetimes of thousands of tiny individual objects with complex interdependencies). Okay, but I sure hope you are aware that this is a fringe opinion shared by very few people. The people who need to track the individual lifetimes of thousands of tiny individual objects with complex interdependencies do in fact need that "power". E.g. the average webapp or webserver and C is a non-starter for anything that is internet connected. If I were to switch to C, the thing I would miss the most is the absence of antagonistic compilers.
- flohofwoe 2y ago
  > How is that different from calling <struct_name>_free(<struct_name> *p)? That can trigger a cascade of thousands of other tiny destructions. You don't call 'struct_free(obj)' (there isn't even such a function), instead you call 'arena_reset(arena)' once. Stop thinking about individual object lifetimes, start thinking about arenas as 'lifetime buckets' :) > I sure hope you are aware that this is a fringe opinion shared by very few people It's really not a fringe opinion in areas of the industry where performance matters (like video game development).
  - SuperV1234 2y ago
    > You don't call 'struct_free(obj)' (there isn't even such a function), instead you call 'arena_reset(arena)' once. Stop thinking about individual object lifetimes, start thinking about arenas as 'lifetime buckets' :) Yes, so you can use RAII for the arena if needed. The problem is not RAII itself, is where it is applied. And having a manual "arena_reset" function instead of a RAII-based "Arena" abstraction is objectively inferior as anyone could forget to call "arena_reset" while RAII would enforce the clean-up.
  - asveikau 2y ago
    That depends heavily on what you're working with. If it's POD types then ok. But a lot of things fit into the destructor paradigm. Note it's not just memory. The R in RAII is for resource, not memory.
UncleMeat 2y ago
You can detect this case with profiling or other tools and then adjust it when appropriate. Having a less error-prone solution for the common case and then doing something else when necessary is a great approach to software design so long as you don't run into the "something else" too often that you end up with two common idioms rather than one common idiom and some clear exceptions.
SuperV1234 2y ago
> RAII is a solution to a problem that shouldn't exist in the first place (having to track the individual lifetimes of thousands of tiny individual objects with complex interdependencies) That's not what RAII is at all. You're projecting an extreme use case on the whole feature. You can use RAII to clean-up the arena at once without forgetting to do so. To manage the lifetime of a socket or mutex. No one is forcing you to go full-OOP individual-allocation design when RAII is available, that's just terrible programming in general.
KerrAvon 2y ago
This isn't an inherent problem with RAII; it's a design/architecture problem. Not every object needs a destructor; if free() is a bottleneck, you have other serious problems that you need to address. Also, arena-type approaches aren't free; you can run into serious safety problems with a large object graph, because the pointers _will_ escape containment and become stale and you won't realize it.