_CrtIsValidHeapPointer(pUserData)

i found out whats wrong!
it happens when idelete m_StrInfo;
where m_StrInfo is SStrInfoData* m_StrInfo;
and SStrInfoData is struct SStrInfoData
{
std::string time;
std::string Vx;
std::string h;
std::string comment;
};
if i cooment the delete line its ok but i dont understand why it happens (probably it was the cause of the DAMAGE:... error as well)
does anyone know why ?

Originally posted by urika
i found out whats wrong!
it happens when idelete m_StrInfo;
where m_StrInfo is SStrInfoData* m_StrInfo;
and SStrInfoData is struct SStrInfoData
{
std::string time;
std::string Vx;
std::string h;
std::string comment;
};
if i cooment the delete line its ok but i dont understand why it happens (probably it was the cause of the DAMAGE:... error as well)
does anyone know why ? Where do you do:

m_StrInfo = new SStrInfoData;
?
If you didn't call operator new, then the call to operator delete is illegal.

If you did call operator new, then for each call to opreator new must be matched with a call to operator delete. In other words, two calls to new must have two (and only two) calls to delete.

If you did match calls to new and delete correctly then you haven't solved your problem. What you did was only cover up a problem that exists elsewhere, and depending on conditions, will crop up again.

Regards,

Paul McKenzie

new returns a pointer. You must not lose that pointer. Can you post a small subset of your work that shows the problem. Post an example of you declaring/using/destroying a dynamic array of your structures.

First, you used operator new[], therefore you use operator delete[] -- note the emphasis. You are missing the [], therefore you are not destroying the elements properly. Mixing the array new with the non-array delete leads to undefined behavior.

Allocate with new, deallocate with delete

Allocate with new[], deallocate with delete[].

Once you change this, then try again. Even if it doesn't solve your problem, you still need to make this change.

Second, your EnlargeArrays function looks suspicious in that I don't know why you need to make m_TempArray global -- it should be a local pointer. The way you enlarge an array is the following:

#include <algorithm>

void Enlarge()
{
// Assume that m_Data is the array
// and buffsize is a global holding the size of the array
SInfoArray *pTemp = new SInfoArray[buffsize * 2];

std::copy(m_Data, m_Data + buffsize, pTemp );

delete [] m_Data;
m_Data = pTemp;
buffsize *= 2;
}

Having said all of this, I personally, and most experienced C++ programmers wouldn't have written what I wrote above, or would even have a function called EnlargeArrays. Remember that you are using C++. Code to resize arrays as you have written is unnecessary. C++ has a std::vector class that takes care of all of these details.

Here is your code rewritten using std::vector.

#include <vector>
//...
typedef std::vector<SInfoData> SInfoArray;
//...
SInfoArray m_Info;
//...resize m_Info
//...
void EnlargeArrays()
{
m_Info.resize(m.size()*2);
}

void DeInit()
{
// Nothing to do
}

I've reduced your code, to one line. In that one line, it did all you tried to do, but the difference is that vector does it correctly and efficiently.

Also, there is no cleanup for you to do at the end, since vector will remove the elements on destruction. And to top it off, std::vector has an overloaded operator [] that works exactly as if you were using an array, so that most of your code stays intact when you switch from arrays to vectors.

I suggest you get a few books on the various C++ classes that would make your work much easier. Maybe "Accelerated C++" by Koenig & Moo is a good start, with an indispensible reference book such as "The C++ Standard Library" by Josuttis as another. There are also articles in dev-archive discussing vector.

When your application is a Win32 app, this does not mean that you have to resort to "old" C++ coding. The C++ library has a lot to offer, such as vector, map, list, etc. -- basically all the stuff you had in MFC, but without any added libraries, and IMO, superior.

Regards,

Paul McKenzie