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

Memory Leak in deque ?

P: n/a
stp

Hello,

I declare the following types:

typedef pair<long, string> CEventPair;

typedef deque<CEventPair*> EventPairCont;

// here I add some new elements

// l is a long

// value is a string

// events is EventPairCont

if ((npair = new CEventPair (l, value)) != NULL) {

events.push_back (npair);

}

// here I do something with this

...

// at the end I use clear-method to destroy all

events.clear ();

After Shutdown Boundschecker reports me Memory leaks allocated in the
line with new CEventPair. If I step throught code I do allocation
memory for string. But I dont step into the destructor of the string
down from clear ()

Where is the problem ?

Thanks to all.
--
Posted via http://dbforums.com
Jul 19 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
stp wrote:
Hello,

After Shutdown Boundschecker reports me Memory leaks allocated in the
line with new CEventPair. If I step throught code I do allocation
memory for string. But I dont step into the destructor of the string
down from clear ()

Where is the problem ?


*You* are allocating memory for CEventPair, so *you* should clean it up. You
cannot expect deque to delete the pointers you store in it (after all, it
cannot know if you still have a reference lying around somewhere). You
either need to store non-pointers, but the objects themselves (that'll work
fine with the copy-constructor supplied by pair) in the deque or delete the
pointers you allocated yourself.

--
Unforgiven

"Most people make generalisations"
Freek de Jonge

Jul 19 '05 #2

P: n/a

"stp" <me*********@dbforums.com> wrote in message news:33****************@dbforums.com...
// at the end I use clear-method to destroy all

events.clear ();


That doesn't destory any CEventPairs. Your container only
stores pointers. Clearing or deleting the container only
destroys the pointers stored in it, it doesn't call delete on
each element. You need to iterate over the deque and
delete each element.

C++ design is usually symetrical. You delete things in
a complementary manner than they were created.
Jul 19 '05 #3

P: n/a

"stp" <me*********@dbforums.com> wrote in message
news:33****************@dbforums.com...

Hello,

I declare the following types:

typedef pair<long, string> CEventPair;

typedef deque<CEventPair*> EventPairCont;

// here I add some new elements

// l is a long

// value is a string

// events is EventPairCont

if ((npair = new CEventPair (l, value)) != NULL) {

events.push_back (npair);

}

// here I do something with this

..

// at the end I use clear-method to destroy all

events.clear ();

After Shutdown Boundschecker reports me Memory leaks allocated in the
line with new CEventPair. If I step throught code I do allocation
memory for string. But I dont step into the destructor of the string
down from clear ()

Where is the problem ?

Thanks to all.
--
Posted via http://dbforums.com

Try using autoptr or write a loop in your destructor to clear the memory in
CEventPair etc

Jul 19 '05 #4

P: n/a
Govindan wrote:


Try using autoptr or write a loop in your destructor to clear the memory in
CEventPair etc


Do *not* use auto_ptr!! It is not suitable for standard containers.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Jul 19 '05 #5

P: n/a
stp wrote:

if ((npair = new CEventPair (l, value)) != NULL) {
This test can never be true. The 'new' operator either returns a valid
pointer or throws an exception.


// at the end I use clear-method to destroy all

events.clear ();


As others pointed out, this does not delete any of your dynamic objects.
You need to do that yourself. You could make it automatic by using a
smart pointer, but you may not use auto_ptr for this purpose, as it does
not meet the requirements for standard containers.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Jul 19 '05 #6

P: n/a
Kevin Goodsell wrote:
stp wrote:

if ((npair = new CEventPair (l, value)) != NULL) {

This test can never be true.


Excuse me, I meant "This test can never be false", of course.

To put it another way, 'new' can never return a null pointer.

The 'new' operator either returns a valid
pointer or throws an exception.


-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Jul 19 '05 #7

P: n/a
Kevin Goodsell wrote:
To put it another way, 'new' can never return a null pointer.


While I'd like to agree with you (and certainly do in the context of the C++
standard), for many programmers, new certainly can return a NULL pointer.
Visual C++ 6 and older have a (non-standards compliant) non-throwing
operator new. In Visual C++ .NET 2002 and 2003 you get the non-throwing new
if you explicitly ask for it (by using a special form of new) or if the CRT
happens to be linked before the Standard C++ Library (which you can
prevent).

This is the related article from the VS.NET 2003 documentation:
http://msdn.microsoft.com/library/en..._Operators.asp

I realise this group is about Standard C++, and what you said is true for
Standard C++, I'm not debating that. I'm simply pointing out that we
shouldn't lose sight of (however sad) reality there might be out there, and
I'm also trying to prevent the OP from adopting behaviour that might not
apply to his/her compiler.

--
Unforgiven

"Most people make generalisations"
Freek de Jonge

Jul 19 '05 #8

P: n/a
Unforgiven wrote:
Kevin Goodsell wrote:
To put it another way, 'new' can never return a null pointer.


While I'd like to agree with you (and certainly do in the context of the C++
standard), for many programmers, new certainly can return a NULL pointer.
Visual C++ 6 and older have a (non-standards compliant) non-throwing
operator new.


The workaround is to set_new_handler a routine that throws bad_alloc like it should.
Jul 19 '05 #9

P: n/a
On Tue, 9 Sep 2003 17:38:38 -0400, "Ron Natalie" <ro*@sensor.com> wrote:
Unforgiven wrote:
Kevin Goodsell wrote:
To put it another way, 'new' can never return a null pointer.


While I'd like to agree with you (and certainly do in the context of the C++
standard), for many programmers, new certainly can return a NULL pointer.
Visual C++ 6 and older have a (non-standards compliant) non-throwing
operator new.


The workaround is to set_new_handler a routine that throws bad_alloc like it should.


Bad advice.

Will break many libraries.

Use a throwing wrapper instead (note: MSVC 6 still got a problem with
instantiating a template function on a nested class, macros can help).

Jul 19 '05 #10

P: n/a
Alf P. Steinbach wrote:

Will break many libraries.


Haven't found it breaks anything. The majority of things are ill-prepared to deal with new
failing regardless of how the error is indicated.
Jul 19 '05 #11

P: n/a
Unforgiven wrote:
Kevin Goodsell wrote:
To put it another way, 'new' can never return a null pointer.

While I'd like to agree with you (and certainly do in the context of the C++
standard), for many programmers, new certainly can return a NULL pointer.
Visual C++ 6 and older have a (non-standards compliant) non-throwing
operator new.


You are absolutely right and I agree completely with the point you are
making.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Jul 19 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.