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

std::map and newed char *

P: n/a
Hello,

Say I have a map:

typedef map< MyString, const char* MyMap;

The char* are being new'd. Do these needed manually deleted or are they
deleted in the destructor? I know if the map was using std:string they
would be freed.

If so, in *my* destructor where mMyMap is a memeber, I am trying:

for ( MyMap::iterator iter = m_mymap.begin(); iter != m_mymap.end();
iter++ )
delete [] (*iter).second;

Although, how do I know these are getting freed? Is there some sort of
test I can add. I tried to assing the (*iter).second to the const char*
but in the debugger this makes it look like these did not get deleted.

-- Brian Ray

Jul 3 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
br*******@gmail.com wrote:
Hello,

Say I have a map:

typedef map< MyString, const char* MyMap;

The char* are being new'd. Do these needed manually deleted or are they
deleted in the destructor?
Why should they be? The map doesn't even know where the pointer comes from.
I know if the map was using std:string they would be freed.
In this case, the string's destructor is called, which does whatever is
needed to release the string's resources. However, pointers don't have
destructors, so nothing is done when they are destroyed.
If so, in *my* destructor where mMyMap is a memeber, I am trying:

for ( MyMap::iterator iter = m_mymap.begin(); iter != m_mymap.end();
iter++ )
delete [] (*iter).second;

Although, how do I know these are getting freed?
What do you mean?
I tried to assing the (*iter).second to the const char*
but in the debugger this makes it look like these did not get deleted.
Again, what do you mean? Did the delete[] operator not get called?

Jul 3 '06 #2

P: n/a

<br*******@gmail.comwrote in message
news:11*********************@v61g2000cwv.googlegro ups.com...
Hello,

Say I have a map:

typedef map< MyString, const char* MyMap;

The char* are being new'd. Do these needed manually deleted or are they
deleted in the destructor?
In general, you need to delete anything you new. (We'll leave "smart
pointers" out of the picture for now, since you're not asking about them.)
I know if the map was using std:string they
would be freed.
That's because a std::string is not a pointer. It has a destructor which
will get called when the container is destroyed. Pointers don't have
destructors, so nothing will get done for them.
>
If so, in *my* destructor where mMyMap is a memeber, I am trying:

for ( MyMap::iterator iter = m_mymap.begin(); iter != m_mymap.end();
iter++ )
delete [] (*iter).second;

Although, how do I know these are getting freed? Is there some sort of
test I can add. I tried to assing the (*iter).second to the const char*
but in the debugger this makes it look like these did not get deleted.
If you call delete[], then you're deleting. The compiler will do what it is
supposed to do. Is there some problem you're anticipating with the code?

-Howard

Jul 3 '06 #3

P: n/a

br*******@gmail.com wrote:
Hello,

Say I have a map:

typedef map< MyString, const char* MyMap;

The char* are being new'd. Do these needed manually deleted or are they
deleted in the destructor? I know if the map was using std:string they
would be freed.

If so, in *my* destructor where mMyMap is a memeber, I am trying:

for ( MyMap::iterator iter = m_mymap.begin(); iter != m_mymap.end();
iter++ )
delete [] (*iter).second;

Although, how do I know these are getting freed? Is there some sort of
test I can add. I tried to assing the (*iter).second to the const char*
but in the debugger this makes it look like these did not get deleted.
If they are not deleted, then the for loop was not executed. You can
check if there is any pre-mature return.
>
-- Brian Ray
Jul 3 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.