C++, do I need to delete a temporary vector

Started by
6 comments, last by SiCrane 18 years, 8 months ago
I've written a method that loads in a .txt file and reads in commands, instructing the program to load in sprites, make copies of some of the sprites and flip them over, etc etc. The method reads in the data and stores it in vectors, depending on the type, eg a command, some int values, a filename: vector<string> commands; vector<string> phrases; vector<int> values; vector<int> amounts; I'm just wondering, do I need to destroy these vectors, or the data, in some way at the end of the routine? They're not needed again by the program, as the file is re-loaded if you die on that level and have to start the level again. Presumably the vectors go out of scope, as they are declared at the start of the method, they're not data members of the class. But what about the strings in the two vectors of strings? Strings are objects, so do I have to delete/destroy them? They're created something like this:

	string text;
	int value;
	while ( ! file.eof() )
	{
// more stuff here...
		file >> text;
		defineNames.push_back(text);
		file >> value;
		defineValues.push_back(value);


Any takers? [Edited by - darenking on August 5, 2005 9:39:32 AM]
Advertisement
Only delete things you new. The vectors store their elements by value, so they will automatically be destroyed when the vectors are destroyed. If you instead had vectors of pointers to strings instead of vectors of strings, you would need to delete the pointers to the strings that you had newed.
No you don't.

As the vectors are local objects, their destructor will automatically called.
The destructor of a vector calls teh destructor (if existing) for all stored objects.
The vectors don't actually take the strings by value, they take them by reference, so in your code seem to be using
file >> text
to fill the string. This would probably fill the same string, and so when you're done you would have a vector filled with references that all point to the same string. It shouldn't be a problem for the ints.
I'm pretty sure about it taking values by reference, the signature is,
void push_back(const Ty& val);
At least according to dinkumware it is.
Sorry if I'm mistaken.

edit-
SiCrane is right that they'll get taken care of by vector's destructor as long as you don't use new to allocate a string. I was just pointing out something else I noticed.
I also noticed that you may only use the string in the while loop, and then just reuse it again on the next iteration. But since you're saving them in vectors I'm assuming you're using it outside the while loop somewhere.
beavis: The vector does indeed take the string by reference, but it stores it by value. It's simply an optimisation to avoid unneccessary copying. If push_back took it's parameter by value then the compiler would have to copy the string twice to insert it into the vector. Once to copy it into the push_back member function and a second time to copy it into final storage (inside the dynamic array that vector maintains). By taking the parameter by reference vector eliminates the redundant first copy and copies directly from the source string to the dynamic array, via a reference.

Enigma
Quote:Original post by beavis6325
I also noticed that you may only use the string in the while loop, and then just reuse it again on the next iteration. But since you're saving them in vectors I'm assuming you're using it outside the while loop somewhere.


Not quite sure what you mean actually. The vectors are created outside of the loop, before the loop. The data is put into the vectors with push_back inside the while loop. Then, after the loop, the vectors are passed by reference to another method, which loops through all the vectors and processes the instructions.

It certainly all works, just wanted to check for memory leaks.
well if it works, I was probably wrong about that.
Depending on your compiler there may be more robust methods to check for memory leaks. For example in MSVC there's the crtdbg.h header which contains the function _CrtDumpMemoryLeaks().

This topic is closed to new replies.

Advertisement