Thoughts on unified integer literal improvements

brucechapman at paradise.net.nz brucechapman at paradise.net.nz
Mon Jun 29 19:25:00 PDT 2009


Quoting Weijun Wang <Weijun.Wang at Sun.COM>:

> > long ell = 0xFFFFFFFFu; // A positive long value
> 
> Any particular requirement here? Why not simply
> 
>  long ell = 0xFFFFFFFFl;
> 
> > 
> > I think this approach has some advantages over the "y" suffix; in 
> > particular I think it gives more desirable behavior in cases like
> this:
> > 
> > byte b = 0xFFy // a negative byte value
> > byte b = 0xFFu // also a negative byte value
> > 
> > short s = 0xFFy // a negative short value, -128;
> > // byte value is signed extended
> > short s = 0xFFu // a positive short value, +127
> > 
> > int i = 0xFFy // -128
> > int i = 0xFFu // 127
> 
> Does this mean the actual value of 0xFFu is determined by looking at
> the
> LHS of the assignment? This is terrible.

Yes that would be terrible if it were true, fortunately it is not. The value is
determined by the digits and any radix specified by the prefix.  In the above
examples, the "y" suffix means byte, so when is widened to a short or int it
sign extends and stays negative. The "u" suffix would create a special type that
would always zero extend when widening giving a positive number.

> 
> I'd rather use something like 0bXX which is itself always a byte
> literal.

But that is inconsistent, prefixes currently determine radix, suffixes determine
type. Also the binary literals part of the proposal is using 0b as a prefix for
binary literals so 0bXX is an int.

Bruce

> 
> Max
> 
> > 
> > -Joe
> > 
> 
>  




More information about the coin-dev mailing list