a += b vs a = a + b

[wizofaus]

Compiles:

short a = 1;
a += 2;

Does not:

short a = 1;
a = a + 2;

(Cannot implicitly convert type 'int' to 'short').

Does this not strike anyone as little incongruent?
I assume the rules for type promotion after arithmetic are documented
somewhere, but it appears to be...

[sbyte|short|int] + [byte|short|int] = int // true for + - * /
[sbyte|short|int|long] + long = long
[sbyte|short|int|long|float] + float = float
[sbyte|short|int|long|float|double] + double = double

(unsigned types behave as per their signed relatives)

Even

a = a + (short)2;

does not compile; you need:

a = (short)(a + 2);

As a C++ programmer, the return of the old "C" cast syntax (which I
haven't used for over 5 years) is definitely the least appealing part
of C#, but there seems to be no way to avoid it.

 

[Peter Gummer]

As a C++ programmer, the return of the old "C" cast syntax (which I
haven't used for over 5 years) is definitely the least appealing part
of C#, but there seems to be no way to avoid it.

Although I dislike casts and welcome the belated arrival of generics, I
think it's only fair to point out that C# casts are not as dangerous as
the old C casts. C# casts explode in your face immediately, with an
InvalidCastException and a nice stack trace; whereas those old C casts
had the nasty habit of complying with stupid requests, only to blow up
behind your back some time later, possibly trashing memory along the
way. C# casts are _much_ easier to debug.

An aversion to casts is healthy, but we old-time C programmers fear
them more than we really need to these days

-- Peter Gummer

 

[wizofaus]

Although I dislike casts and welcome the belated arrival of generics, I
think it's only fair to point out that C# casts are not as dangerous as
the old C casts. C# casts explode in your face immediately,

They do? To me "immediately" implies at compile time!
At least 4 or 5 times I tried using C# casts, the compiler should have
been able to detect I wasn't using them correctly (i.e., it was quite
obvious from a static analysis).

with an
InvalidCastException and a nice stack trace; whereas those old C casts
had the nasty habit of complying with stupid requests, only to blow up
behind your back some time later, possibly trashing memory along the
way. C# casts are _much_ easier to debug.

I pretty much always use checked C++ casts that do the same thing (at
least in Debug builds), in the very *rare* occasions I ever need to
explicitly cast. So I don't see that C# has an advantage here
particularly, except that the checking support is built in to the
language.

 

[Jon Skeet [C# MVP]]

Compiles:

short a = 1;
a += 2;

Does not:

short a = 1;
a = a + 2;

(Cannot implicitly convert type 'int' to 'short').

Does this not strike anyone as little incongruent?
I assume the rules for type promotion after arithmetic are documented
somewhere, but it appears to be...

Yes, they're documented in the language spec, section 14.7.4 (ECMA
numbering):

<quote>
int operator +(int x, int y);
uint operator +(uint x, uint y);
long operator +(long x, long y);
ulong operator +(ulong x, ulong y);
....
float operator +(float x, float y);
double operator +(double x, double y);
</quote>

The reason a+=2 works is due to 14.13.2:

<quote>
An operation of the form x op= y is processed by applying binary
operator overload resolution (§14.2.4) as if the operation was written
x op y. Then,

* If the return type of the selected operator is implicitly
convertible to the type of x, the operation is evaluated as x = x op y,
except that x is evaluated only once.
* Otherwise, if the selected operator is a predefined operator, if
the return type of the selected operator is explicitly convertible to
the type of x, and if y is implicitly convertible to the type of x,
then the operation is evaluated as x = (T)(x op y), where T is the type
of x, except that x is evaluated only once.
* Otherwise, the compound assignment is invalid, and a compile-time
error occurs.
</quote>

In this case, the return type of the operator (int) is explicitly
convertible to short, and 2 is implicitly convertible to short, so it's
evaluated as

a = (short) (a+2);

 

[wizofaus]

Yes, they're documented in the language spec, section 14.7.4 (ECMA
numbering):

<quote>
int operator +(int x, int y);
uint operator +(uint x, uint y);
long operator +(long x, long y);
ulong operator +(ulong x, ulong y);
...
float operator +(float x, float y);
double operator +(double x, double y);
</quote>

Ok, so what's the justification? Why the expression (short_var + 2)
more likely to produce something that won't fit into a short than the
expression (short_var +=2)?

But more importantly, why is this "unsafe":

short var = get_a_short();
var = (var - 1) / 2;

But this, fine:

int var = get_an_int();
var = (var * 0x10000) + 0x1000000;

Surely the latter is far more likely to produce a type overflow?

 

[Peter Gummer]

I pretty much always use checked C++ casts that do the same thing (at
least in Debug builds), in the very rare occasions I ever need to
explicitly cast. So I don't see that C# has an advantage here
particularly, except that the checking support is built in to the
language.

The comparison I was making was with C, not C++. C# casts are a big
improvement over C casts.

As to C++, I suspect you're right. I accept your complaint that C#
casts are a backwards step from alternatives available in C++. But, as
I've pointed out, returning to the old C cast _syntax_ does not imply a
return to the old C cast _semantics_: thank goodness!

-- Peter Gummer

 

[Jon Skeet [C# MVP]]

(e-mail address removed) wrote:

Ok, so what's the justification? Why the expression (short_var + 2)
more likely to produce something that won't fit into a short than the
expression (short_var +=2)?

I don't think it's actually a safety issue. I think it's a performance
issue. If the type of the expression (shortVar+2) were "short" rather
than "int", the expression would have to be evaluated in 16 bits, which
is slower on many processors than using 32 bits. In the case of doing
+=, the language itself knows (with no extra information such as where
you're using the operator - it only needs to look at the operands of
the operator itself) that the result *must* be converted to 16 bits.

That's only a suspicion, admittedly. I can ask MS to enter the
discussion at this point if you'd like. (I can't guarantee they will,
but I can ask...)

Jon

 

[wizofaus]

(e-mail address removed) wrote:



I don't think it's actually a safety issue. I think it's a performance
issue. If the type of the expression (shortVar+2) were "short" rather
than "int", the expression would have to be evaluated in 16 bits, which
is slower on many processors than using 32 bits. In the case of doing
+=, the language itself knows (with no extra information such as where
you're using the operator - it only needs to look at the operands of
the operator itself) that the result *must* be converted to 16 bits.

Ok, but that's a compiler optimization issue, nothing to do with the
language.
I would expect that if I were compiling specifically for a machine
where 16 bit arithmetic was faster, it would use that (even for 32 bit
and 64 bit values values).

That's only a suspicion, admittedly. I can ask MS to enter the
discussion at this point if you'd like. (I can't guarantee they will,
but I can ask...)

Well I'm definitely curious. In the whole 3 or 4 days now that I've
written any C# code, I never had to sprinkle my code with so many ugly
(and logically unnecessary) casts!

 

[Peter Gummer]

Well I'm definitely curious. In the whole 3 or 4 days now that I've
written any C# code, I never had to sprinkle my code with so many ugly
(and logically unnecessary) casts!

But why are you using 'short' in the first place? The question you've
raised is interesting, but I always use 'int' for whole numbers unless
I have a very specific reason to do otherwise. Hence, I've never even
encountered this issue ... and so I thank you for drawing it to my
attention ;-)

