Re: [GD-Windows] memory leak?
Brought to you by:
vexxed72
From: Colin F. <cp...@ea...> - 2002-11-07 14:58:17
|
2002 November 7th Thursday Okay, I just wasn't sure if "new" and "delete" on a "struct" would, in practice, work the same way as with a "class". Let's just say I avoid pointless risks, and I'd use "class" instead of "struct" if the object in question had member variables that required construction. The code sample with the "memory leak" calls std::vector::clear() -- not "erase()". Sure, capacity is never reduced by "erase()", but "clear()" (with VC++ .NET implementation) makes the same single "_Tidy()" call as the destructor -- which allegedly really does free memory after calling the destructor on all elements. In any case, I don't see how (assuming Jason's STL implementation isn't broken) STL has anything to do with the "memory leak", since Jason's code is doing "new" and "delete" on objects that happen to CONTAIN an STL container. It's not about capacity of vectors never shrinking; the whole vector should be destroyed! So, I'm still vaguely suspicious about the vector destructor actually being called when Jason does the delete on a TestObj -- but I am totally willing to believe that "struct" and "class" are essentially treated the same by the compiler (apart from the very minor default "public" vs "private" distinctions). Maybe it's worthwhile to examine the other two possibilities I proposed: [B] Process memory grows due to reading in more code (DLL or EXE) because new code/functions were called; [C] Lazy C runtime library is hanging on to memory after all allocations are freed just because it is likely you'll want more memory again in the near future -- and maybe it can avoid expensive system calls. But perhaps the real issue is the method of measurement of "process (memory) consumption", and the interpretation of that quantity. --- Colin cp...@ea... |