[cairo] UserFontFace vs FtFontFace management (cairomm)

[Jonathon Jongsma]

Behdad Esfahbod wrote:
> Ian Britten wrote:
> 
>> Nor do I, especially not knowing all the C<->C++ separation issues
>> you need to maintain between cairo<->cairomm...
> 
>> Anything I would come up with would lean towards trying to store the
>> actual C++ object in the user-data part of the C object, but I'm
>> assuming you've been down that road...
> 
> Yes, that's how it's supposed to be done.

Yes, and I do store a *pointer* to the wrapper object in the user-data part of the C 
object, but that does not really help me here since that will not keep the wrapper object 
alive.  It is simply a weak reference -- once the wrapper object is destroyed, the pointer 
will be dangling, which causes the memory corruption and crash that Ian reported initially.

In the current cairomm implementation, the lifetime of the wrapper object is managed by 
the smart pointer that it is created with.  When the wrapper object is deleted, the 
destructor simply calls cairo_font_face_destroy() on the wrapped object.  If I were to 
store an owning reference to the wrapper inside of the wrapped C object, the wrapper's 
destructor would never be called, so we'd never _destroy() the underlying font face, and 
it seems that we'd have circular reference issues.  Or am I missing something? (quite 
possible, I admit)

>> I also assume there's a reason that the C++ Context doesn't simply
>> maintain a reference to the faces that are set on it...
> 
> Because that would be redundant and the font face on the context can be
> changed from other languages.

By Context, I assume you mean Cairo::Context (?).  Besides the issues that Behdad 
mentions, it would also lead to strange behavior because the Context wrapper object could 
die before the underlying cairo_t dies (exactly the same issue we've been discussing, but 
just on a different class), which would free any references to font faces we have been 
maintaining, even though the underlying cairo_t object still holds references to the 
underlying C font face objects.  It all gets really messy very quickly if you try to do 
anything in the wrapper layer beyond the bare minimum.

-- 
jonner