NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/os/mswindo/programm/misc/4309

Text File | 1992-12-17 | 3.2 KB | 87 lines

Newsgroups: comp.os.ms-windows.programmer.misc
Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mksol!duitz
From: [e-mail] (mitchel n duitz)
Subject: Re: Borland and Memory
Message-ID: <[e-mail]>
Organization: Texas Instruments, Inc
References: <[e-mail]> <[e-mail]> <[e-mail]>
Distribution: usa
Date: Thu, 17 Dec 1992 16:00:15 GMT
Lines: 75

In article <[e-mail]> [e-mail] (Rob Ryan) writes:
>In <[e-mail]> [e-mail] (mitchel n duitz) writes:
>
>>I seem to have a point in my code, where I am stuck.
>>
>>I do a lot of new and delete inside my code, and first,
>>I do see a memory leak somewhere, but I can;t pin it down.
>>
>>The problem I have is that the program just spins.  This
>>can happen in two different places - either when I declare ofstream ofs(name),
>>or when I'm in a loop allocating a 2 dimensional array - similar to the
>>following
>>
>> [ ... code deleted ... ]
>
>As recommended by another user, make sure that you're using a memory model
>large enough to support all the data you're using.  Also, make sure you
>check the results of the "new" allocation so you can determine if everything
>works or not, and report a failure when it does occur.
>
>I wanted to try this out, though, and got some curious results.  I initially
>tried Borland's EasyWin and kept on getting GPFs.  So, while the command
>line versions of Borland C++ v3.1 and MSC v7.0 dealt with the following code
>fine (reporting errors allocating at row 14, which makes sense given how
>much data I'm allocating).  And when I tried from Windows, Microsoft's
>QuickWin worked fine, too (reporting allocation failure at row 12, which
>also makes sense due to overhead of Windows processing).  What failed to
>work was Borland's EasyWin.  It got a GPF when I tried this program with it.
>I don't know why, though, since the code seems safe.  I presume this is a
>bug in EasyWin's memory allocation routines.
>
>Assuming that you're not using EasyWin, you'd presumably want something
>like the following.  Incidentally, when I decrease the numbers to 150 and
>30, the program works without incident.  And I don't know why the ofstream
>would be causing a problem.  Have you tried running the code through a
>debugger and seeing where the problem occurs?
>
>-------------------------------- cut here --------------------------------
>
>#include <iostream.h>
>
>const long MAXX = 1000;
>const long MAXY = 1000;
>
>main()
>{
>    float **pn = new float *[MAXX];
>
>    if (!pn) {
>        cerr << "failed initial allocation";
>        return -1;
>    }
>
>    for (int i = 0; i < MAXX; i++) {
>        pn[i] = new float[MAXY];
>        if (!pn[i]) {
>            cerr << "failed allocation of row " << i << endl;
>            return -2;
>        }
>    }
>
>    return 0;
>}
>
>--
> Rob Ryan
>    [e-mail]

I'm using The Large Model in the program, and the allocation
works fine the first time I use the object, then when i delete
the object that uses all the memory, and try again it bombs.
I am freeing the memory delete[] pn.   So I don;t know
what's going on.  I even looped through with the debugger, and
then it got to a magic row and it locked up. Thanks.