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

[strk]

I found out that our gnash::font class was storing texture_glyph *values*
into a std::vector, while texture_glyph is a ref_counted (thus GcManaged) 
class.

Now, this is unsafe (and corrupts memory in the GC case) in that
std::vector will destroy the values after copying them somewhere else
on resize.

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

For texture_glyph class, this happens often, so I'm debating wheter that
class really needs to be a ref_counted (thus GcManaged) object at all.

Currently, it seems that no parts of the code are storing texture_glyph
into intrusive_ptr, and so the code doesn't blow up that much.
If we used a similar 'wrapping' for registration into the GC it wouldn't
be a big problem for GC model either. 

Basically, the change would be that GcResource instances would not be
*automatically* (by GcResource ctor) registered to the GC, but the
registration would be offered by a pretty simple and dumb gc_ptr<> 
templated class.

Storing a GcResource pointer into a gc_ptr<> class could register that
pointer into the GC for you. Mapping a 'smart_ptr' macro to either
'intrusive_ptr' (for the RC case) or 'gc_ptr' (for the GC) case would
likely give us the same abstraction for both models, which is:
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)

--strk;

 ()   ASCII Ribbon Campaign
 /\   Keep it simple!