Comment by ltbarcly3
6 months ago
This literally doesn't solve any actual problems. If all memory allocation patterns were lexical this is the most easy and most obvious thing to do. That is why stack allocation is the default and works exactly like this.
Imagine we have a function "foo" which returns an allocated object Bar, we want to pass this to a function "bar" and then have it released.
Now we usually cannot do "bar(foo())" because it then leaks. We could allocate a buffer on the stack, and then do "bar(foo(&buffer))", but this relies on us safely knowing that the buffer does not overflow.
If the language has RAII, we can use that to return an object which will release itself after going out of scope e.g. std::unique_ptr, but this relies on said RAII and preferably move semantics.
If the context is RAII-less semantics, this is not trivial to solve. Languages that run into this is C3, Zig, C and Odin.
With the temp allocator solution, we can write `bar(foo())` if `foo` always allocates a temp variable, or `bar(foo(tmem))` if it takes an allocator.
Wait, you are implying this is some kind of algorithmic 'solution' to a long standing problem. It's not. This is notable because it's an implementation that works in C++. The 'concept' of tracking allocations in a lexical way is trivially obvious.
It is a problem for manual memory management. I am not quite sure where you're coming from. In Modern C++ this is managed by RAII, but if you instead look at C there is no solution that doesn't involve various additional code.
You seem the same in "C alternatives" such as Zig.
But obviously if you're coming from a language which already has some form of automatic memory management it won't seem like a big thing.
But in the context of manual memory management it is solving a very real problem.
1 reply →
Well, it solves the problem of destructors/deallocation wasting a lot of time.
You still have to call the destructor.
What destructor?