On Wed, Dec 29, 2010 at 3:06 PM, Matt Thompson <[email protected]> wrote:
> When you are debugging, the CRT will set the pointer to that particular > pattern (0xfeeefeee) to signify that the memory has been deleted Correct. > even if you set the pointer to 0. I'm 99% sure that's wrong. You'll only see feeefeee for freed pointers that have NOT been set to zero (ie. hanging pointers). If you see that magic number, you've found a timebomb in your code. > This is done to find the exact bug you > had, i.e. a multiple delete. When you are running normally, you > delete the pointer and then zero it out. Except he's not zero-ing the pointer after deleting it which is why the if !null check fails to catch the hanging pointer the second time around. > Calling delete on a null > pointer is technically safe so under a normal run, the second delete > succeeded. > Yes delete(null) is perfectly safe code. One of the most common mistakes I see in production code is checks for null prior to a call to delete. Absolutely pointless. Null pointers are your friends. But neither your code nor delete can detect a hanging pointer until it's too late. The second delete should NOT have succeeded - it's attempting to free a bad address. I'm at a loss as to why it didn't fall over but in release, there are fewer checks so it was most likely luck. (Well technically on win32 you can recover by catching an access violation c-block exception but that's completely non-standard. Fix your code!) > On Wed, Dec 29, 2010 at 12:22 AM, Paul Wellner Bou <[email protected]> > wrote: > > > > I have my reasons. All these data will be passed to OpenGL. But that's > > not the problem anyway. > std vector has an [] operator to expose the underlying array. Using containers that have been apart of the standard for 15 years now will save you a lot of headache.
_______________________________________________ Qt-creator mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-creator
