🚀 go-pugleaf

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