Newb: Pointers, Refs, & Arrays

Discussion in 'C++' started by Jeremy Cowles, Jul 21, 2003.

  1. 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, Jul 21, 2003
    #1
    1. Advertising

  2. Re: Pointers, Refs, & Arrays

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

    :)




    "Jeremy Cowles" <> wrote in message
    news:jRVSa.132967$...
    > 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, Jul 21, 2003
    #2
    1. Advertising

  3. On Mon, 21 Jul 2003 17:58:39 GMT, "Jeremy Cowles" <> 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.
     
    Alf P. Steinbach, Jul 21, 2003
    #3
  4. "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
     
    Karl Heinz Buchegger, Jul 22, 2003
    #4
  5. 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.
     
    Alf P. Steinbach, Jul 22, 2003
    #5
  6. Thanks all.


    "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.
    >
    >
     
    Jeremy Cowles, Jul 22, 2003
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. kelvSYC

    Arrays and Pointers to Arrays

    kelvSYC, Sep 26, 2003, in forum: C Programming
    Replies:
    2
    Views:
    386
  2. John Nagle
    Replies:
    3
    Views:
    299
    John Nagle
    Feb 25, 2007
  3. Replies:
    1
    Views:
    653
    -berlin.de
    Mar 28, 2005
  4. cerr

    pointers, pointers, pointers...

    cerr, Apr 7, 2011, in forum: C Programming
    Replies:
    12
    Views:
    679
  5. Replies:
    3
    Views:
    266
    J├╝rgen Exner
    May 13, 2008
Loading...

Share This Page