@s_i - Thanks.
You were right all along, I just didn't see it to begin with.
@The Tall Man
Quote: "Also, frequently used new and delete pairs are slow, due to the windows memory manager, and could result in system memory fragmentation (meaning new allocations would become slower and slower, and it would be more difficult to allocate a large memory block in the future).
In my software, if I anticipate a need for a frequently used local new and delete pair, I will allocate once, a higher-scope variable that can be reused just for that purpose."
My code was testing for memory leaks which requires frequent use of new/delete.
Quote: "Delete is unsafe for memory that you've not allocated. The reasons are obvious. You're apparently getting away with it for the time being, and maybe you could indefinitely if you'd like to take that gamble."
Unless the library you're using actually
requires you to clean up after it, which is the case with DarkGDK. We've established that DarkGDK allocates all strings using new[] in this function here:
DARKSDK void CreateSingleString(DWORD* dwVariableSpaceAddress, DWORD dwSize)
{
if(dwSize>0)
{
// Create a core string
*dwVariableSpaceAddress = (DWORD)new char[dwSize];
}
else
{
// Delete a core string
delete[] (LPSTR)*dwVariableSpaceAddress;
}
}
And additionally allocates the string a second time for you whenever you call any of the string functions, but it won't take care of deleting them. That's up to you.
Quote: "Why leave that memory bug open? Why not just fix the source code? As for checklists though, I'm pretty sure I saw a db cleanup/delete/empty checklist command somewhere."
The only smart way to solve this problem would be to have DarkGDK return std::string instead of raw pointers. If anyone here is up for re-writing the entire string system of DarkGDK then be my guest.
