Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!att!cbnewsk!ech
From: ech@cbnewsk.ATT.COM (ned.horvath)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Think C 32K global data limit: workaround?
Message-ID: <1664@cbnewsk.ATT.COM>
Date: 17 Dec 89 05:49:55 GMT
References: <257@intek01.UUCP>
Organization: AT&T Bell Laboratories
Lines: 62

From article <257@intek01.UUCP>, by mark@intek01.UUCP (Mark McWiggins):
> We're getting discouraged with the speed of MPW C (especially with C++)
> and are interested in evaluating Think C as a target for C++ 2.0. 
> But the 32K global data limit is a concern.  Has anyone come up with 
> a satisfactory workaround?

This is a classic red herring in Macintosh programming: you aren't limited
to 32K of data space, just to 32K of named globals.  You can allocate any
amount of memory up to available RAM (or user-specified RAM partition under
Multifinder) by using NewPtr or, better, NewHandle.  The difference is

/* lazy, VAX-programmer method */
	int foo[20000];
/* enlightened, Mac programmer method */
	int *foo;
	... foo = NewHandle (20000 * (Size) sizeof *foo);
/* even more enlightened method */
	int *foo;
	/* figure out how big foo NEEDS to be */
	foo = NewHandle (whatzit * (Size) sizeof *foo);

The first method requires ungodly (>>32K) of global data space, and has the
additional disadvantage that it blows up when the problem size is 20001.
Which is probably your third customer.

The second method still breaks for 20001, but requires 4, count 'em 4, bytes
of global data space.  You're still limited to 8000 dynamic arrays, but I'll
bet you can live with that.

The third method reflects good programming practice and also needs only global
space for the pointer.  Oh, yeah: the second and third methods MUST be
followed by
	if (foo == NIL) {
		/* tell the user the bad news */
		/* fail in some nice fashion */
	}

If you need a huge initialized array, put it in a resource.  If you need a
huge, initialized, writeable array, put it in a resource, mark the resource
non-purgable, and DetachResource it so your program will continue to run
when some bright character at Apple figures out how to share resources
over a network.  Oh, yeah: make sure your GetResource succeeds in loading
that nasty array, same sad story and gentle termination in the face of
failure: this is the Mac, not Cleveland, to paraphrase Sam Wyche...

The only serious problem you face is that all extant O-O programming systems
on the Mac store their method-dispatch tables in global dataspace, so there's
the possibility that a very complex class hierarchy will blow you out of the
water.  MPW is no better than LSC in this respect, and until recently ALL
Object Pascal methods went in the (above A5) jump table at 8 bytes a pop,
another painful limit with even a moderatedly complex class structure.
I don't know if that latter situation has been corrected; I know there
was a lot of concern with it at Apple (perhaps Larry Rosenstein can comment).

One more shot from my favorite soapbox, and I'll shut up: Think, and just
about anybody else, will let you use classes in non-apps (DAs, XCMDs, etc).
So far, the MPW linker won't give non-apps globals, hence no method dispatch
tables.

Hope that helps.

=Ned Horvath=