Re: [Gnash-dev] GC: texture_glyph and private dtor/copy

[Eric Hughes]

At 05:50 PM 6/15/2007, strk wrote:
> Both GC and RC ? Do you really want to go there ?

Well, I've always seen RC as special case of GC, one that's not reliable in 
general.  A reference count can be seen as a memo of the number of incoming 
edges.  It would seem that there may be some benefit to combining the 
mechanisms.  But like I said before, my desiderata was simplicity of 
interface--nothing else.

> Can't we just rely on the programmer to know what
> he's doing and NOT registering the instance with the GC ?

Things change.  An original coder probably knows better.  One making an 
incremental modification may not.  The most obvious error would be adding a 
reference to an existing non-GC object from a new GC object as an 
incremental addition and not realizing there's a need to add gc_ptr<> to 
the old declaration.

If there's a *relatively straightforward* way of doing this, I'd recommend 
it to avoid future problems.  I don't have a strong opinion, mind you, and 
it's your call.

> Passing auto values around as pointers is a bug, I'd avoid complex solution
> to make it safe.

Yes, passing pointers to auto values as such is unsafe.  Initializing a 
managed object with one, however, need not be unsafe.  I have some ideas 
about how to do this, if you're curious.

--------------------------------------------------------------

> Anyway suggestions for a better name are welcome.

How about "template< class T> managed_ptr ;"?

> > Small, but important: "smart_ptr" is already in Boost, it's in TR1, and
> > should essentially be treated as a quasi-reserved identifier.
>
> There's no 'using namespace boost' in gnash. And should never be.

My real point is that shared_ptr is developing some fixed semantics as a 
human-readable name (not as a member of a namespace); I'd recommend not 
using it with different semantics.  In particular, shared_ptr won't ever 
delete a cyclic reference; that's not a defect, that's just how it works.

I have "using boost::shared_ptr" in headers, simply because I consider it 
such a valuable tool.  I'd have "using std::TR1::shared_ptr" if it were 
standard yet, and I look forward to "using std::shared_ptr".  I'm not 
implementing a generic language, cyclic references aren't a problem, and I 
don't use the keyword 'delete' as a result.  I also use scoped_ptr and an 
occasional auto_ptr.

Eric