Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!mintaka!mit-eddie!uw-beaver!sumax!amc-gw!nwnexus!pilchuck!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.lang.c++
Subject: Re: C++ comparison
Message-ID: <2670@dataio.Data-IO.COM>
Date: 27 Aug 90 19:11:18 GMT
References: <2119@trlluna.trl.oz> <1990Aug24.181159.19680@cs.columbia.edu>
Organization: Data I/O Corporation; Redmond, WA
Lines: 29

In article <1990Aug24.181159.19680@cs.columbia.edu> kearns@cs.columbia.edu (Steve Kearns) writes:
<* the compiler (Zortech) does not support huge pointers, meaning that it is
<extremely cumbersome (and non-portable) to access data structures
<larger than 64K bytes.  For example, an array of structures, each
<structure 16 bytes long, would be limited to 4000 entries.  I guess I
<will try making a C++ class to simulate a huge pointer, since the
<application I am porting requires huge pointers.

Let's say you want an array of 16000 16 byte structs. Here's how to do
it portably without the overhead of huge pointers:

	struct S *arrayp[4];
	#define array(i) arrayp[(unsigned)i/4000][(unsigned)i%4000]

	/* Initialize: */
	for (i = 0; i < sizeof(array) / sizeof(array[0]); i++)
		array[i] = (struct S *) malloc(sizeof(struct S) * 4000);

Adjusting the value 4000 so it is a power of 2 makes the *,/ and %
turn into shifts.
To use, array(i) instead of array[i]. It will work as both an lvalue
or an rvalue. I would argue that it is both more space efficient and is
much faster than using huge arithmetic. It also does not suffer from the
problems that you get with huge model if sizeof(struct S) does not divide
into 64k evenly.

I've helped several people convert their code to Zortech from using huge
pointers, and this method, or minor variations of it, usually works fine.
I hope this helps...