Fabien Costantini wrote:
>> Fabien Costantini wrote:
> 
>> But then you want to destroy the object, and then you must
>> know, which type of object it really is: if it's an
>> Fl_Shared_Image you must cast it to (Fl_Shared_Image *) and
>> then call "image->release()" or do something equivalent, but
>> if it is not, then you must call "delete image". I know that
>> there are different ways to achieve this (including dynamic_cast),
>> but simply calling "delete image" without distinction would
>> do the _wrong_ thing if it is really an Fl_Shared_Image.
>>
>> And no compiler would warn you about it, although
>> ~Fl_Shared_Image() is protected. That's the point!

> This is exactly why mike suggested to implement release() in the Fl_Image 
> class I think.

He wrote "refcounting", but I don't want to be nitpicking, maybe
that's what he meant.

> This way, we could avoid completely the need of deleting images.

No, objects are created with new, and objects are deleted with
delete (or variants). Static and local objects are deleted
automatically, you can't do anything against that. Adding
release() to Fl_Image as an alternate means of destroying
an Fl_*_Image object might work, but still calling delete
explicitly would do the wrong thing for Fl_Shared_Images.

And I hope that you won't suggest to make ~Fl_Image()
protected... ;-)

> a release base impl. would just delete himself in the non shared image impl.,
> the shared image would do what it does now.

IMHO that's the wrong way (although it would work, as you
wrote it). But see above.

Please give me some time to write my proposal. I'll do it
when I'm at home again...

Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to