看看这段c#代码:
byte x = 1;
byte y = 2;
byte z = x + y; // ERROR: Cannot implicitly convert type 'int' to 'byte'
在字节(或短)类型上执行的任何数学运算的结果都隐式地转换回整数。解决方案是显式地将结果转换回一个字节:
byte z = (byte)(x + y); // this works
我想知道的是为什么?是建筑吗?哲学吗?
我们有:
Int + Int = Int 长+长=长 浮+浮=浮 Double + Double = Double
所以为什么不呢:
字节+字节=字节 空头+空头=空头?
一点背景知识:我正在对“小数字”(即< 8)执行一个长列表的计算，并将中间结果存储在一个大数组中。使用字节数组(而不是int数组)更快(因为缓存命中)。但是大量的字节强制转换散布在代码中，使得代码更加难以阅读。
当前回答
就“为什么会发生这种情况”而言，这是因为正如其他人所说的那样，c#中没有为byte、sbyte、short或ushort的算术定义任何操作符。这个答案是关于为什么没有定义这些操作符。
我相信这主要是为了性能。处理器具有本地操作，可以非常快速地处理32位的算术。可以自动地将结果转换回字节，但如果您不希望发生这种行为，则会导致性能损失。
我认为这在一个带注释的c#标准中提到过。看……
编辑:令人恼火的是，我现在已经查看了带注释的ECMA c# 2规范、带注释的MS c# 3规范和注释的CLI规范，但据我所知，它们都没有提到这一点。我相信我已经看到了上面给出的理由，但如果我知道在哪里，我就被吹了。对不起，参考粉丝们:(
其他回答
在添加字节和将结果截断回字节时显示一些低效的答案是不正确的。X86处理器有专门为8位数的整数运算而设计的指令。
事实上，对于x86/64处理器，执行32位或16位操作的效率低于64位或8位操作，因为必须对操作数前缀字节进行解码。在32位机器上，执行16位操作需要同样的代价，但是仍然有专门的8位操作的操作码。
许多RISC架构都有类似的本地字/字节高效指令。那些通常没有存储并转换为某个比特长度的signed值的类型。
换句话说，这个决定必须基于对字节类型用途的感知，而不是由于硬件的底层低效率。
我认为这是一个关于哪种操作更常见的设计决策……如果byte+byte = byte，可能更多的人会被强制转换为int类型的结果所困扰。
从.NET框架代码:
// bytes
private static object AddByte(byte Left, byte Right)
{
short num = (short) (Left + Right);
if (num > 0xff)
{
return num;
}
return (byte) num;
}
// shorts (int16)
private static object AddInt16(short Left, short Right)
{
int num = Left + Right;
if ((num <= 0x7fff) && (num >= -32768))
{
return (short) num;
}
return num;
}
使用。net 3.5及以上版本进行简化:
public static class Extensions
{
public static byte Add(this byte a, byte b)
{
return (byte)(a + b);
}
}
现在你可以做:
byte a = 1, b = 2, c;
c = a.Add(b);
除了所有其他伟大的评论，我想我要添加一个小花絮。很多评论都想知道为什么int、long和几乎任何其他数字类型都不遵循这个规则…返回一个“更大”的类型以响应算术。
A lot of answers have had to do with performance (well, 32bits is faster than 8bits). In reality, an 8bit number is still a 32bit number to a 32bit CPU....even if you add two bytes, the chunk of data the cpu operates on is going to be 32bits regardless...so adding ints is not going to be any "faster" than adding two bytes...its all the same to the cpu. NOW, adding two ints WILL be faster than adding two longs on a 32bit processor, because adding two longs requires more microops since you're working with numbers wider than the processors word.
I think the fundamental reason for causing byte arithmetic to result in ints is pretty clear and straight forward: 8bits just doesn't go very far! :D With 8 bits, you have an unsigned range of 0-255. That's not a whole lot of room to work with...the likelyhood that you are going to run into a bytes limitations is VERY high when using them in arithmetic. However, the chance that you're going to run out of bits when working with ints, or longs, or doubles, etc. is significantly lower...low enough that we very rarely encounter the need for more.
从字节到int的自动转换是合乎逻辑的，因为字节的规模是如此之小。从整型到长型，从浮点数到双精度浮点数等自动转换是不符合逻辑的，因为这些数字具有显著的比例。
我想我以前在什么地方见过这个。从这篇文章，旧的新事物:
假设我们生活在一个幻想的世界 对'byte'的操作导致了什么 “字节”。
byte b = 32;
byte c = 240;
int i = b + c; // what is i?
在这个幻想世界里，i的值 应该是16岁!为什么?因为这两个 +操作符的操作数都是 字节，因此“b+c”的和计算为 一个字节，由于 整数溢出。(而且，正如我所指出的 之前，整数溢出是新的 安全攻击向量。)
编辑:Raymond实质上是在捍卫C和c++最初采用的方法。在评论中，他从语言向后兼容的角度为c#采用了相同的方法进行了辩护。
