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

[Eric Hughes]

At 03:27 PM 6/15/2007, strk wrote:
> use 'smart_ptr' when not willing to have full control over lifetime,
> don't use it to expliclty manage it (and possibly allocate on the stack too)

I am now pretending complete ignorance, and I'm simulating a complete 
newbie to the project.

Wouldn't it be better (contingent on its very possibility) to use a single 
declaration mechanism that rolls together both RC and GC mechanisms?  And 
maybe even auto declarations?  That way there's one type template that 
means "manage my memory" that users can use and then not think about it any 
more.  It seems more reliable in the long term.

> GC-managed instances should *never* be deleted by anyone else that the GC.
> Also, GC-managed instances should *never* be allocated on the stack !

It seems there's a way around this.  Consider a GC-instance whose 
allocation is "auto".  It is protected by a sentry that does "copy on 
destroy", that is, moves if out of the stack and into the heap.  The sentry 
only copies if some other reference has been created to it since creation, 
so that if it was treated as purely local, nothing else happens.

If the typical case were that references to such an object were rare, this 
is just as efficient as manually moving its storage class.  It's certainly 
more reliable.

In the case where some reference is usually created, it _is_ less efficient 
(spurious copy) in run-time efficiency.  It is also, on the other hand, 
much quicker to stability, since it will work rather than leak.  And 
someone will notice eventually and get rid of the copy.

> Mapping a 'smart_ptr' macro

Small, but important: "smart_ptr" is already in Boost, it's in TR1, and 
should essentially be treated as a quasi-reserved identifier.

Eric