If I use delete, when delete[] is correct, can the consequence be
anything
worse than a memory leak?

E.g.
int* pi = new int[2];
delete pi; // delete[] is correct

(Obviously, let's assume the rest of the program doesn't contain any
errors.)

ted wrote:

Yes. The use of new[] (i.e. you are creating a dynamic array) often
returns an adjusted pointer that is not a pointer to the allocated
memory but only a pointer to the array. The first few bytes of allocated
memory is used to store the array size. delete[] will first destroy the
array objects and then adjust the pointer so that it points to the
allocated memory for release.

On 10 Jul., 14:28, ted trhj.homeunix.net> wrote:

Yes. What happens is not specified, but typical behaviour includes
memory leaks, missing destructor calls, heap corruption and crash.

There's practically never any reason to use new[]. Prefer using
std::vector which has very low overhead and offers additional safety
and lots of extra goodies such as resizing.

/Peter

ted wrote:

If you are lucky it may crash (as it did to some person asking about this on
freenode/##c++ IRC). For those of use who are not so lucky it will corrupt
the memory allocator internal data and then (much later) you may get a
crash from doing someting as innocent as "new SomeObject" and have no idea
what's happening...

--
Dizzy

On Jul 10, 8:28 am, ted trhj.homeunix.net> wrote:

Yes. It is undefined behavior, so anything can happen. Always assume
the worst. Also, don't forget that one can overload operator new/
delete and also new[]/delete[], so you cannot make assumptions about
what they do nor what is safe when you misuse them.

Chris

On Jul 10, 8:28 am, ted trhj.homeunix.net> wrote:

Yes.
Generally a memory leak results when you "forget" to tell the
memory allocator to free a block.

But here you are deleting a structure that doesn't
really exist. The allocator has to maintain internal
data structures to track where and what memory has
been allocated. An array allocation may very well
have a different structure than that from a
simple new(), and an incorrect delete can corrupt
that structure, which is a very bad thing (tm),
and likely to cause a crash.

The memory allocator could be designed to tolerate
this, but my experience is that memory allocators
are not very tolerant .

Ken Krovchuck

The theoretical consequence is undefined behavior (I think, needs
double check). Your coffee-boiler could explode. The actual
consequence depends on your compiler/library/memory allocator. Test
and see.

However, are you asking the right question? Why do you need to call
delete on an array?

- Are you writing a function template and don't know the kind of
object you're deleting?

- Could you not use vector<>?

- Or is it just a theoretical question? If so, have you insured your
coffee boiler?

Can you tell us more?

Carl

ted wrote:

The consequence of an invalid delete is undefined by the standard. You
always want to avoid this, because it makes your program ill-formed and all
bets are off. There are cases where this 'undefined' behaviour is somehow
defined by some other source, i.e. some platform-specific behaviour, but
those are the only exceptions I would let slip.

Any further questions, whether this can lead to anything bad in practice are
IMHO moot, in particular because this is a problem that is so easy to
avoid.

std::vector vi(2);

Don't use new[]/delete[] for temporary buffers, use std::vector instead.
Even more, I don't remember using new[]/delete[] at all, because in most
cases this was just a weak replacement for either std::vector or
std::string. If at all, I'd use something like boost::scoped_array, which
makes sure the right delete is invoked.

ted wrote:

Undefined. It could crash your machine - don't do that.

The memory layout of something allocated with new compared to an array
allocated with new[] might be very different, so the corresponding
delete operations will not necessarily be compatible to each other in
any way.

So long,
Thomas

ted wrote:

Yes, it's undefined behavior and the standard places no bounds on that.
It gets particularly onerous when the object being deleted has class
type.