By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,264 Members | 1,795 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,264 IT Pros & Developers. It's quick & easy.

delete vs delete[]

P: n/a
AB
Hi all,

A thought crossed my mind....

if I allocate memory for an array at runtime using....

int* arr = new int[num_of_elems] ;

what happens when I then de-allocate memory using

delete arr ;

AND/OR

delete[] arr ;

As I understand it, the first method will remove the reference only,
whereas the second method will de-allocate the memory as well as
removing the reference.

Am I right?

May 29 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
AB posted:

if I allocate memory for an array at runtime using....

int* arr = new int[num_of_elems] ;

what happens when I then de-allocate memory using

delete arr ;

Same thing that happens when you inject female human sexual hormones into
an adolescent male hedgehog:

Undefined Behaviour.

AND/OR

delete[] arr ;

AND: Undefined Behaviour

OR: The array gets destroyed properly.

As I understand it, the first method will remove the reference only
whereas the second method will de-allocate the memory as well as
removing the reference.

You don't understand what's going on. Your code doesn't contain any
references.
-Tomás
May 29 '06 #2

P: n/a
On 28 May 2006 21:26:23 -0700, "AB" <ab*****@gmail.com> wrote:
Hi all,

A thought crossed my mind....

if I allocate memory for an array at runtime using....

int* arr = new int[num_of_elems] ;

what happens when I then de-allocate memory using

delete arr ;
C++ Std, 5.3.5- 2. ".. the value of the operand shall be a pointer to
a non-array object or a pointer to a sub-object (...) . If not, the
behavior is undefined"

AND/OR

delete[] arr ;


So you should only use the second form to delete an array. Ther is no
reason to do otherwise.

Zara
May 29 '06 #3

P: n/a
AB
>adolescent male hedgehog:

Why not a male gnat?

May 29 '06 #4

P: n/a
AB wrote:
Hi all,

A thought crossed my mind....

if I allocate memory for an array at runtime using....

int* arr = new int[num_of_elems] ;

what happens when I then de-allocate memory using

delete arr ;
Undefined
AND/OR

delete[] arr ;
The array is destroyed, the memory is freed.
As I understand it, the first method will remove the reference only,
What reference?
whereas the second method will de-allocate the memory as well as
removing the reference.

Am I right?


No.

May 29 '06 #5

P: n/a
You already got plenty of answers. Think of it this way: the c++
new/new[] delete/delete[] "API", so to speak, is a pointer.

The pointer itself is just abstraction of concept called "memory
address", the delete does see only a pointer. It must implement a flag
to tell if the "memory" that was being allocated previously with new is
array or not, for it to be able to handle freeing memory allocated with
new and new[] both alike. Such flag or similiar construct does not
exist, so the burden of knowing if memory was allocated with new or
new[] falls to the application.

This code...

char* buffer = new char[100000];
delete buffer;

... invokes undefined behaviour. Most likely it will even compile into
*identical* platform specific binary code. But it doesn't have to. The
code may just aswell explode your PC, or turn your poop green for a
week, or place a Viagra order.

The situation is even more volatile (not that it makes any difference)
if the type is not char, but some class with very complex memory
management scheme. Let's say, you allocate 100 objects with new[], then
you "free" the memory using delete. The destructor for these objects
isn't called and that may be a problem (but again, that is not relevant
as you already invoken undefined behaviour and ANYTHING can go wrong).

Example:

Your compiler and platform implements delete differently from delete[]
-- they are completely independent the delete[] is NOT implemented in a
way that it first calls destructors for the array objects and then uses
delete (plain) to free the memory, instead, the implementation of
delete does read from data associated with delete[], which has totally
different memory layout. It reads a variable from wrong address from
memory, let's assume that this doesn't yet crash and the address has
literal value of 12. Let's further assume that this code runs on x86
architechture on ring0 privilege level, then let's assume that we write
into this address (physical address, not linear address) and we
overwrite interrupt table entry there. Then this interrupt is
controlling some gadget attached to the PC, and this gadget gets a
wrong signal and overheats, then a curtain is hanging over the gadget,
it catches fire, then your house burns down and the Taleban terrorists
next door also have their hideout on fire. Then their improvised dirty
bomb (WMD!!!) explodes destroying three square miles of neighbourhood
and contaminating 20,000 people of whom 8,000 die of cancer in the next
10 years. You survive the undefined behaviour, but lose your balls.

Or, the code might *appear* to work without any ill side effects
whatsoever. You never know.

May 29 '06 #6

P: n/a
AB wrote:
adolescent male hedgehog:


Why not a male gnat?


Gnat adolescense is fleeting indeed. It's hard to pin one down long
enough to inject the hormones, before said adolescence has reached its
end.

Luke

May 30 '06 #7

P: n/a
AB
> Gnat adolescense is fleeting indeed. It's hard to pin one down long
enough to inject the hormones, before said adolescence has reached its
end.


This might be single most important off topic tid-bit I've picked up.

May 30 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.