Hello Carsten, Thanks a lot for your reply.
> true, once the conversion to boost::function has happened there is not > enough type information left to do the comparison. However, the return > value from a boost::bind() (before being converted to boost::function) has > enough information, so internally we use that to remove functors, e.g. from > OSGVisitSubTree.cpp: > > value->addChangedFunctor( > boost::bind(&VisitSubTree::rootChanged, this, _1, _2, _3), > ""); > > value->subChangedFunctor( > boost::bind(&VisitSubTree::rootChanged, this, _1, _2, _3)); > *facepalm* Of course I tried the two-line-approach OSG::ChangedFunctor objCB = boost::bind(&classname::destinationChanged, this, _1, _2); pObj->subChangedFunctor(objCB); Which can't work then. I also overlooked the subChangedFunctor is templated. Plus, searching the OpenSG source code did not return any use of subChangedFunctor - I don't understand how that could have happened. Anyway, I still don't really understand how that function can work, since the needed information should be lost during add, so it should not be possible to find it again. > yes, if you are worried about two objects being allocated to the same > memory location (at different points in time of course) you could add the > container id as well. I guess if I had a callback function in a list which points to an invalid memory address, I might be in trouble. :-) Aloha, Andi ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
