C³: Comments on Memory Management

I just got wind that someone else in this world is attempting to create another “better C++” language: C³. It’s still vapourware¹ at this point. What’s special is that I know who is c3wife. And here is a reply to c3wife’s post about the value of values.

It’s true that garbage collectors don’t solve all problems, but I think you’re a little too rash about them. I don’t know a serious garbage collector which isn’t capable of handling cyclic references correctly. Some are totally non-blocking and can run on a separate thread, but require atomic operations and being notified of changes to pointer values (like the one in Apple’s Objective-C 2.0). Some garbage collectors can defragment memory by relocating memory blocks and adjusting pointers that point to them (like the one in Sun’s JVM). Some don’t run until you try to allocate memory (like the one in D), which makes it no more unpredictable than calling malloc that itself offers no guaranty about speed.

And a garbage collected program in some cases can outperform one using RAII: since you postpone calling destructors and freeing memory when you no longer need it, you finish the task faster, and only then the garbage collector kicks in. Note however that you can still mimic that with RAII by having a destructor placing memory on a garbage stack which is to be handled later, something à la NSAutoreleasePool.

I agree that RAII is a very good thing in C++, and surely something to keep since there are many situations where a garbage collector is inappropriate. For anything that holds a resource other than memory (file handle, transaction, mutex lock, etc.), you generally can’t wait for the garbage collector to catch up. And if you do some real-time programing, you don’t want the GC to interfere at random times.

And it’s also true that a garbage collector doesn’t entirely protect against memory leaks, but it has nothing to do with cyclic references (except for poor ones based on reference counting). It has to do with keeping unnecessary references where you shouldn’t (in a global list for instance), or, for conservative garbage collectors, having some pointer-like data which isn’t really a pointer.

So I’d say the best of both worlds is to have the two memory management techniques at our disposal.

The page about garbage collection on Wikipedia is full of interesting details on that subject.

Forcing all pointers to be smart pointers expressing ownership and copy behaviour is a good move. Plain old C pointers are an abomination in C++, and I use them only scarcely when writing C++.

The only downside is that it can easily explode in a dozen of different pointer types. But I think that’s still better than having one type with ambiguous or wrong semantics.

One thing I’m wondering: are pointer to stack variables allowed? And in that case, is there any provision to ensure the pointer doesn’t outlive the stack frame?

And good luck developing C³.