C# Byte/Short Mathematics

[NvrBst]

is there anyway to use bytes with numbers without actually casting at
the end?

byte Test = 10;
byte row = Test - 5;

Return Error: Cannot implicitly convert type 'int' to 'byte'. An
explicit conversion exists (are you missing a cast?)

I seen some integer-type-suffix's
ulong Test = 10;
ulong row = Test - 5UL;

But I only found "U" and "L"... meaning a number like "5" in "Test -
5" can only set to int / long (uint / ulong)? Whats the suffix's for
short and byte? Or just have to cast it at the end? (byte)(Test - 5)?

Thanks

[Peter Duniho]

On Wed, 13 Jun 2007 21:31:09 -0700, NvrBst <nv****@gmail.comwrote:

[...]
I seen some integer-type-suffix's
ulong Test = 10;
ulong row = Test - 5UL;

But I only found "U" and "L"... meaning a number like "5" in "Test -
5" can only set to int / long (uint / ulong)? Whats the suffix's for
short and byte? Or just have to cast it at the end? (byte)(Test - 5)?

I'm not aware of a specifier to define a byte constant (other than, of
course, making a named constant of type byte).

However, I'll point out that instead of casting the result of your
calculation, you can cast the constant itself so that the entire
calculation is done with bytes:

byte row = Test - (byte)5;

That way, Test isn't promoted to int, and the expression itself winds up
with type byte instead of type int.

Pete

[Ben Voigt [C++ MVP]]

"NvrBst" <nv****@gmail.comwrote in message
news:11*********************@n15g2000prd.googlegro ups.com...

is there anyway to use bytes with numbers without actually casting at
the end?

byte Test = 10;
byte row = Test - 5;

Return Error: Cannot implicitly convert type 'int' to 'byte'. An
explicit conversion exists (are you missing a cast?)

I seen some integer-type-suffix's
ulong Test = 10;
ulong row = Test - 5UL;

But I only found "U" and "L"... meaning a number like "5" in "Test -
5" can only set to int / long (uint / ulong)? Whats the suffix's for
short and byte? Or just have to cast it at the end? (byte)(Test - 5)?

You have to cast it at the end, because the operands are always promoted.
Even with a byte constant you end up with an int result. Peter is wrong
about this one.

I'm convinced this is a bug, but it is designed into the C# specification.

>
Thanks

[Jon Skeet [C# MVP]]

Peter Duniho <Np*********@nnowslpianmk.comwrote:

However, I'll point out that instead of casting the result of your
calculation, you can cast the constant itself so that the entire
calculation is done with bytes:

byte row = Test - (byte)5;

That way, Test isn't promoted to int, and the expression itself winds up
with type byte instead of type int.

No, both are promoted. Try it and see:

using System;

class Test
{
static void Main()
{
byte test = 10;
byte row = test - (byte)5;
}
}

Test.cs(8,20): error CS0266: Cannot implicitly convert type 'int' to
'byte'. An explicit conversion exists (are you missing a cast?)

Basically there's no operator byte +(byte, byte). Instead, the operands
are promoted and int +(int,int) is used.

The exception to this is using += and -= :

using System;

class Test
{
static void Main()
{
byte test = 10;
test += 5;
}
}

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Peter Duniho]

On Wed, 13 Jun 2007 23:24:34 -0700, Jon Skeet [C# MVP] <sk***@pobox.com>
wrote:

[...]
Basically there's no operator byte +(byte, byte). Instead, the operands
are promoted and int +(int,int) is used.

Ugh. Really? Sheesh.

[Peter Duniho]

On Wed, 13 Jun 2007 22:01:46 -0700, Ben Voigt [C++ MVP]
<rb*@nospam.nospamwrote:

[...]
Peter is wrong about this one.

I'm convinced this is a bug, but it is designed into the C#
specification.

I'll be happy to sign the petition. :)

[Jon Skeet [C# MVP]]

On Jun 14, 8:12 am, "Peter Duniho" <[e-mail]>
wrote:

Basically there's no operator byte +(byte, byte). Instead, the operands
are promoted and int +(int,int) is used.

Ugh. Really? Sheesh.

I *believe* it's for performance reasons. Processors natively add 32
bit values together with appropriate overflow handling - adding the 8
bit values and then "manually" handling the overflow would be slower
than just treating them as 32 bit values and letting the user add the
overflow handling *where required*.

At least, that's what I've heard before (from people who know). I'm
not saying it's the best decision in the world - language choices
being affected by performance rarely are - but that's the reason I've
heard used pretty frequently.

Jon

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Jon Skeet [C# MVP] wrote:

On Jun 14, 8:12 am, "Peter Duniho" <[e-mail]>
wrote:

>>Basically there's no operator byte +(byte, byte). Instead, the operands
are promoted and int +(int,int) is used.

Ugh. Really? Sheesh.

I *believe* it's for performance reasons. Processors natively add 32
bit values together with appropriate overflow handling - adding the 8
bit values and then "manually" handling the overflow would be slower
than just treating them as 32 bit values and letting the user add the
overflow handling *where required*.

AFAIK, modern ALUs are even incapable of byte arithmetic. :)

At least, that's what I've heard before (from people who know). I'm
not saying it's the best decision in the world - language choices
being affected by performance rarely are - but that's the reason I've
heard used pretty frequently.

Jon

--
Göran Andersson
_____
http://www.guffa.com

[Peter Duniho]

On Thu, 14 Jun 2007 00:33:17 -0700, Jon Skeet [C# MVP] <sk***@pobox.com>
wrote:

I *believe* it's for performance reasons. Processors natively add 32
bit values together with appropriate overflow handling - adding the 8
bit values and then "manually" handling the overflow would be slower
than just treating them as 32 bit values and letting the user add the
overflow handling *where required*.

I can understand there being a performance issue. I can't understand the
compiler imposing that on the programmer.

To me, the type promotion as it's applied to the code need not match the
type promotion as it's applied to the implementation. Semantically, it
would make sense to allow adding two bytes, so the operator should exist.
If the implementation of the operator was done to promote both operands,
and then demote the results, I wouldn't have a problem with that. But why
exclude the operator altogether?

Pete