Hi Robert, I understand what you mean, in fact I think exactly the same : I don't like those small tricks to workaround some minor problems. But still I believe there is a memory management issue left here, (in fact both AQTime and the integrated Visual Studio debugger [VS 7.1]) report the same "leaks"... : it is not important because you can't see those leaks before the end of your process, and the process destruction will clean everything anyway, but I don't think relying on such a final cleanup is a good final solution.
As you said, a "clear" function is probably an very bad choice: but as I said, the most important is to be aware of the problem, and to try to find the best solution. By the way, I found two others small issues in this reflection framework : 1) [VERY MINOR] The PropertyInfo class doesn't have a virtual destructor... its derived classes don't have data members, I'm not sure if it is important to have a virtual destructor in this case, I guess it's not, but still, if someone tries to build an extension from this it would surely cause a problem. 2) [HIDDEN LEAK] The CustomAttributeProvider destructor doesn't free the "attribs_" vector... so there is a memory leak if you try to delete types using StdVectorReflector for example. regards, Manu. 2007/12/15, Robert Osfield <[EMAIL PROTECTED]>: > > HI Manu, > > I generally cringe a hacks to get round bugs in other software, and > this does look a case of this here, the profiler you are using is > buggy and producing false positives. Adding a clear method is > potentially dangerous if called at the wrong time, so the naming of > such a method would have to very clearly reflect its purpose, just > calling it clear wouldn't cut it. I not totally opposed to such a > method it does allow you to workaround a problem. W.r.t submissions > see: > > > http://www.openscenegraph.org/projects/osg/wiki/MailingLists/SubmissionsProtocol > > Robert. > > On Dec 15, 2007 12:07 AM, Emmanuel Roche <[EMAIL PROTECTED]> wrote: > > Hi everyone, > > > > just a simple request stil on the introspection framework: > > > > I have noticed that the Types and Converters are stored in a static > > structure in the Reflection class... and this structure is totally > > unaccessible. (Well we could still use Reflection::getTypes() to get the > > type map and delete every type one by one after a const cast, but for > the > > converters map that's not possible. > > > > The problem with this kind of static structure, is that they are > destroyed > > only at the very end of your process, and when it comes to profiling > > questions this gives a big mess (at least on Windows...) : My profiler > > (AQTime 5) is simply considering all the reflection allocations as > memory > > leaks !... > > > > I guess it would not be a bad idea to add a simple "clear" static > function > > to the reflection class to simply delete the static_data member and set > it > > to NULL. This could even prove useful in [I admit very specific and very > > strange] cases where people would want to stop reflecting every types > and > > restart with new types... > > > > Could some one remind me how to process to submit a code change ? > (except if > > someone else can add this "clear" or whatever function directly... it > should > > only be two lines of code anyway: > > > > void clear() { > > if(_static_data) > > delete _static_data; > > _static_data = 0; > > } > > > > regards, > > > > Manu. > > > > > > _______________________________________________ > > osg-users mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
