delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/06/07/12:21:49

Message-ID: <393DF410.93824118@earthlink.net>
From: Martin Ambuhl <mambuhl AT earthlink DOT net>
Organization: Nocturnal Aviation
X-Mailer: Mozilla 4.73 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Strange behaviour of new/delete
References: <8hknqj$gki$1 AT mulga DOT cs DOT mu DOT OZ DOT AU>
Lines: 142
Date: Wed, 07 Jun 2000 07:03:33 GMT
NNTP-Posting-Host: 63.23.136.110
X-Complaints-To: abuse AT earthlink DOT net
X-Trace: newsread1.prod.itd.earthlink.net 960361413 63.23.136.110 (Wed, 07 Jun 2000 00:03:33 PDT)
NNTP-Posting-Date: Wed, 07 Jun 2000 00:03:33 PDT
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com


Alistair_P SHILTON wrote the text quoted below my answer:

 /* mha: code posted by apsh AT ecr DOT mu DOT oz DOT au (Alistair_P SHILTON), turned
    into a real program.  He is concerned with "Strange behaviour of
    new/delete" and asks:

    "I was wondering if anyone else has encountered trouble with
    new/delete. I have a function which allocates memory with new as
    follows:"

    I have obviously added the 'int main() {' 'and return 0; }' program
    bracketing.  All references to NULL have been changed to 0, in
    conformance with most C++ prescriptive stylists, including BS.

    a, b, c, i, removal, and size were never declared in the original
    code. I have declared them as they appear, no matter whether this is
    stylistically best. A value for i (5 in this case) and for size (12)
    were arbitrarily added since it needs initialization.

    I have included <cstdio> so the printfs become legal.

    After all these things, to have a compilable program, there 
    are no compilation or runtime errors.  Since the apsh's question now
    has no referrent, I would suggest that his actual program (which he
    has not shown us) has some apsh-generated errors, perhaps some of
    which are corrected by the above.

    The tests for new failure are misguided.  new does not act like 
    malloc().  They have been removed.

  */

#include <cstdio>



int main()
{
    double **res = new double *[3];
    size_t i = 5, size = 12;
    double *a = new double[i];
    double *b = new double[1];
    double *c = new double[size - i + 1];
    res[0] = a;
    res[1] = b;
    res[2] = c;
    double **removal = new double *[3];
    removal[0] = a;
    removal[1] = b;
    removal[2] = c;
    /* apsh - For simplicity, I've allocated 1 double too much to a and 
       c.  Later on I delete as follows: (res has since become removal) 
     */
    delete removal[0];
    printf("0 down\n");
    delete removal[1];
    printf("1 down\n");
    delete removal[2];
    printf("2 down\n");
    printf("freed partial removal\n");
    delete removal;
    printf("free mem\n");
    /* apsh: (ignore the printf's - I was debugging).  The odd
       behaviour is this - if I don't actually use a or c (don't put
       anything in them), then it hangs at delete removal[2] (even
       though a non zero amount of memory was allocated)!! I've checked 
       on unix, and it works fine - so is this a known bug with djgpp,
       or am I missing something? */
    /* mha: you are obviously missing something.  Perhaps it is legal
       code. */
    return 0;
}






> 
> I was wondering if anyone else has encountered trouble with new/delete.
> I have a function which allocates memory with new as follows:
> 
>     double **res;
> 
>     res = new double *[3];
> 
>     if ( res == NULL ) { return NULL; }
> 
>     a = new double[i];
>     if ( a == NULL ) { return NULL; }
> 
>     b = new double[1];
>     if ( b == NULL ) { return NULL; }
> 
>     c = new double[size-i+1];
>     if ( c == NULL ) { return NULL; }
> 
>     res[0] = a;
>     res[1] = b;
>     res[2] = c;
> 
> For simplicity, I've allocated 1 double too much to a and c.  Later on I delete
> as follows:
> 
> (res has since become removal)
> 
>         delete removal[0];
> printf("0 down\n");
>         delete removal[1];
> printf("1 down\n");
>         delete removal[2];
> printf("2 down\n");
> 
> printf("freed partial removal\n");
>         delete removal;
> 
> printf("free mem\n");
> 
> (ignore the printf's - I was debugging).  The odd behaviour is this - if I
> don't actually use a or c (don't put anything in them), then it hangs at
> delete removal[2] (even though a non zero amount of memory was allocated)!!
> 
> I've checked on unix, and it works fine - so is this a known bug with djgpp,
> or am I missing something?
> 
> ----------------------------------------------------
> 
> Thanks
> 
> Alistair Shilton
> 
> http://www.ee.mu.oz.au/pgrad/apsh

-- 
Martin Ambuhl	mambuhl AT earthlink DOT net

What one knows is, in youth, of little moment; they know enough who
know how to learn. - Henry Adams

A thick skin is a gift from God. - Konrad Adenauer

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019