Xref: utzoo comp.lang.c++:13185 comp.lang.c:38913
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!zaphod.mps.ohio-state.edu!rpi!uupsi!TALOS!jerry
From: jerry@talos.npri.com (Jerry Gitomer)
Newsgroups: comp.lang.c++,comp.lang.c
Subject: Re: 64 bit architectures and C/C++
Message-ID: <2110@talos.npri.com>
Date: 1 May 91 14:50:15 GMT
References: <168@shasta.Stanford.EDU> <6157@trantor.harris-atd.com>
Organization: NPRI, Alexandria VA
Lines: 34

mvm@jedi.harris-atd.com (Matt Mahoney) writes:

:When I need to specify bits, I'm usually forced to make the 
:following assumptions:

:	char	8 bits
:	short	16 bits
:	long	32 bits

:since this is true on most machines.  Anything else would probably break
:a lot of code.

	We are caught between the rock (wanting to take *full* advantage of
	the new wider register and memory data path machines 64 bits today,
	128 tomorrow, and 256 the day after tomorrow) and the hard place 
	(wanting to preserve code that was handcrafted to the
	idiosyncracies of prior generation hardware).  Our choices are
	simple -- throw the performance of the new machines out the window
	or spend the time and money required to fix up the code so that it
	complies with the standard.  (Sure, standards aren't cast in
	concrete, but their life exptancy exceeds that of today's typical
	computer system).

	IMHO (now isn't that an arrogant phrase? :-) ) it is better to fix
	up the offending programs now than to do it later.  I say this
	because I presume that salaries will continue to increase, which
	will make it more expensive to fix things up later, and because
	staff turnover leads to a decrease over time in knowledge of the
	offending programs.

-- 
Jerry Gitomer at National Political Resources Inc, Alexandria, VA USA
I am apolitical, have no resources, and speak only for myself.
Ma Bell (703)683-9090  (UUCP:  ...uunet!uupsi!npri6!jerry )