Fabien Costantini wrote: >>>> Currently the Fl_Shared_Image would be removed from the image >>>> list only if release() would be called, but we'd have a problem >>>> anyway, since there might be other pointers to the shared image.
>>> Yup, and we'll just have to educate users about this - don't use >>> delete on shared images, don't mix delete with retain/release, etc. >> And that's the reason why I don't *like* the current implementation >> of Fl_Shared_Image. IMHO education is not the way to prevent >> obvious errors, especially in this case, where we would like to >> have polymorphism (in a way that we can use Fl_Image pointers >> everywhere), but then we must take care how to destroy the object. >> And this should preferably work without dynamic_cast ... > I think you mix 2 things: No, I don't think so (see below). > Polymorphism has nothing to here with the deallocation problem. Maybe I haven't been clear enough... > This is the reference counting that makes the complexity, if any. Yep, true again. > As the Fl_Image destructor is explicitly defined as virtual, it > is not a problem of casting to the correct derived class > before deleting: not only it is not necessary (because the > correct destructors will be called whatever your object > pointer class is derived from in the class tree) but you > should not do it. That's all true, but that's not the point. I'll explain what I mean again: The mentioned aspect of polymorphism is: you can use an Fl_Image (base class) pointer everywhere, and that's all okay. Everything works, drawing, ... 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! That's why I asked, if we should simply say "don't do it!" and Mike talked about education (this effectively means the same). Have I been clear enough now? (If not it may be my fault, not yours, but I hope it's been clear enough). Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
