Memory Leak in deque ?

[Govindan]

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.

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

 

[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.

 

[Unforgiven]

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.

 

[Ron Natalie]

// 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.

 

[Kevin Goodsell]

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

 

[Kevin Goodsell]

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

 

[Kevin Goodsell]

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

 

[Unforgiven]

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-us/vclang/html/_pluslang_The_new_and_delete_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.

 

[Ron Natalie]

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.

 

[Alf P. Steinbach]

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).

 

[Ron Natalie]

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.

 

[Kevin Goodsell]

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