This might be foolish Q but I like to try to ask here, I experienced many times myself being trap into access violation errors when I use "new" operator to dynamically allocate memory, the problem is after I use new once, I copy the returned pointer value into another variable, and then advance this pointer exceeds the allocated memory, C++ complier won''t warn me, even run time won''t occurs any error until I try to use "new" again to allocate another memory, the error occurs, I wonder why and why the run time error didn''t occur while access exceeds boundary but another new operator did?

According to the standard, if an allocation fails, new is supposed to return NULL and throw a bad_alloc exception. From what I''ve heard, however, many current implementations don''t actually throw the exception.

Are you saying that new will return a too-small block of memory for the final alloc and then fail on the following one?

If a compiler were to insert code to check for out-of-bounds assignments, and if that code were to be executed every time your program assigned into an array or through a pointer, all the extra code being run could slow down the execution of your program immensely. The design of the C/C++ language prioritizes performance over safety. The compiler doesn''t add an inordinate amount of behind-the-scenes memory maintenance and error checking. This is why you don''t get warned at run-time when you write passed the boundaries of an array. In this case, the language allows you to do what you want, and you are responsible for making sure that your code does what you intend it to do.

A memory integrity check when ''new'' is called, is a fairly reasonable thing for a compiler to insert. It only happens once during the ''lifetime'' of a chunk of allocated memory, and the ''new'' operation only checks the memory it is allocating. Since memory allocation is a relatively slow operation anyway, a single integrity check per call to ''new'' wont slow you down much.

So, what is happening is that you are overwriting memory that has not yet been allocated. The next time you request a memory allocation, the ''new'' operation detects the memory corruption and reports an error.

So it turns out that the little bit of error-checking code that is being added by the compiler is sufficient to catch your bug.

quote: Original post by Kensai

According to the standard, if an allocation fails, new is supposed to return NULL and throw a bad_alloc exception. From what I''ve heard, however, many current implementations don''t actually throw the exception.

<pedantic>The standard says that a failed ''new'' should just throw a std::bad_alloc exception. It is technically impossible to throw an exception and return a value at the same time </pedantic>

Kensai and all the guys reply my message, I like to say Thank you very much, it really gaves me an idea what VC++ complier doing but I still wonder while complier checks the allocated memory will be illegal accessed will cost a lot of time, is it meant the complier time? If so, I think it''s better an option provide for someone like me - a mess programmer who access pointer as variable! It won''t hurt the complied executable anyway but will help me no need to check each new statement and it''s pointer activities?

Kylotan: hahaha... good point

banlee: You might want to investigate the debug memory management functions. In your VC++/MSDN documentation, do a search for the string "Using the Debug Heap" Basically, with debug builds you can opt for new to do a memory integrity check after it''s allocated memory. This should give you some indication of whether something has gone wrong.