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

From: Noah Stein (noah_at_[hidden])
Date: 2002-04-16 12:12:04

> -----Original Message-----
> From: boost-admin_at_[hidden] [mailto:boost-admin_at_[hidden]]On
> Behalf Of David Abrahams
> Sent: Tuesday, April 16, 2002 4:45 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Re: Re: Adding Loki to Boost (reprise)
>
>
>
> ----- Original Message -----
> From: "James S. Adelman" <j.adelman_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Tuesday, April 16, 2002 6:11 AM
> Subject: Re: [boost] Re: Re: Adding Loki to Boost (reprise)
>
>
> > 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,

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!  :)

-- Noah