🚀 go-pugleaf

In article rba@news.csus.edu, dick@silicon.csci.csusb.edu (Dr. Richard Botting) writes:
>
>However, you mentioned:
>: and they require at least the following ranges of each type:
>Does this allow someone to have larger ranges (more bits)?
>For example 66 bit ints (the fastest fixed point on a CDC Cyber)
>certainly includes: -32767 .. 32767

Yes, of course. This was true in C as well. The requirements are that
	sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
They are allowed to be all the same size, for example, and you can look
in K&R1 to find examples. This situation -- no predetermined size for
any built-in type -- has been true since the beginning of C, and is
still true in C++.

>Any way I guess we can always
>	enum{ lo=-32767, hi=32767} signed16bit;
>and so on?

There is no requirement that any type have a specific number of bits;
the only requirements are pure binary encoding and specified minimum ranges.
For one thing, a specific number of bits might be impossible on
some architecture. A 36-bit machine, for example, won't have a 16-bit
data type. It might have 9-bit bytes and an 18-bit data type.

If you need to restrict yourself to a fixed number of bits to match
an external data format, you can use bitfields in a struct. Such code
is inherently unportable (byte size, byte order, padding requirements, 
1's complement vs 2's complement, etc) and should be restricted to
interface modules that may need to be recoded for each new platform.
In portable code, assume only the minimum ranges required by the standard.

That problem is particularly easy to resolve in C++. Create a class that
manages the bit-fiddling, and reimplement only that class for each
different architecture. The remainder of the source code is unchanged.
---
Steve Clamage, stephen.clamage@eng.sun.com



[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]