🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.os.ms-windows.programmer.misc
Article #1972

Re: Borland and Memory

#1972
From: Rob Ryan
Date: Wed, 16 Dec 1992 18:25
66 lines
2905 bytes
In <1992Dec15.144205.16197@mksol.dseg.ti.com> duitz@mksol.dseg.ti.com (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
    rryan@panix.com
Technical Details
Message-ID: <1992Dec16.182513.5844@panix.com>
Path: arc1-ca.pugleaf.net!sparky!uunet!spool.mu.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!malgudi.oar.net!news.ans.net!cmcl2!panix!rryan
References: <1gilfkINNjmd@crcnis1.unl.edu> <BzA2sp.199@newsserver.technet.sg> <BzAyI5.BrH@world.std.com> <1992Dec15.144205.16197@mksol.dseg.ti.com>

Show Full Headers
Complete Article Headers
Newsgroups: comp.os.ms-windows.programmer.misc
Path: arc1-ca.pugleaf.net!sparky!uunet!spool.mu.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!malgudi.oar.net!news.ans.net!cmcl2!panix!rryan
From: rryan@panix.com (Rob Ryan)
Subject: Re: Borland and Memory
Message-ID: <1992Dec16.182513.5844@panix.com>
Date: Wed, 16 Dec 1992 18:25:13 GMT
Distribution: usa
References: <1gilfkINNjmd@crcnis1.unl.edu> <BzA2sp.199@newsserver.technet.sg> <BzAyI5.BrH@world.std.com> <1992Dec15.144205.16197@mksol.dseg.ti.com>
Organization: Panix, NYC
Lines: 66