Why is a cast required for byte subtraction in C#?

Question

I have to following code in VS2008 .net 3.5 using WinForms:

byte percent = 70;
byte zero = 0;

Bitmap copy = (Bitmap)image1.Clone();
...

Color oColor = copy.GetPixel(x, y);
byte oR = (byte)(oColor.R - percent < zero ? zero : oColor.R - percent);

When I leave the "(byte)" off the last line of code, I get a compiler error saying it "Cannot implicitly convert type 'int' to 'byte'." If everything is of type byte and byte is an integer type... then why do I need to have the cast?

Eric Lippert says, "I don't think of bytes as "numbers"; I think of them as patterns of bits that could be _interpreted_ as numbers, or characters, or colors or whatever. If you're going to be doing math on them and treating them as numbers, then it makes sense to move the result into a data type that is more commonly interpreted as a number." See http://stackoverflow.com/questions/941584/byte-byte-int-why-c . — Brian, Jun 03 '09 at 13:26
You guys do realize you've marked this as a duplicate even though it was asked *before* the "already has an answer here" link? — Charlie Martin, Nov 26 '13 at 22:13
Hell, now it even says "asked before" even though the other question was asked three years later. — Charlie Martin, Sep 18 '15 at 19:52
Uh, actually, *every* data value is a bit pattern that can be interpreted as a number. — Charlie Martin, Sep 18 '15 at 19:54

score 16 · Accepted Answer · answered May 29 '09 at 18:19

16

Because subtraction is coercing up to an integer. As I recall, byte is an unsigned type in C#, so subtraction can take you out of the domain of bytes.

answered May 29 '09 at 18:19

Charlie Martin

110,348
25
193
263

4

Subtraction can take you out of the domain of every number type. That doesn't really explain why there is no byte-specific subtraction operator. – John Gietzen Sep 18 '15 at 17:02
1

Well, then, the answer is "because the developers of C# decided they didn't want one." – Charlie Martin Sep 18 '15 at 19:50

score 11 · Answer 2 · answered May 29 '09 at 18:20

11

That's because the result of a byte subtraction doesn't fit in a byte:

byte - byte = (0..255) - (0..255) = -255..255

answered May 29 '09 at 18:20

schnaader

49,103
10
104
136

1

What a nice graphic explanation !!! – Jhonny D. Cano -Leftware- May 29 '09 at 18:23
21

Neither does any integer type except floats or decimals. int is of finite range too, so (min_int - max_int) wont fit, but it returns an int. – Adam Frisby May 29 '09 at 18:24
3

@Adam: 1) floats and decimals are not integer types. 2) Results of subtractions for these also may not fit, as these also have a finite (though large) range. – Brian Jun 03 '09 at 13:24

score 8 · Answer 3 · answered May 29 '09 at 18:18

8

Arithmetic on bytes results in an int value by default.

answered May 29 '09 at 18:18

Timothy Carter

15,459
7
44
62

3

Link is dead... – chtenb Oct 10 '17 at 08:35
1

@Timothy Cartner, Link only answers are not recommended on SO, For the reason it stands now for a year, with a broken link. Could you provide some context? – Rafael Herscovici Aug 07 '18 at 12:05

score 4 · Answer 4 · answered May 29 '09 at 18:19

Because arithmetic on bytes returns integers by default so of the two possible assignments the narrower type of zero (byte) is promoted to int (that of oColor.r - percent). Thus the type of the operation is an int. The compiler will not, without a cast, allow you to assign a wider type to a narrower type, because it's a lossy operation. Hence you get the error, unless you explicitly say "I know I'm losing some data, it's fine" with the cast.

Andrew Hare · Answer 5 · 2009-05-29T18:23:35.193

3

This is because byte subtraction returns an int. Actually any binary arithmetic operations on bytes will return an int, so the cast is required.

edited May 29 '09 at 18:23

answered May 29 '09 at 18:18

Andrew Hare

344,730
71
640
635

I think that's subtraction, actually.... – Charlie Martin May 29 '09 at 18:20
Oops - thanks Charlie, I corrected it. – Andrew Hare May 29 '09 at 18:20
Wasn't me, at least. I think we're having a random downvoter, I got one too. – Charlie Martin May 29 '09 at 18:29

score 2 · Answer 6 · answered May 29 '09 at 18:24

Because arithmetic operations on sbyte, byte, ushort, and short are automatically converted to int. The most plausible reason for this is that such operations are likely to overflow or underflow.

Thus, in your ternary operation, the final oColor.R - percent, actually results in an int, not a byte. So the return type of the operation is int.

score 1 · Answer 7 · answered Jul 04 '09 at 00:39

1

Try to run this C# code: object o = (byte)(1); o = (int)o; What do you expect? Now try :)

I think this is right:

Eric Lippert says, "I don't think of bytes as "numbers"; I think of them as patterns of bits that could be interpreted as numbers, or characters, or colors or whatever. If you're going to be doing math on them and treating them as numbers, then it makes sense to move the result into a data type that is more commonly interpreted as a number."

Perhaps byte is closer to char than to int.

answered Jul 04 '09 at 00:39

2

You could use the same logic for short, int and long. They are also strings of bits which could be interpreted as numbers. – David Klempfner May 21 '18 at 11:41
1

Try telling that to someone who remembers 8 bit computing. Excepting sbyte, there is no 8 bit structure more commonly interpreted as a number than byte. – Paul Childs Feb 23 '21 at 00:46

score 1 · Answer 8 · answered May 29 '09 at 18:24

1

Because the arithmetic expression on the right-hand side of the assignment operator evaluates to int by default. In your example percent defaults to int. You can read more about it on the MSDN page.

answered May 29 '09 at 18:24

Alexander Kahoun

2,458
24
36

score 0 · Answer 9 · answered Jun 02 '09 at 20:19

0

FWIW, java also promotes bytes to int.

answered Jun 02 '09 at 20:19

Licky Lindsay

1,048
6
10

Why is a cast required for byte subtraction in C#?

9 Answers9

Linked