It has just occured to me that since C++ is a strongly typed language
it should provide intrinsic support for constants of all intrinsic types
that is currently we have:

  1 // int
  1U // unsigned int
  1L // long
  1UL // unsigned long
  '\1' // unsigned char -- it is unsigned since only
   // octal and hex bit patterns are allowed and
   // by default they are unsigned -- this may be
   // shakey logic, it may be implimentation dependent
   // on whether char is signed/unsigned, I admit
  '\1'L // wide unsigned char -- see above comment
  "\1" // unsigned char[]
  "\1"L // unsigned wide char -- w_chart is scheduled to
   // be an intrinsic type in ANSI/ISO C++

This as I see it leaves room for:

  1S // short
  1US // unsigned short
  1I // int -- this may not be really neccessary!
  1UI // unsigned int
  '\1'S // signed char -- see I'm following the spirit of C
   // and confusing programmers nicely by using S for both
   // short and signed!
  '\1'U // unsigned char
  '\1'SL // signed wide char
  '\1'UL // unsigned wide char
  "\1"S // signed char[]
  "\1"U // unsigned char[]
  "\1"SL // signed wide char[]
  "\1"UL // unsigned wide cahr[]

Ofcourse you can always have:

 (short) 1; // etc

and this may be more portable since you can then have:

 (int16) 1; // etc

where you typedef int16, etc to the correct type in some header somewhere which takes
care of compiler/OS/machine dependecies, but shouldn't you be able to do the other way
if you want? (Can any one send me the appropriate #define macro to convert 1INT32; to
1L or 1 depending on wether long is 32 or 64 bits?)
 Well just a though for the standards committee after all it shouldn't break any
existing code should it?

rodb@racerx.bridge.COM (Rod Burman) writes:

>It has just occured to me that since C++ is a strongly typed language
>it should provide intrinsic support for constants of all intrinsic types
>that is currently we have:

>  1 // int
>  1U // unsigned int
>  1L // long
>  1UL // unsigned long

OK so far.

>  '\1' // unsigned char ...

No.  This has type "char", a type distinct from both "signed char" and
"unsigned char".  It will usually have the same implementation as either
signed or unsigned char, you are not allowed to assume which.
Similarly, type int usually has the same implementation as either type
short or type long, but is always a type distinct from both.  Not all
current C++ implementations have the required three character types.

>  '\1'L // wide unsigned char ...

No.  It will have whatever type the implementation chose for wide
characters, and may be any signed or unsigned integral type.  There
is no "signed wide character" or "unsigned wide character" type, just
plain "wide character", which may behave as either a signed or an
unsigned type.

>  "\1" // unsigned char[]
>  "\1"L // unsigned wide char  ...

No to both.  See above.

>This as I see it leaves room for:

>  1S // short
>  1US // unsigned short

... etc.

>Ofcourse you can always have:

> (short) 1; // etc

>and this may be more portable ...

Well, I would say it is more general, rather than more portable.

You could make a symmetry argument for the additional suffixes, but
I don't see that they solve any problem.  Although this would not
break any existing code, it might create readability problems.

For example, I don't like using the lower-case 'l' suffix, since 2l
looks too much like 21.  Similarly, some type faces make 'S' or 's'
hard to distinguish at a glance from a '5', particularly when you
are not expecting to see the letter 's'.

Whenever a short value appears in an expression it is immediately
promoted to type int.  For example, let XX stand for any integer
literal representable as a short, and XXs be that value with type
short as you request.  Let Z be a value of any scalar type.  Then
the three expressions
 XX + Z
 (short)XX + Z
 XXs + Z
must always have exactly the same effect.  The 's' suffix does not
allow the compiler to take any shortcuts it could not take without
the suffix.  (The suffix can only be applied to a literal, so the
compiler already knows whether the value is representable as a short.)

The only place a "short" suffix could make a difference is in
choosing an overloaded function:
 int foo(int);
 int foo(short);
 ...
 foo(XX)  // calls foo(int)
 foo(XXs) // calls foo(short)
Of course, we can always write
 foo((short)XX) // calls foo(short)
for the rare cases when this arises.
--

Steve Clamage, TauMetric Corp, steve@taumet.com