Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Newb: Pointers, Refs, & Arrays

Reply
Thread Tools

Newb: Pointers, Refs, & Arrays

 
 
Jeremy Cowles
Guest
Posts: n/a
 
      07-21-2003
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


 
Reply With Quote
 
 
 
 
Jeremy Cowles
Guest
Posts: n/a
 
      07-21-2003
BTW: I actually WAS destroying the array improperly up until about 5 min ago
when I noticed the missing brackets.






"Jeremy Cowles" <(E-Mail Removed)> wrote in message
news:jRVSa.132967$(E-Mail Removed). com...
> 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
>
>
>


 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      07-21-2003
On Mon, 21 Jul 2003 17:58:39 GMT, "Jeremy Cowles" <(E-Mail Removed)> wrote:

>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.

 
Reply With Quote
 
Karl Heinz Buchegger
Guest
Posts: n/a
 
      07-22-2003


"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.

--
Karl Heinz Buchegger
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      07-22-2003
On Tue, 22 Jul 2003 09:42:23 +0200, Karl Heinz Buchegger <(E-Mail Removed)> 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.

 
Reply With Quote
 
Jeremy Cowles
Guest
Posts: n/a
 
      07-22-2003
Thanks all.


"Alf P. Steinbach" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Tue, 22 Jul 2003 09:42:23 +0200, Karl Heinz Buchegger

<(E-Mail Removed)> 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.
>
>


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Multidimensional arrays and arrays of arrays Philipp Java 21 01-20-2009 08:33 AM
char arrays and integer arrays... why the difference? Bill Reyn C++ 3 06-22-2004 12:01 PM
Arrays.asList() returning java.util.Arrays$ArrayList Alexandra Stehman Java 5 06-17-2004 06:04 PM
Arrays and Pointers to Arrays kelvSYC C Programming 2 09-26-2003 06:52 AM
initializing arrays of arrays Mantorok Redgormor C Programming 4 09-11-2003 02:08 AM



Advertisments