struct Tuple
{
string interrog;
string response;
vector<int> unlocks;
bool unlocked;
};
// ... //
bool Script::Init(string a_path)
{
// load from a file
ifstream file(a_path.c_str());
if (!file.is_open())
return false;
char buff[256];
while (!file.eof())
{
int index = -1;
Tuple t;
t.unlocks.clear();
file.getline(buff, 255);
if (buff[0] == '/' && buff[1] == '/')
continue;
char ibuff[8];
for (int i = 0, j = 0; buff != 0; ++i)
{
if (buff == ' ')
{
ibuff[j] = 0;
if (j > 0)
{
int p = atoi(ibuff);
if (index == -1)
index = p;
else
t.unlocks.push_back(p);
j = 0;
}
}
else if (j < 8)
ibuff[j++] = buff;
}
if (j)
{
int p = atoi(ibuff);
t.unlocks.push_back(p);
}
if (file.eof())
break;
file.getline(buff, 255);
string interrog(buff);
if (file.eof())
break;
file.getline(buff, 255);
string response(buff);
t.interrog = interrog;
t.response = response;
if (index == 0)
{
t.unlocked = true; // index 0 = greeting - always unlocked.
}
else
{
t.unlocked = false;
}
m_tuples[index] = t;
}
file.close();
return true;
}
Memory leak problem
So no use of new or malloc, but from what I've been able to determine, there's some internal re-allocating or something going on for the strings, and I've sprung a dozen or so memory leaks according to VC. Here's the culprit function:
I've tried invoking explicit destructors on the strings, and on the Tuples themselves, but to no avail - I get memory leaks. I'm feeling like a complete C++ newbie here, and I just know the answer is going to be embarassingly simple, but go on I can take it.... *cringe*
does the mem leak grow if you call the function several times?
By the way, use std::getline() instead of file.getline(). It allows you to getline into a string.
By the way, use std::getline() instead of file.getline(). It allows you to getline into a string.
mmgr is great for testing this kind of stuff.
What I suspect is happening is you're using a version of the STL that uses pooled memory (like STLPort). The pools aren't freed until the application exits. If you're using the _CrtCheckMemory() and other CRT debug memory functions, then it checks the allocated memory before you exit main() or WinMain(), where there's still memory allocated in the pools, so it shows up as a memory leak.
If you can get a source file and line number where the allocation occurs, and its in a STL header / function, or its unknown, then its probably this problem. Don't worry about it, unless you have a buggy STL version, just about the only way to make the STL leak memory is not not call the destructor (e.g. delete[] a void* instead of a std::map*).
What I suspect is happening is you're using a version of the STL that uses pooled memory (like STLPort). The pools aren't freed until the application exits. If you're using the _CrtCheckMemory() and other CRT debug memory functions, then it checks the allocated memory before you exit main() or WinMain(), where there's still memory allocated in the pools, so it shows up as a memory leak.
If you can get a source file and line number where the allocation occurs, and its in a STL header / function, or its unknown, then its probably this problem. Don't worry about it, unless you have a buggy STL version, just about the only way to make the STL leak memory is not not call the destructor (e.g. delete[] a void* instead of a std::map*).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement