• Advertisement
Sign in to follow this  

String class and memory leaks

This topic is 4520 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have an array of a particular structure, the structure has strings in it. The array must be a fixed length, so I assume the memory for the strings is allocated on the fly. How does it get released, because I think I am getting memory not released at the end of my program, and it only seems to happen when I put values in these strings. Do the strings need to be released? Thanks

Share this post


Link to post
Share on other sites
Advertisement
Hmm, from experimenting it looks like the memory is released when the owner is released. Is this right? How does the runtime keep track of this? This means I should dynamically allocate the array and free it to make sure the string objects in the structure get released?

Share this post


Link to post
Share on other sites
Er, no?

std::strings will nicely release anything they hold when they're destroyed, which should be when the struct dies.

If you're using char *s in the struct, then yes, you should free them [in the structure's destructor for c++]

And even if you don't, on any modern PC OS, the memory will be reclaimed by the OS at termination.

Code would be helpful.

Share this post


Link to post
Share on other sites
Quote:
Original post by Telastyn
Er, no?

std::strings will nicely release anything they hold when they're destroyed, which should be when the struct dies.

If you're using char *s in the struct, then yes, you should free them [in the structure's destructor for c++]

And even if you don't, on any modern PC OS, the memory will be reclaimed by the OS at termination.

Code would be helpful.


I think he's talking about Java, but it's kind of hard to tell.

Share this post


Link to post
Share on other sites
Quote:
Original post by Roboguy
Quote:
Original post by Telastyn
Er, no?

std::strings will nicely release anything they hold when they're destroyed, which should be when the struct dies.

If you're using char *s in the struct, then yes, you should free them [in the structure's destructor for c++]

And even if you don't, on any modern PC OS, the memory will be reclaimed by the OS at termination.

Code would be helpful.


I think he's talking about Java, but it's kind of hard to tell.


I'd thought of that, a little too late. Though if it were java, wouldn't java do it's automagical garbage collection on it? Anyways, no matter the language, OSes are pretty good these days about memory reclamation.

Share this post


Link to post
Share on other sites
Thanks for the reply guys, I am talking about C++. I was definitely getting a memory leak from it. When I set the string to anything other than "" I get memory leaks when the program exited. When I changed it to "", no memory leaks. Wish I could supply some sample code, but it's pretty imbedded. I changed the array in the class to be a point and allocated the array using 'new'. Then when I do a 'delete []' the strings seem to be freed and no memory leak.

Am I going crazy? You don't seem to think this is possible.

Share this post


Link to post
Share on other sites
In C++, whenever you want to dynamically allocate an array, using the new and delete[] operators is a great choice. In your situation, you can simply declare a variable of type char* and then allocate space for it using the new operator. Then, when you're done using it, call delete[] on it and it's cleaned up beautifully.

char* MyString;

MyString = new char[64]; //Memory allocated
delete[] MyString; //Cleaned up--no leaky

Share this post


Link to post
Share on other sites
Quote:
Original post by Teric
In C++, whenever you want to dynamically allocate an array, using the new and delete[] operators is a great choice.

No! Direct dynamic memory allocation and deallocation should always be your last choice. To represent text use std::string. For anything else use another container (i.e. std::vector, boost::multi_array, etc.). std::string will deallocate any memory it allocated when it is destroyed, even if that destruction is due to stack unwinding caused by an exception.

OP: How is your array declared and how are you detecting memory leaks? The most likely explanation is that your array is a static array that is constructed before your program enters main and destroyed after program execution leaves main and that your memory leak detector is running before your array is destroyed.

Enigma

Share this post


Link to post
Share on other sites
How are you checking for memory leaks?

most std::string implementations don't use new to allocate memory. They use some sorting of memory pooling technique, often with a static memory pool. This can sometimes be detected as a memory leak, but it isn't


It is safe to assume that containers in namespace std don't leak memory.

Share this post


Link to post
Share on other sites
What *exactly* were you using that appeared to leak?

How *exactly* did you change it such that it appears not to leak?

Share this post


Link to post
Share on other sites
Quote:
Original post by Zahlman
What *exactly* were you using that appeared to leak?

How *exactly* did you change it such that it appears not to leak?


So, at it's most basic for debugging I have a class called 'Terrain'. That has an array declared

TerrainTexture m_terrainTextures[32];



In the initialization of the class constructor, I have...

for (i=0; i < 32; i++)
m_terrainTextures[i].Filename="Test";



This caused memory leaks (according to VS2003 debug configuration memory leak dump at the end of program). The destructor was definitely getting called for the class (I had a breakpoint). If I changed the above line to...

m_terrainTextures[i].Filename="";



then I got no memory leak.

[Edited by - Raeldor on September 3, 2005 4:34:51 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Are you using this line?
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );


This checks for memory leaks *AFTER* the program ends. There is another way to use this debug function that check memory at that time. If there is a variable still in scope, it will be seen as a memory leak.

Share this post


Link to post
Share on other sites
What data type is Filename?

EDIT:

m_terrainTextures[i].Filename=


and

m_terrainTextures[i]=


look to be two completely different things.

Share this post


Link to post
Share on other sites
Sorry, my typo. I will edit above post.

m_terrainTextures[i]="";

Should have read...

m_terrainTextures[i].Filename="";

Filename is a string type.

Share this post


Link to post
Share on other sites
A std::string, a char*, or a char[INSERT_CONSTANT_HERE]? These are all refered to as "strings", though the second and third are "c strings" while the first is a "standard template library string class"

Share this post


Link to post
Share on other sites
Quote:
Original post by Erzengeldeslichtes
A std::string, a char*, or a char[INSERT_CONSTANT_HERE]? These are all refered to as "strings", though the second and third are "c strings" while the first is a "standard template library string class"


std::string.

I am not specifically using...

_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );

But I think because my app is an MFC application it is calling this somewhere. I get a dump when the program completes.

Share this post


Link to post
Share on other sites
std::string does not leak. That is all there is to it, unless of course you have a very faulty implementation which is most likely not the case. Setting it to "" or whatever will not stop a leak because there isn't one. So like someone said above, your leak-checker is probably just wrong. When using string just treat it like an int. Do you have to set an int to 0 to stop it from leaking? No, of course not. Likewise with string. So rest easy lad, for you have no leak.

Now you might be wondering, how does string handle memory management such that there are no leaks? There is this beautiful thing in C++ called the destructor. It is the opposite of a constructor. When a string goes out of scope its destructor is called automatically. You never need to call it explicitly. If I have a class A the constructor is A::A(). The destructor is A::~A(). So if you ever design a class that does memory management make sure that you implement the destructor to clean up anything that it allotted.

Also, if you have a class that other classes derive from, make sure that it has a virtual destructor. Otherwise you will end up with leaks and worse.

Share this post


Link to post
Share on other sites
I remember seeing at least one implementation (it was either STLport or VC 2k3, I can't remember which) that didn't deallocate string memory, but kept them in a list of free blocks and reusing them later with other strings. That implementation never actually released those free blocks (that I could see).

Share this post


Link to post
Share on other sites
The MFC leak checker likes to show static variables (or variables with global scope) as leaks. I reckon it's because it starts to list the "leaks" before all the statics are destroyed.

AFAIK the cause is the undefined static initialisation (and destruction) order.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement