> I have found memory leaks due to mismatched new/delete in > JSBsim (and submitted patches to fix the problem). > And JSBsim is very far from being the only place in > FGFS where c-- style manual memory management is used, > as detailed above.
I appreciate any bug reports, and others have run valgrind and reported the results to us many times over the years. I also have run various memory management tools on our code (most recently I have tried runtimechecker). But, the reference to the use of new/delete as so-called "C--" style is not helpful, nor is it valid for us, IMO. In our case (and I would guess for FlightGear as well) lists of objects are often needed where the number of objects is not known. That is, objects (engines, landing gear, flight control components, etc.) are read and pushed onto a vector as they are read. Pushing an object instance onto a vector is a bad idea, as a proper copy constructor must then be created, because the elements stored in a vector may be rearranged as the vector grows. We create instances of engines and other components at runtime and place pointers to those objects in the vector. Each object instance is [supposed to be] properly destroyed as the sim shuts down. I looked at using auto_ptr some years ago, but in compiling across platforms it wasn't working very well for me. Jon ------------------------------------------------------------------------- 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
