Newb: Pointers, Refs, & Arrays

[Jeremy Cowles]

I have the following:

int *array = new int[5];


and I destroy it with:

delete [ ] array;


So my questions is, what happens when you destory the array like this:

delete array;

?


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

TIA,
Jeremy

 

[Jeremy Cowles]

BTW: I actually WAS destroying the array improperly up until about 5 min ago
when I noticed the missing brackets.

 

[Alf P. Steinbach]

I have the following:

int *array = new int[5];


and I destroy it with:

delete [ ] array;


So my questions is, what happens when you destory the array like this:

delete array;

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.

 

[Karl Heinz Buchegger]

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.

 

[Alf P. Steinbach]

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.

 

[Jeremy Cowles]

Thanks all.

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.