Item — HN Reader

Personally I think it is reasonable that a C alternative is an alternative to C, and not a C++ alternative. C3 uses a temp allocator that removes a large number of cases where C++ would need RAII to manage memory. Did you try C3?

1 comments

Does it just deallocate at the end of a scope? Why go halfway? It's obviously valuable and destructors are not complicated. Destructors can also close files, sockets, deallocate buffers from the GPU, etc.

I think when people want C semantics they will just use C in general, but if there is something that solves these extreme pain points in a simple way it might be enough to get someone to switch.

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.

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.

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.

Yes the temp allocator will remove things at the end of it's scope. It makes it very clear when memory will be affected and gives predictable code execution.

There are other contexts for managing mutex locks so they auto close and you could dream up one for database connections and transactions too.

The nice things about a context is you can always see it's there, destructors by design are a bit hidden which can make code harder to reason about.

Destructors take care of all these situations and because they are hidden and run automatically at the end of a scope you don't forget them or mess them up.

I have never heard anyone say they are hard to reason about, especially if there is no garbage collection or inheritance.