For an array of basic type this will "work" with most compilers. But
formally it's undefined, and so you have no reason to complain if all
or nothing of the memory is reclaimed, or if operator delete decides
to send a truthful e-mail to W. Whatever.

In practice, delete[] does this in addition to what delete does: it
calls destructors of all objects in the array, for an array of objects.

>Furthermore, I understand that References are like a pointer, but are
>somewhat safer (and less flexable). So what is a "weak" reference?

That is not C++ terminology but general terminology. A "weak" reference
or pointer to an object O is a reference or pointer that doesn't keep O
alive. Various schemes such as reference counting are used to keep
objects alive. With ref-counting an object self-destroys when its ref-
count goes down to zero, and in that case a "weak" reference is a pointer
to O where O's ref-count hasn't been incremented to reflect that this
pointer exists, which can be useful for example to receive events from O.

"Alf P. Steinbach" wrote:
>
> >delete array;
>
> For an array of basic type this will "work" with most compilers.

It 'appears' as if it would work. But think of the following:
Somewhere there has to be stored the information how large that array
has been allocated. If someone faulty does:

int* i = new int [ some_num ];
delete i;

this additional information is never freed. And depending on how this
additional information is allocated exactly (some systems store the
array size in a few bytes before the actual array) the whole array is
never freed.

But formally it's undefined, and so you have no reason to
complain if all or nothing of the memory is reclaimed, or if
operator delete decides to send a truthful e-mail to W. Whatever.

>It 'appears' as if it would work. But think of the following:
>Somewhere there has to be stored the information how large that array
>has been allocated. If someone faulty does:
>
> int* i = new int [ some_num ];
> delete i;
>
>this additional information is never freed.

That is incorrect. It _may_ never be freed, depending on the memory
management, the compiler and perhaps more things. But that would be
a most unusual C++ implementation (and to be very clear, that does
not mean that it is formally well-defined or acceptable code). The
reason it would be most unusual is that 'int' is a built-in type, and
so there is no reason for additional C++ level information. All that's
needed is the memory manager's own block size.

>And depending on how this additional information is allocated exactly
>(some systems store the array size in a few bytes before the actual
>array) the whole array is never freed.

That again would be most unusual; I don't believe there is any C++
compiler where that is the case, but it could in principle exist.

"Alf P. Steinbach" <> wrote in message
news:...
> On Tue, 22 Jul 2003 09:42:23 +0200, Karl Heinz Buchegger
<> wrote:
>
> >"Alf P. Steinbach" wrote:
> >>
> >> >delete array;
> >>
> >> For an array of basic type this will "work" with most compilers.
>
> Out of context quote; continuation was
>
>
> But formally it's undefined, and so you have no reason to
> complain if all or nothing of the memory is reclaimed, or if
> operator delete decides to send a truthful e-mail to W. Whatever.
>
>
> >It 'appears' as if it would work. But think of the following:
> >Somewhere there has to be stored the information how large that array
> >has been allocated. If someone faulty does:
> >
> > int* i = new int [ some_num ];
> > delete i;
> >
> >this additional information is never freed.
>
> That is incorrect. It _may_ never be freed, depending on the memory
> management, the compiler and perhaps more things. But that would be
> a most unusual C++ implementation (and to be very clear, that does
> not mean that it is formally well-defined or acceptable code). The
> reason it would be most unusual is that 'int' is a built-in type, and
> so there is no reason for additional C++ level information. All that's
> needed is the memory manager's own block size.
>
>
> >And depending on how this additional information is allocated exactly
> >(some systems store the array size in a few bytes before the actual
> >array) the whole array is never freed.
>
> That again would be most unusual; I don't believe there is any C++
> compiler where that is the case, but it could in principle exist.
>
>

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!