[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: |
Eric Hughes |
Subject: |
Re: [Gnash-dev] GC: texture_glyph and private dtor/copy |
Date: |
Fri, 15 Jun 2007 18:25:14 -0600 |
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