[Gc] C++ API enhancement proposal

skaller skaller at users.sourceforge.net
Fri May 11 00:34:36 PDT 2007

On Fri, 2007-05-11 at 08:48 +0200, Christophe Meessen wrote:

> add in gc_cpp.cpp
>    struct GC_initializer { GC_init_struct() { GC_INIT(); } }
>    GC_initializer gc_initializer;
> Note: it won't completely eliminate the problem of global instance
> initialization alloacting blocks because we can't ensure libgc is
> initialized first. 

Yes, and it's a bad idea for that reason. It's important
to delegate the responsibility to the programmer BECAUSE
there is no safe automatic solution.

With static linkage, on most linkers, the first linked
object file is initialised first, so you actually want
a special object file (NOT the whole library archive)
to manually put in your linker command line.

With load time linkage, I'm not sure. Elf probably has
a way to ensure a certain section is initialised before
others, even if there is dynamic linkage (but I don't
honestly know enough about how it decides on link/initialisation
order in this case).

> Better than nothing, in wait of gc support in C++.

C++ will never have gc support: C++ isn't compatible
with garbage collection.

Bjarne tried to get this into the first version of the
Standard, but wasn't able to come up with a satisfactory
proposal. This is not surprising, there simply isn't one.

The problem, roughly is: C++ program is mandated to have
certain semantics in the absence of a collector. If the language
had mandatory collection, it would be a different language.

This actually might work, but it wouldn't be C++ anymore:
an implementation without a collector wouldn't be conforming.

So we're left with optional collection, and that also cannot
be allowed to have any definite semantics because it is
optional. Roughly speaking, the collector would be allowed
to free garbage memory, and nothing more: this wouldn't
change semantics, so much as prevent out-of-memory terminating
a program.

The other alternative is mandatory non-transparent collection,
that is, where the programmer specifies what is collectable.

Such a language already exists and it is already ECMA Standardised.
Microsoft calls it Managed C++, I don't know the official ECMA
designation off hand.

The bottom line is: if you can't write C++ without needing
a garbage collector, start using a decent programming language
like Ocaml, SML (Mlton), Haskell, if you're hooked on OO stuff
try D, and if you're desperate for C++ compatibility, Felix.
If you're in the MS camp, just use C# of F#.

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.

There's much more hope for C+gc to be a viable system than C+++gc.

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

More information about the Gc mailing list