[Gc] C++ API enhancement proposal

skaller skaller at users.sourceforge.net
Fri May 11 10:39:07 PDT 2007

On Fri, 2007-05-11 at 10:42 +0200, Christophe Meessen wrote:
> skaller a écrit :

> > C++ will never have gc support: C++ isn't compatible
> > with garbage collection.
> >   
> With supporting gc, compilers can ensure the gc is initialized before 
> starting to instantitate global variables. They can also ensure 
> optimizations won't break garbage collection. 

Yes, of course, I didn't mean a compiler couldn't support gc:
I meant that the C++ Standard can't.

>  But there exists 
> use cases where a gc is required. 

Apart from leaky code, I don't see how this is possible.
More precisely, I mean 'conservative gc', since clearly
managing circular data structures requires some kind of

> This is what I am facing and the 
> reason why I'm trying to get it running properly for my application. I 
> would save the dependency to this third party library if it was possible.

The problem with Boehm gc .. IMHO .. is that it is very hard
to get working properly. It is sensitive to low level architectural
details of the OS, linker/loader and compiler.

EG: malloc isn't the only way to allocate memory; on Posix
you can play with mmap().

> > Just don't wait for C++ to get 'garbage collection': C++ is
> > a crap language already, it can't be fixed by adding a collector.
> > Far too much C++ is dependent on RAII which isn't compatible for
> > current collector technology.
> I don't agree on this. This is just a matter of code design and as long 
> as user is in control of what class and data is collectable and /or 
> inspected  the user can pick the best of both worlds. 

I do not dispute what you say, but my point regards not
using C++ with a gc, but *standardising* use of an
optional, transparent, gc.

You can certainly write code designed for a gc, submit
it to say g++, and get a nice program -- but your code
is not really conforming C++ any more, because you're
not destroying unused objects in an orderly manner.
Freeing the memory without running the destructor isn't allowed
(failing to free it is, but then you run out of address space
and/or memory eventually)

This can certainly work if you code to take it into
account, for example you can make a singly linked list
and not bother with a destructor which frees the tail
of the list, knowing the collector will do it.

> This would make 
> c++ with gc support more versatile to other existing languages with gc 
> support built in. It will add some complexity to C++ programming because 
> users will have to determine if they need gc or not and where. But this 
> is also true for many other features of C++.

Felix does this already, as does MS 'managed' C++.

BTW: the evidence is 100% exact gc is better than all
other methods, including any hybrid of gc and manual
storage management.

It's likely 100% automatic conservative gc (no deletion
by the user allowed) is also actually more efficient
than other methods.

That is, if you're going to use a gc .. you should probably
completely eliminate all code that attempts to manage
memory, as it is unreliable and more likely to slow the
program down than help.

The caveat in C/C++ of course is that you have to 'delete'
objects by NULLing (at least some) pointers when using a gc
to ensure objects become unreachable, whereas in non-gc C and
C++ there's no need for that (and it will slow the program

Boehm works well for things like Neko, which is a bytecode
interpreter written in C. The C bindings provided take
care to be nice to the gc, and the onus is on the programmer
to do the same if they're going to add C bindings to the system.
Once the basic VM is got running with the gc, the bytecode
will be sure to work properly.

The true hassle with C/C++ is that the whole point of using
such lame language is that there are lots of ready built libraries
available .. and the problem using THEM with Boehm is that you don't
have control over whether they're gc friendly or not.

John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: https://felix.sf.net

More information about the Gc mailing list