chapter and verse needed for matching new[] to delete[] [C++]

Prev: Converting new [] to vectors
Next: Operator chaining

From: Andreas Wallner on 1 Mar 2010 04:25

> What I am looking for is chapter in verse in the std that says this is
> wrong, along with something that clearly explains why this error can
> cause heap corruption.

The clearest think I can think of is 5.3.4/8 [expr.new]:
If the allocated type is an array type, the allocation function�s name
is operator new[] and the deallocation function�s name is operator
delete[].

or some points from 5.3.5 that mention that delete is for non-array
objects and delete[] is for array objects.

I don't think there is a warning for wrong usage of delete/delete[] in
the standard, since it does not specify how memory management has to
be done, therefore it can not predict possible errors.

Btw...weired colleague...

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Nick Hounsome on 1 Mar 2010 04:25

On 1 Mar, 04:50, Andrew <marlow.and...(a)googlemail.com> wrote:
> I am familiar with the need to match new[] to delete[]. It is a
> programming error to say new[] then say delet without the square
> brackets. In some environments this can lead to heap corruption, as
> Meyers warns in item 5 of Effective C++.
>
> What I am looking for is chapter in verse in the std that says this is
> wrong, along with something that clearly explains why this error can
> cause heap corruption. This is not for me - I already know not to do
> it. But there is a colleague that needs convincing. I have to use his
> code in the library of his that I need. It is trashing the heap and I
> know the code does new[] but delete without the brackets. He wont
> change the offending code without proof that its current form can
> cause heap corruption.
>
> I did try telling him that common heap mgmt code will coalesce
> adjacent free blocks when doing a delete and that such a mismatch can
> cause this to go wrong but he wont take my word for it. I dont think
> he will take Meyers word for it either.

Sometimes physical vilolence can be justified :-)

new[] will typically store the number of elements on the heap before
the returned array so that delete[] can call the right number of
dtors.

new doesn't need to do so.

So

X* xp = new X[10];
delete xp;

will (if it works at all - which is unlikely) only call X::~X() once
to delete xp[0].

Obviously an implementation COULD do the right thing in all cases but
it isn't REQUIRED to do so by the standard because it is more speed
and memory efficient not too.

In the early days of C++ you even had to specify the array size at the
point of destruction (delete[10] xp) but this was found to be too
error prone and didn't have any efficiency benefits since the number
of elements must always be stored somewhere.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Ric Parkin on 1 Mar 2010 04:26

From: Juan Pedro Bolivar Puente on 1 Mar 2010 04:26

>
> I did try telling him that common heap mgmt code will coalesce
> adjacent free blocks when doing a delete and that such a mismatch can
> cause this to go wrong but he wont take my word for it. I dont think
> he will take Meyers word for it either.
>

The main difference is that the heap manager should store extra
information in the [] case to account the fact that the pointer points
to several objects. This is needed, because 'delete' should call the
destructor of every of them. If you call delete on a new[]-allocated
pointer it can happen that only the first object of the array is
properly destructed --leaving dangling resources-- or even worse random
effects depending on the implementation of the heap manager. Of course
the C++ designers could have chosen to avoid the difference, but them
you would be paying an extra word for every allocation even if you don't
need it, which goes against �you pay just for what you use� C++'s
philosophy,

Sorry I can't point to a std chapter, but this explanation should be
convincing enough; they key point is that new/delete are not just syntax
sugar for malloc/free, they also call constructors/destructors.

JP

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Francis Glassborow on 1 Mar 2010 04:26

Andrew wrote:
> I am familiar with the need to match new[] to delete[]. It is a
> programming error to say new[] then say delet without the square
> brackets. In some environments this can lead to heap corruption, as
> Meyers warns in item 5 of Effective C++.
>
> What I am looking for is chapter in verse in the std that says this is
> wrong, along with something that clearly explains why this error can
> cause heap corruption. This is not for me - I already know not to do
> it. But there is a colleague that needs convincing. I have to use his
> code in the library of his that I need. It is trashing the heap and I
> know the code does new[] but delete without the brackets. He wont
> change the offending code without proof that its current form can
> cause heap corruption.
>
> I did try telling him that common heap mgmt code will coalesce
> adjacent free blocks when doing a delete and that such a mismatch can
> cause this to go wrong but he wont take my word for it. I dont think
> he will take Meyers word for it either.

My fgirst reaction is that he is too stupid to be allowed to program :)
What more evidince does he want that what he is doing is wrong in
addition to his code trashing the stack.

However tell him to study section 18.4.1 in its entirety drom which you
can deduce that the delete expression calls operator delete which must
be passed a pointer to storage allocated with operator delete and that
the delete[] expressions calls operator delete[] which must be passed a
pointer allocated with operator new[]. There is no room fgor alternatives.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First | Prev |
Pages: 1 2
Prev: Converting new [] to vectors
Next: Operator chaining