Re: STL container memory issue
Gonzo wrote:
I'm implementing my own graph library [...]. When I build my graph,
I use a lot of memory enough to be view in _top_ or another memory
usage tool. I'm sure that I'm deallocating that memory (I reviewed
the code again and again and I used valgrind to check for memory
leak), but the memory remains in use [...] and when I create the
graph once again, it does not increase memory usage, apparently
reusing the allocated memory.
This is a known phenomenon. The memory is kept for future use in the
process and not given back to the OS.
class MyObject
[slightly reduced]
{
public:
int * a;
MyObject( )
{
a = new int[ 8192 ];
}
MyObject( const MyObject & m )
{
a = new int[ 8192 ];
}
~MyObject( )
{
delete [] a;
}
};
See the so-called "rule of three", which explains why this code is bad and
could leak memory. Further it is not exception-safe and you should use
initialiser lists instead of assignments.
typedef std::list< MyObject > list_t;
#define MB_TO_ALLOC 1000 // Size in MB that the program must alloc.
#define SLEEP_TIME 5 // Time in seconds that the program must wait
unsigned const mb_to_alloc = 1000;
unsigned const sleep_time = 5;
int main( )
{
std::cout << "Alloc..." << std::endl;
list_t * list = new list_t( );
Don't use new, unless you have a good reason to. This is _not_ Java and will
get you into all kinds of problems, in particular concerning memory leaks
and exception safety.
// Number of objects for alloc MB_TO_ALLOC amount of memory
int nObjects = MB_TO_ALLOC * 1024 / 128;
Those seem to be MiB rather than MB. ;^)
for( int i = 0; i < nObjects; ++i )
list->push_back( MyObject( ) );
list->resize(nObjects);
Does anyone know what's going on? How to prevent this memory to be
"reserved"?
Normally, the advise given to people is that you shouldn't care, because the
memory isn't lost but recycled when needed and only not given back to the
OS immediately.
However, your case might be different because if your data structures are
really too large or require too much temporary storage while building, this
isn't a solution. In that case, you could think about replacing the
allocator used by the different containers. This allocator is typically the
last template parameter to the containers and has a default. Using e.g. a
pool allocator you could create the whole structure in there, and when you
don't need it any more you simply discard the whole pool. This topic isn't
trivial though and I'd suggest a visit to the library and some web research
to get you started. I could even imagine there being a few implementations
out there that already fit your needs.
Good luck!
Uli
--
Sator Laser GmbH
Gesch??ftsf??hrer: Thorsten F??cking, Amtsgericht Hamburg HR B62 932
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]