You could've avoided the trouble in the first place with vector's at member that throws an exception on out-of-bounds access attempts [smile].

Also, scattering _CrtCheckMemory() calls throughout your code can quickly help you identify the source of heap corruption.

My 2 cents [smile]

Thanks Coder!

edit: So are you saying that we shouldn't use dynamic arrays? Or just that we should use some sort of container if we do?

edit2: Yes I now see using _ASSERTE with _CrtCheckMemory() will be very usefull for apps made with VC++! [smile]

Quote: edit: So are you saying that we shouldn't use dynamic arrays? Or just that we should use some sort of container if we do?

Basically, in C++, you should almost always use std::vector instead of raw arrays. And always use std::vector::at() to access elements, because it does bounds-checking. If profiling shows std::vector::at() is a bottleneck somewhere (in some oft-used inner-loop), switch to std::vector::operator[](), which simply generates code equivalent to what would have been generated with direct access to the raw array (i.e. no performance hit).

Bjarne - The Man (TM) - says it all. Read everything the guy has to say [smile]

Quote: edit2: Yes I now see using _ASSERTE with _CrtCheckMemory() will be very usefull for apps made with VC++!

You can also make use of _CrtSetDbgFlag for memory-leak tracking - it makes it a breeze (plug "Detecting and Isolating Memory Leaks Using Microsoft Visual C++" into google and read the MSDN article that comes up [smile])

Or instead of _CrtCheckMemory, I use Paul Nettles' mmgr, probably does very much the same thing though. It certainly helped me find some very obscure bugs.

Thanks to both of you!