[Gc] C++ API enhancement proposal

skaller skaller at users.sourceforge.net
Fri May 11 11:18:32 PDT 2007


On Fri, 2007-05-11 at 17:33 +0000, Boehm, Hans wrote:
> > From: g skaller

> > 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.
> > 
> This is certainly still being hotly debated in the C++ standards
> committee.  The most recent proposal is at
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2287.pdf .  The
> committee earlier approved a registration draft that proposes to add it.

That's an interesting design, though it isn't optional transparent
collection, but instead provides support for a hybrid gc/nogc
mixture.

I think it is dangerous: the right solution is to abandon C++.
What I suspect will happen is that people will start using
the collectable stuff -- but it won't work properly because
of external libraries, dynamic loading, and other such considerations.

C++ has the same kind of problem with threads and exceptions,
and with dynamic loading/unloading and initialisation/finalisation
order: the Standard avoids these problems by not mentioning
either of these commonly use facilities.

If they and/or gc are standardised it restricts even more
the working context, and locks people even more into what
is basically archaic and poorly designed technology,
when people should be moving away from it to more modern
systems.

Apart from education .. the biggest impediment to using
these systems is the lack of libraries and difficulty
of binding to C/C++ libraries. We really don't want even
more legacy code created! Rather, re-implement the code
in the new languages.

Whilst C/C++ holds the mainstream, especially in the Unix
systems programming area, Microsoft .NET will streak ahead
as an application environment, and Linux will drop further
and further behind .. not that I can actually recommend a
replacement, mind you (it certainly isn't Java).

BTW: you might look at how Felix does this. The call for gc object
construction is:

	new (gc, shape<X>) X(args)


Here 'gc' is the collector, and 'shape<X>' is the data needed by the
collector to find the pointers in an X. Clearly in your proposal,
this information is synthesised by the compiler for an exact collector,
or simply not necessary for a conservative one.

Felix requires the managing collector to be passed, since it
mandates re-entrant code, so the collector isn't allowed to
be implicit. Nested (precise) collectors make sense for some
data structures. I'm not sure if this can be automated
based on type analysis.

Felix also has variable length arrays (the maximum length is fixed).
These can't be created by a C++ constructor. They created at zero
length like an STL vector, and then you can push values onto the end.

The allocator needs to know the maximum length for deallocation
purposes, but the collector needs to know the used length
for scanning and finalisation -- so two counts are required.

BTW2: to illustrate my point above -- needing to bind to existing
non-gc-collected code is already a severe constraint on Felix.
I have toyed with extending the collector to a more advanced
copying collector, but C++ requirements keep getting in the way.

If you add gc to C++ as in the proposal it will become completely
untenable, since I'd be running a collector AS WELL as the C++
system collector: add a collector to C++ *in the standard* and
it kills off any chance of generating C++ which binds to other
C++ which might use the standardised gc.

This is one of the reasons C never got threads. The committee
argued that it would restrict thread implementations too much.
The same applies to collectors.


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


More information about the Gc mailing list