Re: [boost] Smart pointer status, directions, thoughts

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-05-27 10:54:19

Greg Colvin wrote:
 
> At this point cyclic_ptr is a toy, 

        I don't agree. The code looks well on the way
to production quality to me.

> whereas Boehm's collector
> and it's commercial derivative (Great Circle) are serious
> production tools. 

        With a different purpose.

> I'm not sure where Felix fits on this
> spectrum -- but I take it is more than a toy.

        Felix GC isn't a toy, but it was originally
designed with a specific purpose: to be used to collect
stack frames generated by the Felix language translator.

        The version I have posted to boost has been extended
with a few conveniences for 'hand coding' in C++, such 
as the 'smart pointer' handle class.
 
> As for being global, that can be an advantage, as you don't
> have to worry about passing pointers from thread to thread.

        You do if the collector isn't thread safe :-)

> Ocaml, like many such languages, generates huge amounts
> garbage in the normal course of operation, much of it short
> lived, so generational collection is an advantage.

        It is quite true, as Bjarne pointed out, that 
boxing creates more objects in the heap.
 
> Resource release by finalization is always problematic, no
> matter what language and no matter what collection strategy.
> IMHO of course.

        Hmmm: a lot of people use this idiom.
 
> My cyclic_ptr is an experiment in combining reference counting
> and mark-sweep to get some of the advantages of each, but it
> is too soon to say how successful it is.  I take it that Felix
> is a similar experiment.

        Yes. 
 
> My feeling is that the standard will
> be hard-pressed to impose any requirements on finalization
> order or timeliness without unduly constraining implementers.

        That depends on exactly what support is provided.
At present, there is a question as to whether
a program that simply 'forgets' objects is well defined.

        Even if there is wording requiring every object to be
destroyed, if all that happens is that memory is released,
the requirement isn't normative, since there is no way
to detect this.

        So, for a transparent collector, all that may be
necessary is to _permit_ a C++ program to 'forget' objects,
but also to _permit_ them to be finalised.

        This means that the program can be executed 'correctly'
with or without a garbage collector. Of course, the collector
may be necessary in practice to prevent running out of memory.

> I'm not sure this is really important, since I see big systems
> succeeding in java with no useful finalization guarantees.  

        It is important, IMHO, to ensure that GC is a viable
option for C++. What does this actually require? Library
support? [A standard GC interface?] Extensions like a 
'gc' keyword to mark pointers? 

        One thing that the Felix experiment suggests is that
Felix style GC would be easier to use if a table of offsets 
of pointers was available at run time in the typeinfo record.

        That would permit:

        new(gc, typeinfo(T).shape) T( .. args .. )

It would be nice if, somehow, this could be made into a template,
but the variable number of constructor arguments prevents that.
[This problem doesn't arise in Felix, since functions other than
tuple constructors always have one argument, possibly a tuple]

-- 
John (Max) Skaller, mailto:skaller_at_[hidden]
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net