🚀 go-pugleaf

dick@silicon.csci.csusb.edu (Dr. Richard Botting) wrote:

[ talking about required ranges of arithmetic types ] 

>: (With plain `char' having the same range as either `signed char' or
>: `unsigned char', but being of a type distinct from either.)
>: (ISO C: 5.2.4.2.1, referred to by r.2.3 and r.3.6.1 in C++PL2 )

>This must be a later version than the working papers I've got available..
>I searched for 32767 but did not extract this info.

No - this is from the C standard, and The C++ Programming Language, 2nd
ed.  If the committee has actually changed this to remove the
requirement, then 1) I'm quite surprised, and 2) I think they completely
screwed up in so doing.  I guess I'll have to go grab a copy of the DWP
and see if I can find whether the requirements are still there, or have
been eliminated in C++.

>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

>I hope not... 

It may be unfortunate, but yes that's allowable.  For instance, the last
time I looked, on a Cray, char was 8 bits, and short, int and long were
all 64 bits.  There's nothing in the standard to prevent this.  Earlier
versions of their C compiler even had 64 bit chars, and were still
legal.  (All of this is going by the C standard for the moment -- once I
grab a copy of the DWP, I'll see if I can find any more in it, but my
guess would be that there isn't likely to be any real change.)

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

I'm not sure how much it accomplishes, but that certainly looks legal.
This should be as well:

class int16 {
	short contents:16;
public:
	// whatever...
};
	
but once again, it may or may not accomplish much.
    Later,
    Jerry.

/* I can barely express my own opinions; I certainly can't
 * express anybody else's.
 *
 * The universe is a figment of its own imagination.
 */


[ 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. ]