--> By the way, all those tests are done with OSG 2.2, so maybe the problems I'm speaking about are already solved in th SVN version...
Manu. 2007/12/15, Emmanuel Roche <[EMAIL PROTECTED]>: > > 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
