On 7/28/06, Michael D. Adams <[EMAIL PROTECTED]> wrote: > While doing some conversions to the new SCF, I realized a potential > issue with the handling of the iEventHandler interface. I may have > been inadvertently been adding memory leaks when converting classes to > the new SCF. I'm not very familiar with the new event system so I'm > not sure if this is a problem or not. > > Here is the setup: > * The class "csFoo" implements needs to register as an event listener. > * The "csFoo::Initialize" method registers the event listener. > * The "~csFoo::csFoo" destructor unregisters the event listener. > * The "~csFoo::csFoo" destructor will only get called when the > reference count goes to zero. > > Does registering the event listener cause a (non-weak) reference to > the event handler to be held by the event queue?
Yes it does. > > If so, then the natural way of writing the above with the new SCF > (i.e. "class csFoo : scfImplementation1<csFoo, iEventHandler>") will > make any object written in this fashion live at least as long as the > event queue (since it never gets unregistered unless it is destroyed > which never happens unless it is unregistered). > > Is this a problem? Yes it is. The usual solution to this problem is to make the event handler a separate object (i.e. not embedded). As far as I know all event handler implementations written with old SCF used that system. It appeared like it was an embedded interface but actually it wasn't. It was just an embedded structure but not linked to the parent. > > If it is a problem, is embedding the event handler inside the outer > class the best solution? (Part of the point of the new SCF is to get > rid of those.) Would it be better to have an option during > subscription that allowed a choice between using a hard ref (for "fire > and forget" event listeners) and a weak ref for cases where the object > should just go away and unregister itself if nothing else refers to > it? (Is the latter case needed?) Embedding is IMHO the best solution. Note that we can't really talk about SCF embedding here as in this case the embedding is just having an inner class which is otherwise unrelated (SCF-wise) to the parent. I don't think the weak ref solution is very nice. It would complicate things too much. Greetings, -- Project Manager of Crystal Space (http://www.crystalspace3d.org) and CEL (http://cel.crystalspace3d.org) Support Crystal Space. Donate at https://sourceforge.net/donate/index.php?group_id=649 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Crystal-main mailing list Crystal-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/crystal-main Unsubscribe: mailto:[EMAIL PROTECTED]
