I\'m quite worry because I wrote a little application and it seems that there is a memory leak if I believe valgrind (What I actually do):
==9321== 251 bytes in
To quote Valgrind FAQ
With GCC 2.91, 2.95, 3.0 and 3.1, compile all source using the STL with -D__USE_MALLOC. Beware! This was removed from GCC starting with version 3.3.
With GCC 3.2.2 and later, you should export the environment variable GLIBCPP_FORCE_NEW before running your program.
With GCC 3.4 and later, that variable has changed name to GLIBCXX_FORCE_NEW.
Also discussed in GCC FAQ
I would not worry too much about STL leaks.
The default STL allocator (for gcc) uses clever tricks to maximize efficiency that Valgrind often reports as leaks. Notably it pools memory, meaning that it keeps memory around when you clear a string
and may reuse it next time you insert in a map
or a vector
for example.
I don't think the pool itself is properly disposed of at the end of the program, probably to avoid the Static Destruction Order Fiasco (ie, imagine that the pool is disposed of and you then request memory, urk). Thus it leaks... right before your program ends and the OS gets the memory back forcefully.
I suspect what's happening is the compiler is using NRVO to put your temporary string into its real return location. That return string is then stored inside an object that's allocated and leaked off the heap.