On Saturday 19 January 2008, John Denker wrote: > ... > Forsooth it would make sense to *start* by > cleaning up the source i.e. getting rid of needlessly non-automatic > memory management (rather than starting with valgrind), for > several reasons: > a) It's just plain easier to look at the source than to look > at the valgrind output. Valgrind can see the mess left behind > by buggy code, but it doesn't tell you which line of code is > buggy. > b) Cleaning up the code is at least as effective, possibly more > effective at fixing memory leaks. > c) It's the Right Thing to do anyway. Beyond fixing memory leaks, > it has the side-effect of making the code more readable, more > re-usable, more extensible, et cetera.
the good things about doing it from the valgrind side are: a) you get a call trace b) you can start with things that either leak a lot (which valgrind tells you) or are easy to fix c) it is hard to detect uninitialized variables by looking at the source by only looking at the source i woudn't have known where to start. now things are already a bit clearer and i am starting to do general clean-ups and optimizations (e.g. replacing serveral if - else if - else if... with switch) i just hope i don't step on anone's feet by doing so ;-) > >> osg::ref_ptr and SGSharedPtr which should be used for all long-lived, > >> shared objects. > > Ah, "should be". There is presently a noticeable gap between > what "is" and what "should be". Examples of non-automatic > memory management include: ( ... long long grep-listing ...) this list is rather useless. it is not forbidden to assign new objects to normal (non-smart) pointers. often the pointers then get into some structure that manages them. but yeah, often they don't. also. your list is much too long. did you want to scare me off? regards, - till ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