- Peter Gummer

 

[wizofaus]

But why are you using 'short' in the first place? The question you've
raised is interesting, but I always use 'int' for whole numbers unless
I have a very specific reason to do otherwise. Hence, I've never even
encountered this issue ... and so I thank you for drawing it to my
attention ;-)

Why does "short" exist in the language if it's not meant for regular
use?
The values I'm dealing with most definitely fall well within the range
of a short integer.
I also happen to need to store a lot of them, and the memory savings
are definitely worthwhile (well, they were in the original C++ code I
was converting from. Not sure if the same would be true under C#).

 

[Jon Skeet [C# MVP]]

Ok, but that's a compiler optimization issue, nothing to do with the
language.

No, it's not. There's a semantic difference at stake here - if
shortVar+2 should evaluate to a short, that is very different in
observed behaviour from "wrapping" (or throwing an exception, depending
on whether the context is checked or unchecked) and simply overflowing
into the 17th bit.

I would expect that if I were compiling specifically for a machine
where 16 bit arithmetic was faster, it would use that (even for 32 bit
and 64 bit values values).

It can't - not when shortVar+2 could cause overflow into 32 bits.

Well I'm definitely curious. In the whole 3 or 4 days now that I've
written any C# code, I never had to sprinkle my code with so many ugly
(and logically unnecessary) casts!

I'll ask MS tomorrow.

 

[wizofaus]

No, it's not. There's a semantic difference at stake here - if
shortVar+2 should evaluate to a short, that is very different in
observed behaviour from "wrapping" (or throwing an exception, depending
on whether the context is checked or unchecked) and simply overflowing
into the 17th bit.


It can't - not when shortVar+2 could cause overflow into 32 bits.

All I'm saying is that

shortVar = shortVar + 2;

should be logically equivalent to (and just as safe/acceptable as)

shortVar = (short)(shortVar + 2);

After all, even in C++,

int iVar = shortVar + 2;

and

int iVar = shortVar + short(2);

will produce the correct result (no overflowing) even if shortVar is
SHRT_MAX (and even if '2' is stored in a 'short' variable).

Having said this, I'm not sure if this is guaranteed to be true on all
platforms. But at least with VC 7.1 and g++ on a Pentium chip, it's
true.

 

[wizofaus]

After all, even in C++,

int iVar = shortVar + 2;

and

int iVar = shortVar + short(2);

will produce the correct result (no overflowing) even if shortVar is
SHRT_MAX (and even if '2' is stored in a 'short' variable).

Having written this, I think I can now see that the type promotion
rules for arithmetical expressions in C# are exactly the same as those
in C/C++.
Given this, and the fact that it's obviously a key "feature" of C# that
types cannot be automatically demoted (you have to explicitly cast from
a 'larger' type to a 'smaller' type), then the difference between
shortVar += 2 and shortVar + 2 is understandable.
The only solution I can see is that type promotion via an arithmetical
expression should not have the same status as a declared type.
That is, while it's true that (shortVar + 2) is type int, it's never
been "declared" int (via a variable or a function prototype), so can
still be silently downgraded to...well...in this case, obviously a
short, but this would really mean that the type of an arithmetical
expression
has both a "value-size" type (i.e. int), and a conversion type (in this
case short).
I wouldn't have an issue with, for instance,

byte b = shortVar + 2;

not compiling.

I guess I'm just going to have to avoid anything else other than ints
if I want my code to be readable. I can't see myself using C# for
anything where using shorts would be really that important anyway.

 

[Peter Gummer]

Why does "short" exist in the language if it's not meant for regular
use?

By all means use it. It sounds like it's appropriate in this case,
since I assume you'd get the same worthwhile memory saving in C# that
you saw in C++.

I didn't say "it's not meant for regular use". I said use short only if
you have a very specific reason; it sounds like you have such a reason.
This was a policy I adopted long ago in standard C, and have seen good
sense in keeping to when programming in a variety of languages: Delphi,
C# and Eiffel. It just avoids issues that seem to crop up in most
languages.

-- Peter Gummer