By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,637 Members | 1,967 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,637 IT Pros & Developers. It's quick & easy.

STL "wrought with memory leaks"?

P: n/a
I have been using STL for a long time now, without any problems.
Recently we generated a purification report on our software using
Rational Purify, and we found some memory leaks. My colleague claims
that some of the memory leaks are due to the fact that "STL is wrought
with memory leaks". Of course I disagree. I think that there are no
"inherent leaks" with STL, but if used improperly, leaks will occur.

One common source of leak that I have seen is with 1:N maps. In this
case the value itself is a collection (say an STL set of values). Here
the normal approach of deleting an entry from the map [obtaining the
iterator using the find() operation and then invoking erase() on the
iterator] does not work since you don't want to delete the key-value
pair until you are sure that all the values have been deleted. In this
case, when you delete one of the values, you have to check whether
after deletion there are any values left. Only in the case where the
value portion is empty do you have to delete the key-value pair.
Sometimes due to an oversight, you may forget to delete the key-value
pair when the value collection is empty, resulting in a leak.

Are there any other sources of leaks, due to incorrect usage of STL,
that come to mind?

Regards,
Bhat

Jul 23 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
In article <11**********************@z14g2000cwz.googlegroups .com>,
"Generic Usenet Account" <us****@sta.samsung.com> wrote:
I have been using STL for a long time now, without any problems.
Recently we generated a purification report on our software using
Rational Purify, and we found some memory leaks. My colleague claims
that some of the memory leaks are due to the fact that "STL is wrought
with memory leaks". Of course I disagree. I think that there are no
"inherent leaks" with STL, but if used improperly, leaks will occur.

One common source of leak that I have seen is with 1:N maps. In this
case the value itself is a collection (say an STL set of values). Here
the normal approach of deleting an entry from the map [obtaining the
iterator using the find() operation and then invoking erase() on the
iterator] does not work since you don't want to delete the key-value
pair until you are sure that all the values have been deleted. In this
case, when you delete one of the values, you have to check whether
after deletion there are any values left. Only in the case where the
value portion is empty do you have to delete the key-value pair.
Sometimes due to an oversight, you may forget to delete the key-value
pair when the value collection is empty, resulting in a leak.

Are there any other sources of leaks, due to incorrect usage of STL,
that come to mind?


Storing heap based pointers into containers and then mistakenly
believing that the container will own the pointer is a classic mistake.

Use of strstream without extreme care can lead to memory leaks (you've
got to remember to freeze(false) all the time). If you're not familiar
with this issue, just avoid strstream and prefer stringstream
(<sstream>) instead.

Purify (and other leak checkers) have been known to report false
positives for objects that do lazy initialization. The C++ I/O streams
usually fall into this category. They allocate some resources on first
use and then keep those resources around for later use (they are not
required to do this, it is just a typical implementation strategy).

And of course the number 1 cause of memory leaks is always "somebody
else's code". ;-)

-Howard
Jul 23 '05 #2

P: n/a
Howard Hinnant wrote:
In article <11**********************@z14g2000cwz.googlegroups .com>,
"Generic Usenet Account" <us****@sta.samsung.com> wrote:

I have been using STL for a long time now, without any problems.
Recently we generated a purification report on our software using
Rational Purify, and we found some memory leaks. My colleague claims
that some of the memory leaks are due to the fact that "STL is wrought
with memory leaks". Of course I disagree. I think that there are no
"inherent leaks" with STL, but if used improperly, leaks will occur.

One common source of leak that I have seen is with 1:N maps. In this
case the value itself is a collection (say an STL set of values). Here
the normal approach of deleting an entry from the map [obtaining the
iterator using the find() operation and then invoking erase() on the
iterator] does not work since you don't want to delete the key-value
pair until you are sure that all the values have been deleted. In this
case, when you delete one of the values, you have to check whether
after deletion there are any values left. Only in the case where the
value portion is empty do you have to delete the key-value pair.
Sometimes due to an oversight, you may forget to delete the key-value
pair when the value collection is empty, resulting in a leak.

Are there any other sources of leaks, due to incorrect usage of STL,
that come to mind?

Storing heap based pointers into containers and then mistakenly
believing that the container will own the pointer is a classic mistake.

Use of strstream without extreme care can lead to memory leaks (you've
got to remember to freeze(false) all the time). If you're not familiar
with this issue, just avoid strstream and prefer stringstream
(<sstream>) instead.

Purify (and other leak checkers) have been known to report false
positives for objects that do lazy initialization. The C++ I/O streams
usually fall into this category. They allocate some resources on first
use and then keep those resources around for later use (they are not
required to do this, it is just a typical implementation strategy).

And of course the number 1 cause of memory leaks is always "somebody
else's code". ;-)

-Howard


Maybe this helps explains it:

http://www.sgi.com/tech/stl/alloc.html

Mark

Jul 23 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.