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

[strk]

On Fri, Jun 15, 2007 at 05:06:00PM -0600, Eric Hughes wrote:
> 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.

Both GC and RC ? Do you really want to go there ?
In any case the 'smart_ptr' would allow this in the future, it's just a thing
programmers can stuff their pointers in.
Currently (what I'm working on) it will be *either* GC *or* RC, not both.

> >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.

Why all this work ? Can't we just rely on the programmer to know what 
he's doing and NOT registering the instance with the GC ?
Simply NOT storing a pointer to that stack-instance into a gc_ptr<>
class (like it wasn't be doing into an intrusive_ptr<>) would suffice.

> In the case where some reference is usually created, it _is_ less efficient 

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

> >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.

There's no 'using namespace boost' in gnash. And should never be.
Our one would be gnash::smart_ptr.
Anyway suggestions for a better name are welcome.

--strk;