4 ms·

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 oth

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.

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.