tags:

views:

370

answers:

6

Hi,

I'm new to C++, and im confused about arrays and pointer. Could someone tell me how can i properly delete a pointer. Like for example,

int *foo;
foo = new int[10];

delete foo;

or

delete [] foo;

Thanks.

+3  A: 

If you do new <type>[] you must do delete []. It's a simple enough rule, and worth remembering.

dcrosta
+4  A: 

If you allocate an array of objects using the new [] operator then you must use the delete [] operator and therefore the non-array new can only be used with the non-array delete.

int *a = new int[10];
int *b = new int;

delete [] a;
delete b;
Nick Bedford
+5  A: 

It's:

delete[] foo;

Edit: Modern compilers really need you to use the correct delete operator, or they may leak memory or fail to run the proper destructors.

(I earlier stated that it didn't make a difference in practice. About 10 years ago, I tried many different compilers and failed to find one that actually leaked memory if you mistakenly omitted the []. However the howls of the mob - see below - have forced me to re-try my experimentation, and it seems that modern compilers/libc++s really do care.)

alex tingle
Even if compilers do the right thing with `delete`, I think using `delete []` is still better practice -- both for cases where you run into compilers that do not do the right thing, but also as a declaration of intent.
dcrosta
Compilers might not leak memory, but they likely won't call destructors without the `[]`...
bdonlan
I don't think I've ever seen a compiler which allows you to use delete when delete[] is expected. They always produce code that blows up when I do it.
jalf
@alex: It __WILL__ leak memory. But because you used the wrong delete you have messed up the internal memory structure used by the memory management routines. Thus it is quite possible that the it will not be reported by any tools that try and monitor memory leaks.
Martin York
They might not leak memory when you use types with trivial dtors. For UDT's with non-trivial dtors, however, this is quite different, because `delete` won't call all the dtors.
sbi
bdonlan, jalf, Martin: thanks for pointing out my mistake - corrected now. Clearly C++ compilers/runtimes are more sophisticated than they were when I tried this experiment, back in the last century!
alex tingle
At least Visual C++ 8.0 will be able to detect mismatches between array/non-array new and delete (when called with the /analyze switch). And the generated programs will leak if the wrong delete has been used (for classes with destructors).
MP24
+1  A: 

You walked in the front door and left it open. Then you walked through to the back door and tried to close it but you smashed it because it was already closed.

foo = new int [10];  // so when you open the front door
delete [] foo;       // please remember to close the front door.

foo = new int;       // and when you open the back door
delete foo;          // please remember to close the back door.

Don't mix them up!

yjerem
+9  A: 
Jerry Coffin
What if you were trying to build a string class, or something useful like that? Blanket bans on new are bad.
Hooked
The blanket ban would be on new[], not on new. A collection class (including a string) should invoke ::new(size_t); directly. When you use new[], it creates an array of objects -- i.e. all those positions are allocated AND constructed. A collection should NOT create objects in the empty space (merely pointless for a string, positively harmful if the objects are expensive to construct). Instead, it should allocate uninitialized storage, and then use placement new to create objects in that storage.
Jerry Coffin
+1  A: 

Anytime you newed an array you use delete[]. Sometimes you new'ed an array using new - then you still have to use delete[] - no way out. So it's not exactly a rule "use delete[] when you new[]'ed" but rather "use delete[] when deleting an array".

typedef int array[5];

int *a = new array;
delete[] a; // still delete[] !
Johannes Schaub - litb