dak <pierreba@poster.cae.ca> wrote:

> > { Strictly speaking, Bjarne (rightly, IMO), isn't keen on *any* feature
> >   that has a size/space overhead WHEN IT IS NOT USED. GC algos are very
> >   clever today, but there *is* an overhead.

I am puzzled by this. Could someone please explain to me what this
overhead is? "When it is not used" would mean manually delete objects
from the free store, stack based objects etc...

> >   I think BS really wants GC to be
> >   standardised in a ANSI/ISO C++ *revision*, so it gets standardised,
> >   but doesn't hold up the ship, or is manditory for a ANSI C++ compiler.
> >   See "The Design and evolution of C++" -mod }
>
> First, GC and non-GC modules can be intermixed. It's easy to have the
> delete calls mark the objects as already GC'ed. Second, it is also easy
> not to have any penalty if not used: simply put the garbage collector in
> a library and have a similar restriction to that of typeinfo: the garbage
> collector is only used if any module include a special header (say gc.h).
> The implementation only has to declare an external variable in the header
> which brings in the collector. Thus the argument doesn't hold.
>
> The only valid arguments are lateness and complexity to implement on ALL
> platforms (although you could have a last resort implementation in which
> the collector simply never runs!).

I realize that it is - and has been for quite a while - too late for
language extensions.

Is it too late for a small library extension? One small header, that
might contain the entire implementation? Providing a gc header with a
gc-placement new is not perfect, but vastly superior to nothing. Boehms
GC could perhaps serve as an example of what interface to provide. His
interface is modeled closely after the Detleffs/Ellis language extension
proposal. The suggestion above (allow no op collector + library rather
than language) could give implementors sufficient leeway and be trivial
to implement and still allow better implementations.

This would in spite of its simplicity still give two very important
benefits:

1) Garbage Collection sanctioned. This is by far the most important
benefit. Standardization is a form of sanction. It would become alright
to use GC in C++. Vendors would be less inclined to sneer at users
asking for GC. Some might even provide a working implementation:-) Those
that don't, at least there is a minimal, portable standard interface to
commercial or freeware third party allocators.

2) Standardized interface with the usual benefits.

Adding a gc.h might also be taken as an indication of future development
in future revisions of the language. There would be no cost to those
that didn't use GC.


--
Lars Farm, lars.farm@nts.mh.se
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]