Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!fernwood!dumbcat!marc
From: marc@dumbcat.sf.ca.us (Marco S Hyman)
Newsgroups: comp.lang.c++
Subject: Re: 64 bit architectures and C/C++
Message-ID: <297@dumbcat.sf.ca.us>
Date: 4 May 91 17:36:53 GMT
References: <224@tdatirv.UUCP> <1991Apr29.140256.27605@cbnewsh.att.com>
	<230@tdatirv.UUCP> <295@dumbcat.sf.ca.us> <226@tdatirv.UUCP>
Organization: MH Software, Hayward, CA.
Lines: 28

In article <226@tdatirv.UUCP> sarima@tdatirv.UUCP (Stanley Friesen) writes:
 > Binary communication between machines should use XDR *not* C structures.

Agreed.  (But please, not ASN.1/BER as someone else suggested :-)

 > First, C has this concept called bit fields, which can be of any size you
 > want - so if you *must* have a 16-bit quantity, use a 16-bit bit field.
 > (This also answers the previous objection - if you *must* be machine
 > dependent, at least make it stand out).

And in article <230@tdatirv.UUCP> sarima@tdatirv.UUCP (Stanley Friesen) writes:
 > Remember if *bits* are important use bitfields

The problem with using bit fields is that they might not be able to overlap
the <allocation unit> boundary (ARM, pg 184-185: remember, we're talking C++
here) and that a programmer cant tell from looking at the code if the first
field is placed in the high order bits or the low order bits.  I suppose the
former problem doesn't count because we want _smaller_ fields and since we are
being machine dependent by using bit fields the last is not much of a problem
either.

These days I tend to think in terms of embedded processors with lots of low
level peripheral device interface code.  A '64-bit only' processor would not
be an good match in this environment.
-- 
// marc
// home: marc@dumbcat.sf.ca.us		pacbell!dumbcat!marc
// work: marc@ascend.com		uunet!aria!marc