back

by lerno·1y ago·view on hn ↗
The temp allocator is a stack allocator, so it's a bit more flexible than that and can be used for return values or even more long lived allocations. It doesn't use the standard heap allocator to alloc, so there is a potential win in speed and cache coherence as well.

For scoping files, sockets and so on, there's actually a simple mechanism in C3 that allows creating code like that very easily using macros with "trailing body". Which is a little like trailing closures in Swift, but here there is no closure, just a macro.

There is an example here: https://c3-lang.org/generic-programming/macros/#trailing-blo... but it's used in the stdlib quite a lot.

1 comments
The temp allocator is a stack allocator,

How much have you used that? C has that and it will get cleared at the end of a scope too, but it is pretty exotic because it is so fragile. It's a catch-22, if something is so big that you need to allocate the exact size to save stack space, then it could become problematic and blow the stack. This is not a substitute for having allocations be freed at the end of a scope.

For scoping files, sockets and so on, there's actually a simple mechanism in C3 that allows creating code like that very easily using macros with "trailing body". Which is a little like trailing closures in Swift, but here there is no closure, just a macro.

I think stuff like this is interesting, but it's interesting in the context of straight C, not in the context of a new language where it could be done better.

In regular C you could already create a custom allocator and macros that would use the fact that a for loop will run something after the scope finishes to mimic some of these effects.

C's syntax may be a little funky, but it's real pain point is the actual semantics that will bite people over and over until they move on.

No, not alloca, I mean a stack allocator as you push / pop memory scopes.

The trailing body macro is something I think you should try out before dismissing it. It's similar to how Ruby can do it, with the closures exiting the "outer scope", which is unusual.

You keep saying "stack allocator" but you haven't been specific and said if you mean allocating on the stack or allocating on the heap and freeing memory based on the stack.

I'm not dismissing the trailing body macro approach, I just don't see what advantage it has over destructors which is a well worn solution. It seems like some of the design decisions are based off of 'don't do something that C++ does'

A stack allocator is an allocator that aside from allocate, has a push and a pop function. Image an arena allocator (aka bump allocator), where ”push” stores the current start of free memory, and ”pop” resets to this point, erasing all allocations between push and pop. This is a stack allocator.

It is similar to the function stack, but push and pop can be arbitrarily granular, as opposed to only happening at entry/exit.