09 Oct 96 04:42, David Nugent wrote to andrew clarke:

 >> > Depends on what you call a byte.

 >> "Byte --- the unit of data storage in the execution
 >> environment large enough to hold any member of the basic
 >> character set of the execution environment."

 > I've always defined one byte - or, strictly, "octet" - is 8 bits. 
 > Therefore char != byte on all platforms, so I guess it does indeed come 
 > down to what you call a "byte".

When in Rome...

 > Code breakage in the year 2000 will probably be nothing compared to a 
 > change to 32-bits as the basic sizeof(int).

It will be some time before we see sizeof(int) > 4 on a regular basis. 
By that time it may well be less relevant to the majority of computer
programmers than it is today as system-independant languages such as Java
(and languages yet to be formed) become more prevalent.  It's quite likely
that many computer users will stick with 32-bits systems for lack of a good
reason to upgrade to 64-bits.  There is plenty of life left in the 32-bit
world; mainstream PC users (notably those of the Wintel variety) are only
beginning to reap the benefits of 32-bit programming.

 > Unfortunately, there's a *lot* of code out there that isn't portable,
 > but that I guess is a headache the maintainers have to face when the
 > time comes.

Teachers and students of computer programming in general still have a lot
to learn regarding the importance of portability.  I guess it's a bit like
First Aid, you may never use it, but it could well save your life.  :-)

In the long term portability at a software level will probably become a
non-issue, especially once 64-bit systems become well established.  I am
thinking a few decades from now though.  Much of the portability issues may
well be solved at the hardware level than in software.  It seems like the
logical place to me.  With any luck it should allow programmers to get on
with more productive tasks, and not have them worry about the inevitable
change in hardware.

 > The realities of publishing code is that usually it becomes a trade-off 
 > between getting something working sooner and perhaps spending the 
 > energy later in porting it to a different environment. Sometimes that 
 > energy never need be expended at all since the half-life of most code 
 > isn't very long.

Some programmers tend to ignore that fact and hack away regardless,
producing non-reusable code, or code that needs so many modifications to be
reused that it might as well be rewritten (with the end result often being
lack of functionality compared to the original).  I would hope that would
not always be the case.

Regards
Andrew

-- randy{at}zws.com

--- Msged/2 4.00