Note the special treatment given to char and short:

char c;        short s;      int i;        long l;
c = 'A';       s = 5;        i = 7;        l = 8L;
c = c + 'B'    s = s + 2;    i = i + 2;    l = l + 2
ILLEGAL        ILLEGAL       OKAY          OKAY

Because of the "+" operator, we get integral promotion of
c=c+'B' and s=s+2 to int on both sides of the "+" and
following the addition we have truncation when assigning the
int back to the char or short.

Why not allow a char plus a char equal a char, or a short plus
a short equal a short, just like an int plus an int DOES equal
and int and a long plus a long DOES equal a long.

To avoid warnings, you must use a cast:
c = (char)(c + 'B');        s = (short)(s + 2);
which is absurdly stupid and unnecessary.  Why arbitrarily and
artificially force integral promotion of a char or short to an
int prior to the addition?

Stated another way, why drag into the strong type checking of
C++ an artificial limitation of ANSI C (A6.1 in K&R 2nd
edition) on type checking which blindly hacks two perfectly
good short's into int's?  Notice the wording (same reference
A6.1): "A character, a short integer, or an integer bit-field,
all either signed or not, or an object of enumeration type,
may be used in an expression wherever an integer may be used."

This was a GOOD THING in ANSI C because we could burden that
poor "+" operator to work on several data types smaller than
int's -- but of course we have to promote everything to an int
for that poor "+" operator to know what to do with it!

This kind of thinking is unnecessary in C++ and the automatic
integral promotion to ease the burden on the "+" operator is
no longer necessary in C++ when both sides to the "+" are the
same and smaller than an int.

If we can now come up with our own types that allow definition
of:
     xchar operator+ (xchar, xchar)
where xchar is really just a char, then why force the built-in
types to operate on nothing smaller than an int?  They
certainly are capable of operating on a number of different
data types in C++ and we need to throw out integral promotion
when both sides of the "+" are both char or both short.  The
same holds true for "-" as well.

Thanks for your comments,  Max Polk




---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

MaxPolk@megaweb.com (Max Polk) writes:

>Note the special treatment given to char and short:
>
>char c;        short s;      int i;        long l;
>c = 'A';       s = 5;        i = 7;        l = 8L;
>c = c + 'B'    s = s + 2;    i = i + 2;    l = l + 2
>ILLEGAL        ILLEGAL       OKAY          OKAY

Excuse me, but where did you get the idea that the first two
examples are illegal?

>Why not allow a char plus a char equal a char, or a short plus
>a short equal a short, just like an int plus an int DOES equal
>and int and a long plus a long DOES equal a long.

I agree that this would not be such a bad idea.
However, in defence of the status quo, the above four examples
are all quite legal in C++, so you have not yet demonstrated
any real practical problems arising from the status quo.

>To avoid warnings, you must use a cast:
>c = (char)(c + 'B');        s = (short)(s + 2);
>which is absurdly stupid and unnecessary.

Agreed, but again in defense of the status quo this is a
quality-of-implementation issue.  Such warnings are not
mandated by the standard, and it would certainly be possible
for a C++ compiler to issue warnings about

 int i;
 char c = i;

without issuing warnings in the above cases.
I suggest you send your vendor an enhancement request.

--
Fergus Henderson             |  "Australia is the richest country in the world,
fjh@cs.mu.oz.au              |   according to a new system of measuring wealth
http://www.cs.mu.oz.au/~fjh  |   announced by the World Bank yesterday."
PGP: finger fjh@128.250.37.3 |  - Melbourne newspaper "The Age", 18 Sept 1995.
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]