Re: [boost] Re: Re: Adding Loki to Boost (reprise)

From: James S. Adelman (j.adelman_at_[hidden])
Date: 2002-04-16 14:11:36

On Tuesday 16 April 2002 6:12 pm, Noah Stein wrote:

> [ Dave Abrahams wrote: ]

> > > On Tuesday 16 April 2002 11:09 am, Alan Bellingham wrote:
> > > > j.adelman_at_[hidden]:
> > > > >Why is that a problem?  It is permitted and
> > > > >unambiguous, no more problematic than using long
> > > > >to mean long int.
> > > >
> > > > You mean 'signed long int'?
> > > >
> > > > <grin>
> > >
> > > Yes and no.  The name of the fundamental type is "long int" and
> >
> > "signed long
> >
> > > int" is merely a simple-type-specifier which specifies the type "long
> >
> > int".
> >
> > > In constrast "unsigned int" is a fundamental type, for which one of
> >
> > the
> >
> > > simple-type-specifiers is "unsigned".  See 3.9.2 [2] and 7.1.5.2 [1;
> >
> > Table 1].
> >
> >
> > It's nice to know the standard has a consistent and reasonable
> > definition of "simple" <.02wink>
> > I think I'll go write some python code now,
> >
> > where-things-are-underspecified-but-at-least-they-make-sense-ly y'rs,

To be clear, "unsigned," "unsigned int," "signed int," "int," "long int," 
"signed long int" are all simple-type-specifiers for fundamental types; the 
term simple refers to the lack of cv-qualifiers, etc..  The integral types 
are a subset of the fundamental types.  On the other hand, the signed 
integral types are "signed char," "short int," "int" and "long int."  This 
makes sense because if "char" were signed some things would break.

> Yes, and to add to this tangent, 3.9.1p1 states "Plain char, signed char,
> and unsigned char are three distinct types."  Strangely, 3.9p2 talks about
> how "... the underlying bytes making up the object can be copied into an
> array of char or unsigned char.  If the content of the array of char or
> unsigned char is copied back into the object, the object shall subsequently
> hold its original value."  I guess there's no requirement that this copying
> work properly with signed chars!  :)

Do you mean with signed chars as the source, or as the destination?  If you 
mean as source, this will work, as specified.  This does not negate the fact 
that they are different types, just as struct A { int a;}; and struct B {int 
a;}; are different types.  If you mean as destination, this could be 
impossible, as signed char could have fewer distinct values than unsigned 
char, for example, with sign-magnitude representation.  Then unsigned char 
a=2<<(CHAR_BIT-1); signed char b[1]; b[0]=a; if(b[0]==0) {a=3;} a=b[0]; might 
alter the value of a.

James