On 01/19/2008 07:47 AM, Tim Moore wrote: > I know for a fact that many of those allocations and assignments use smart > pointers.
OK. > How about a more useful list of those that don't? Good idea. Here you go: If we exclude files that make *any* mention of 'SGSharedPtr' or 'ref_ptr' then it appears we have: 471 lines with 'new' statements in 84 files. For the lurid details, see http://www.av8n.com/fly/fgfs/mmm.find I'm sure some of these have carefully balanced, tightly controlled new/delete pairs ... but some of them don't. If anybody wants a copy of the tool I used to ferret these out, let me know. The tool is non-judgmental; it does not distinguish between well-used new statements and ill-used new statements. ============================== On 01/19/2008 08:47 AM, Jon S. Berndt wrote: >> I'm perplexed by the previous comment stating: "we want to avoid writing >> explicit deletes as much as possible, as that need is the source of most >> memory leaks." >> >> Where there is a new, there is a delete. That depends on what the definition of "is" is. I think it would be better to say where there is a new, there _should be_ a delete. Alas, there is a noticeable gap between what "is" and what "should be". This is a problem in fact, not just in theory. 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. >> What am I missing in the above >> comment? I can see memory leaks being caused by NOT delete-ing memory that >> was allocated by a previous "new". If you use the automatic memory management that is a feature of the c++ language, you don't need 'new' *or* 'delete' except in the lowest of low-level code, where ordinary folks don't see them. The main point to keep in mind is that c++ is a different language from c-- ... for good reasons. Switching from c-- to c++ does *not* consist of replacing malloc with new and replacing free with delete. ------------------------------------------------------------------------- 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