[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnash-dev] GC: texture_glyph and private dtor/copy
From: |
strk |
Subject: |
Re: [Gnash-dev] GC: texture_glyph and private dtor/copy |
Date: |
Sat, 16 Jun 2007 01:50:14 +0200 |
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;