Free memory problem in STL List

[Kathy]

Hi:

I write a simple C++ program using the following platform

OS: Linux Redhat 7.3
GCC: gcc-3.2.1
C++: libstdc++-v3

The part of the source code of my program is:

list<double> clList1;
double d=1.0;
for (long i=0; i<100000; i++)
{
clList1.push_back(d);
d++;
}
clList1.clear();

list<float> clList2;
float f=1.0;
for (long j=0; j<1000000; j++)
{
clList2.push_back(f);
f++;
}
clList2.clear();

list<double> clList3;
d=1.0
for (long k=0; k<100000; k++)
{
clList3.push_back(d);
d++;
}
clList3.clear();

After I compiled the program and run the EXE file, I found that the program
cannot free the used memory after calling list::clear() function. Also, the
used memory kept alive until the program quit.

Actually, I need to use many lists to temporarily store different data when
running the program. And, my program runs as a server. Therefore, my program
does not exit after finishing its job.

As a result, the memory used by my program increases sharply after finishing
several job requests from clients.

Do anyone get any idea to solve this memory usage problem when using this
STL Container in my program?

Note: When I run the same program in Microsoft Window (using Visual Studio
6.0 for development), I did not encounter this problem. Is it a problem of
the implementation of C++ STL Container in Linux?

Kathy

 

[Gianni Mariani]

Kathy wrote:
....

After I compiled the program and run the EXE file, I found that the program
cannot free the used memory after calling list::clear() function. Also, the
used memory kept alive until the program quit.

That is the expected behaviour.

Actually, I need to use many lists to temporarily store different data when
running the program. And, my program runs as a server. Therefore, my program
does not exit after finishing its job.

As a result, the memory used by my program increases sharply after finishing
several job requests from clients.

Do anyone get any idea to solve this memory usage problem when using this
STL Container in my program?

2 options.

1. Perform computations in a different process.
2. Use a different allocator (STL allows this), that returns resources
to the OS.

Note: When I run the same program in Microsoft Window (using Visual Studio
6.0 for development), I did not encounter this problem. Is it a problem of
the implementation of C++ STL Container in Linux?

Neither - this is expected behaviour.

 

[David Rubin]

Kathy wrote:
...

That is the expected behaviour.

Can you elaborate on this? My STL documentation says that clear() is
equivalent to erase() over an iterator range, and erase() "destroys the
elements in the range...and removes them [from the list]." How can you
infer from this that memory used to create the list elements is not
supposed to be freed?

/david

 

[Gianni Mariani]

Kathy wrote:
...


That is the expected behaviour.

Can you elaborate on this? My STL documentation says that clear() is
equivalent to erase() over an iterator range, and erase() "destroys the
elements in the range...and removes them [from the list]." How can you
infer from this that memory used to create the list elements is not
supposed to be freed?

There are 2 meanings to "free" here.

a) The application marks the resource as being unused

b) The application allows other applications to use the resource

By default, when you "free" (erase, clear, delete etc) you're invoking
behaviour a).

Alot more work is required to invoke behaviour b).

This has nothing to do with C++. I suggest posting questions to
comp.programming.

 

[David Rubin]

Kathy wrote:
...

After I compiled the program and run the EXE file, I found that the
program
cannot free the used memory after calling list::clear() function.
Also, the
used memory kept alive until the program quit.


That is the expected behaviour.

Can you elaborate on this? My STL documentation says that clear() is
equivalent to erase() over an iterator range, and erase() "destroys the
elements in the range...and removes them [from the list]." How can you
infer from this that memory used to create the list elements is not
supposed to be freed?

There are 2 meanings to "free" here.

a) The application marks the resource as being unused

b) The application allows other applications to use the resource

This seems to have more to do with returning the resource to the resource pool
(e.g., malloc arena) than allowing other *applications* to use the resource.
But, I think I see where you are going with this. I guess the point is that the
OS's view of the application might show that the memory footprint does not
decrease whereas the application is internally consistent wrt dynamic memory use
(no leaks). And that is OT.

/david