Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!uw-entropy!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.lang.c++
Subject: Re: initializing array of objects
Message-ID: <2026@dataio.Data-IO.COM>
Date: 22 Jun 89 18:59:18 GMT
References: <1284@cadillac.CAD.MCC.COM> <1000015@hpclscu.HP.COM>
Reply-To: bright@dataio.Data-IO.COM (Walter Bright)
Organization: Data I/O Corporation; Redmond, WA
Lines: 53

In article <1000015@hpclscu.HP.COM< shankar@hpclscu.HP.COM (Shankar Unni) writes:
<< bright@Data-IO.COM (Walter Bright) writes:
<< In article <1284@cadillac.CAD.MCC.COM< rpj@redcloud.cad.mcc.com (Rich Johns) writes:
<< <class Foo;
<< <Foo** fooArray;
<< <fooArray = new Foo*[100];
<< <for (int i = 0; i < 100; i++) fooArray[i] = 0;
<< <Is there a better way to initialize fooArray?
<< Try:
<< 	memset(fooArray,0,100 * sizeof(fooArray[0]));
<< or:
<< 	fooArray = (Foo**) calloc(100,sizeof(fooArray[0]));
<< Both are faster and generate less code.
<And both are non-portable.
<A NULL pointer does not have to have a bit-representation of all-zeroes.
<Admittedly this is rare, but I do know of a couple of such machines.
<"fooArray[i] = 0" initializes fooArray[i] to a NULL pointer value. 
<"memset" and "calloc" initialize fooArray[*] to all-zero bits.
<
<Try the following:
<   memset (fooArray, (Foo *) 0, 100*sizeof(Foo *));
<It's fast and correct.

Not quite. memset will set fooArray to whatever the least significant
byte of (Foo*)0 turns out to be. Also, (Foo*)0 on the PC can turn out
to be 32 bits, while memset expects a 16 bit value.

I've been involved frequently with porting code between Vaxes, PCs,
68000s, 386s and Sparcs, running various operating systems. None of these
have problems with (void*)0!=0bits. Based on experience, I don't care
about:
	1. 1's complement machines
	2. NULL pointers are not 0 machines
	3. 0.0 is not a 0 bit pattern machines
	4. EBCDIC
I worry about *real* porting problems:
	1. 68000's store bytes in the wrong :-) order
	2. int's are different sizes
	3. Properly declaring functions that return pointers
	4. Whether chars are signed or unsigned
	5. Care in passing pointers, ints and longs as function parameters
	6. K&R compilers (no prototyping, etc.)
	7. Properly using varargs (it matters on RISC machines)
	8. Operating system variations
	9. Non-virtual memory machines
	10. Text vs binary file modes

Someday I may run across the mythical machine with 0!=NULL, but I doubt it.
I don't waste time porting code to machines that do not have significant
market presence.

When talking portability, there is 'more portable' and 'less portable'.
It usually isn't black and white as in 'portable' and 'not portable'.