Is it hard to implement deletion of array using a single keyword? Is it less efficient?
-
3I hesitate marking this as *Not a real question*, though perhaps not too well-phrased, it does ask for the technical challenges behind the unification; I believe those could be addressed. – Matthieu M. Jun 12 '12 at 15:41
-
Related question: http://stackoverflow.com/q/703691/10077 – Fred Larson Jun 12 '12 at 15:50
4 Answers
First, let me summarize what both do: delete
calls a destructor for one object and deallocates the memory; delete[]
calls the destructor of some number of objects and deallocates the memory.
One could fold these into the same operation: "calls the destructor of some number of objects and deallocates the memory.". After all one is some number.
Both delete
and delete[]
operate on a pointer. Like this one:
foo* ptr;
Look at it closely. And tell me how many destructors should be called when we delete
it. You can't. And so can't the compiler. This can only be known at runtime. The information about the number of objects has to be stored somewhere. That means that, for each usage of new[]
, there is some extra memory allocated to keep track of that number.
C++ is built on the principle of "you don't pay for what you don't use", and that's why the non-array forms exist: since delete
always only deletes one object, new
doesn't need to allocate any extra.

- 228,013
- 71
- 433
- 510
-
More accurately, this is a legacy problem. It would be trivial to do `delete(1, ptr)` and `delete(expression, ptr);` Everybody knows how many elements they have. – Puppy Jun 12 '12 at 15:58
-
2Malloc knows how much memory was allocated for the allocation request. `delete` could have consulted the same information. – jxh Jun 12 '12 at 16:19
-
@user315052 So what? `malloc` is not `new`. You can't `delete` something you `malloc`ed. – R. Martinho Fernandes Jun 12 '12 at 16:21
-
@DeadMG You may know that in an early version of C++ that's exactly what one would do: `int *foo = new int[10]; delete [10] foo;` Thus no extra storage was required for allocating an array. – bames53 Jun 12 '12 at 16:22
-
3@R.MartinhoFernandes: If the C library is extended to report how much memory was allocated for a pointer, then C++ could easily allow `delete` to behave like `delete[]`, regards. – jxh Jun 12 '12 at 16:25
-
4@user315052 No. Even if that was the case, the information stored by `malloc` is the wrong information. It's the *amount of storage* allocated in some block, which is usually aligned to some special boundary, and thus can be more than the actual size of the objects constructed there. But, what `delete[]` needs is the *number of objects*, not the size of the storage allocated for them. `malloc` doesn't store that because this is irrelevant in C: there are no destructors. – R. Martinho Fernandes Jun 12 '12 at 16:28
-
@R.MartinhoFernandes: What he probably meant is, whatever `delete[]` does could be done by `delete` instead. If `delete[]` stores Xyz information, and does Abc job, then `delete` could do the very same thing. – Nawaz Jun 12 '12 at 16:30
-
@Nawaz If that's the case, these comments are just noise, because that's what the answer reads (second paragraph). – R. Martinho Fernandes Jun 12 '12 at 16:31
-
-
@JamesKanze: And is the way it should be now. Nobody can use an array without knowing how large it is anyway. – Puppy Jun 12 '12 at 16:37
-
1@DeadMG Really? You should see what people in C do for strings. In general, you don't need (or even want) the number of elements allocated, you want the number of elements which are valid. If you don't know how many `char`, or `double` you're going to read, you allocate a million, and return the pointer, with a count of 10, because that's what you actually read. – James Kanze Jun 12 '12 at 16:45
The problem is not complexity, but the fact that the argument to delete
is a single pointer, and that type is exactly the same whether you allocated a single element or an array. Underneath the implementation is quite different, as the number of elements destroyed differs.
This is actually a problem with having backwards compatibility with C... if that had not been a requirement from the beginning we would probably not have C++ (it would not have caught up so much) but the type of new T[N]
could be different from the type of new T
and the type system could be used to detect which delete
needed to be called.

- 204,818
- 23
- 294
- 489
-
1I guess the OP is really asking why `new T` is any different to `new T[1]`. – Oliver Charlesworth Jun 12 '12 at 15:43
-
Which might lead one to ask, "If I'm `new`ing an array of Gizmos, would I ever really want to call the constructor on just the first one?" – John Dibling Jun 12 '12 at 15:47
-
2@OliCharlesworth As I said in my answer: `new T[1]` has additional overhead, and you shouldn't have to pay for what you don't use. – James Kanze Jun 12 '12 at 15:52
It's because one of the overriding principles of C++ design is that you
don't pay for what you don't use. new[]
/delete[]
have extra cost,
and it was felt that their utility (I've never used then in 25 years of
C++.) was limited enough that it didn't justify adding this cost to
non-array new
/delete
.

- 150,581
- 18
- 184
- 329
Features like this cannot just be dropped from the language event if it was easy to implement. Do you volunteer to come and fix all my code after such change?

- 82,306
- 11
- 110
- 171
-
1They could have deprecated the `delete[]` syntax if it was obsolete without dropping it, and have a conforming implementation delegate one to the other. – Mark Ransom Jun 12 '12 at 15:44
-
-
`auto_ptr` is a library class, not the language construct, so it's not the same, and mandating to complicate useful feature is outright stupid, if you ask me. – Nikolai Fetissov Jun 12 '12 at 16:01