OSDev.org

Posted: **Tue Feb 14, 2006 2:41 am**

What happens if I allocate memory using new[] and then delete it using 'delete' not 'delete[]'.
For e.g.

char *p = new char[10];
...
delete p;

Posted: **Tue Feb 14, 2006 3:01 am**

ad hoc: Memory leak. You are freeing only the first element of the array.

en detail: Will look it up in "Effective C++" later. (Highly recommended reading for C++ coders.)

Posted: **Tue Feb 14, 2006 3:20 am**

Ok exactly what I expected.
Any chance there is an electronic version of that book someplace?

Posted: **Tue Feb 14, 2006 3:49 am**

Neo wrote: Ok exactly what I expected.
Any chance there is an electronic version of that book someplace?

I expect it to be implementation-specific, but that you shouldn't count on it freeing all memory (so you might as well not delete it). It might error (two allocators) or just do exactly as you expect it to (single allocator). My guess for the majority of implementations is that they do exactly what you would expect it to, just free the memory.

Posted: **Tue Feb 14, 2006 3:53 am**

just free which memory?
The whole array or the first element only?

Posted: **Tue Feb 14, 2006 5:10 am**

After referring to Scott Meyers' "Effective C++", chapter 5:

Code: Select all

string * stringArray = new string[100];
...
delete stringArray;

In this case behaviour is undefined. Even if the memory for the array is free'd correctly, it is very likely that 99 of the string objects above never get their destructor called.

It might be that some smart implementation sacrifices some memory and some performance to handle the case gracefully, but as with everything that is labeled "undefined" in C/C++, you should not rely on it.

Posted: **Tue Feb 14, 2006 9:29 am**

And note that when it says undefined it really truely means that. I can't remember it offhand but there is an operation that would appear simple at frst sight that is akin to

Code: Select all

i++ = i++

that is also classed as undefined, one compiler ended up generating code that adds 7 to the value of i.

Posted: **Tue Feb 14, 2006 9:37 am**

On the subject of undefined behaviour, a quote from the early days:

The '#pragma' command is specified in the ANSI standard to have an arbitrary implementation-defined effect. In the GNU C preprocessor, '#pragma' first attempts to run the game 'rogue'; if that fails, it tries to run the game 'hack'; if that fails, it tries to run GNU Emacs displaying the Tower of Hanoi; if that fails, it reports a fatal error. In any case, preprocessing does not continue.

-- Richard M. Stallman, The GNU C Preprocessor, version 1.34

Consider that the compiler might decide to wipe your hard drive in case you do something undefined. It would be a really bad compiler if it did that, but still 100% standard-compliant.

Posted: **Tue Feb 14, 2006 10:50 pm**

From the Jargon File, v 4.4.7:

nasal demons: n.

Recognized shorthand on the Usenet group comp.std.c for any unexpected behavior of a C compiler on encountering an undefined construct. During a discussion on that group in early 1992, a regular remarked ?When the compiler encounters [a given undefined construct] it is legal for it to make demons fly out of your nose? (the implication is that the compiler may choose any arbitrarily bizarre way to interpret the code without violating the ANSI C standard). Someone else followed up with a reference to ?nasal demons?, which quickly became established. The original post is web-accessible at http://groups.google.com/groups?hl=en&selm=10195%40ksr.com

OSDev.org

delete and delete[]

delete and delete[]

Re:delete and delete[]

Re:delete and delete[]

Re:delete and delete[]

Re:delete and delete[]

Re:delete and delete[]

Re:delete and delete[]

Re:delete and delete[]

Re:delete and delete[]