byte + byte = int ... 为什么？

Question

看看这段 C# 代码：

byte x = 1;
byte y = 2;
byte z = x + y; // ERROR: Cannot implicitly convert type 'int' to 'byte'

对byte（或short）类型执行的任何数学运算的结果都会隐式转换回整数。解决方案是将结果显式转换回一个字节：

byte z = (byte)(x + y); // this works

我想知道为什么？它是建筑的吗？哲学？

我们有：

• int + int = int
• long + long = long
• float + float = float
• double + double = double

为什么不呢：

• byte + byte = byte
• short + short = short?

一点背景知识：我正在对“小数”（即 byte 数组（而不是 int 数组）更快（因为缓存命中）。但是通过代码传播的大量字节转换使其更加难以阅读。

Answer 1

你的代码第三行sn -p：

byte z = x + y;

其实就是

byte z = (int) x + (int) y;

因此，对字节没有 + 操作，字节首先转换为整数，两个整数相加的结果是一个（32 位）整数。

Answer 2

就“为什么会发生”而言，这是因为 C# 没有为算术定义任何运算符，如其他人所说的那样，字节、sbyte、short 或 ushort。这个答案是关于为什么这些运算符没有定义。

我相信这基本上是为了性能。处理器具有本机操作，可以非常快速地使用 32 位进行算术运算。自动将结果转换回字节可以完成，但在您实际上不想要这种行为的情况下会导致性能损失。

我认为这是在带注释的 C# 标准之一中提到的。看着...

编辑：烦人的是，我现在浏览了带注释的 ECMA C# 2 规范、带注释的 MS C# 3 规范和注释 CLI 规范，并且 none 尽我所能看。我确定我已经看到了上面给出的原因，但是如果我知道在哪里，我会感到震惊。道歉，参考粉丝:(

Answer 3

我以为我以前在某个地方看到过这个。来自this article, The Old New Thing：

假设我们生活在一个幻想世界 对“字节”的操作导致 '字节'。

byte b = 32;
byte c = 240;
int i = b + c; // what is i?

在这个奇幻的世界里，我的价值 将是 16 岁！为什么？因为两人 + 运算符的操作数都是 字节，因此总和“b+c”计算为 一个字节，结果为 16 由于 整数溢出。 （而且，正如我所指出的 早些时候，整数溢出是新的 安全攻击向量。）

编辑：Raymond 本质上是在捍卫 C 和 C++ 最初采用的方法。在 cmets 中，他为 C# 采用相同方法的事实辩护，理由是语言向后兼容。

Answer 4

C#

ECMA-334 声明加法仅在 int+int、uint+uint、long+long 和 ulong+ulong 上被定义为合法 (ECMA-334 14.7.4)。因此，这些是针对 14.4.2 考虑的候选操作。因为存在从 byte 到 int、uint、long 和 ulong 的隐式转换，所以所有加法函数成员都是 14.4.2.1 下适用的函数成员。我们必须根据 14.4.2.3 中的规则找到最佳的隐式转换：

将(C1) 转换为 int(T1) 优于将(C2) 转换为 uint(T2) 或 ulong(T2)，因为：

• 如果 T1 是 int 而 T2 是 uint 或 ulong，则 C1 是更好的转换。

将(C1) 转换为int(T1) 优于将(C2) 转换为long(T2)，因为存在从int 到long 的隐式转换：

• 如果存在从 T1 到 T2 的隐式转换，并且不存在从 T2 到 T1 的隐式转换，则 C1 是更好的转换。

因此使用了 int+int 函数，它返回一个 int。

要说它深深地埋在 C# 规范中，那是一段很长的路要走。

命令行

CLI 仅在 6 种类型（int32、native int、int64、F、O 和 &）上运行。 （ECMA-335 分区 3 第 1.5 节）

Byte (int8) 不是这些类型之一，在添加之前会自动强制转换为 int32。 （ECMA-335 分区 3 第 1.6 节）

Answer 5

表明添加字节并将结果截断回字节的某些低效率的答案是不正确的。 x86 处理器具有专门为 8 位整数运算而设计的指令。

事实上，对于 x86/64 处理器，执行 32 位或 16 位操作的效率低于 64 位或 8 位操作，因为必须解码操作数前缀字节。在 32 位机器上，执行 16 位操作会带来相同的损失，但仍然存在用于 8 位操作的专用操作码。

许多 RISC 架构都有类似的本地字/字节高效指令。那些通常没有存储并转换为一些位长度的有符号值的。

换句话说，这个决定一定是基于对字节类型的感知，而不是由于硬件的潜在低效率。

Answer 6

我记得有一次从 Jon Skeet（现在找不到，我会继续寻找）那里读到一些关于 byte 实际上不会使 + 运算符超载的内容。事实上，当像您的示例一样添加两个字节时，每个字节实际上都被隐式转换为一个 int。结果显然是一个int。现在至于为什么这样设计，我会等 Jon Skeet 自己发帖:)

编辑：找到了！关于这个主题的大量信息here。

Answer 7

这是因为溢出和进位。

如果将两个 8 位数字相加，它们可能会溢出到第 9 位。

例子：

  1111 1111
+ 0000 0001
-----------
1 0000 0000

我不确定，但我认为ints、longs 和doubles 被给予了更多空间，因为它们本来就相当大。此外，由于内部数据总线的宽度为 4 字节或 32 位（现在 64 位越来越普遍），因此它们是 4 的倍数，这对于计算机来说更有效。 byte 和 short 效率稍低一些，但它们可以节省空间。

Answer 8

根据 C# 语言规范 1.6.7.5 7.2.6.2 Binary numeric Promotions，如果它不能适合其他几个类别，它会将两个操作数都转换为 int。我的猜测是他们没有重载 + 运算符以将 byte 作为参数，而是希望它正常运行，所以他们只使用 int 数据类型。

C# language Spec

Answer 9

我的怀疑是 C# 实际上调用了在 int 上定义的 operator+（除非您在 checked 块中，否则它将返回 int），并隐式转换您的 bytes/@987654326 @到ints。这就是行为看起来不一致的原因。

Answer 10

这可能是语言设计者的一个实际决定。毕竟，int 是一个 Int32，一个 32 位有符号整数。每当您对小于 int 的类型执行整数运算时，无论如何，大多数 32 位 CPU 都会将其转换为 32 位有符号 int。再加上溢出小整数的可能性，很可能达成了交易。它使您免于不断检查溢出/下溢的繁琐工作，并且当字节表达式的最终结果在范围内时，尽管在某些中间阶段它会超出范围，但您会得到正确的结果。

另一个想法：必须模拟这些类型的上溢/下溢，因为它不会在最有可能的目标 CPU 上自然发生。何必呢？

Answer 11

这是我与该主题相关的大部分答案，首先提交给类似的问题here。

所有小于 Int32 的整数运算默认在计算前四舍五入到 32 位。结果是 Int32 的原因只是在计算后保持原样。如果检查 MSIL 算术操作码，它们操作的唯一整数类型是 Int32 和 Int64。这是“设计使然”。

如果您希望返回 Int16 格式的结果，则在代码中执行强制转换是无关紧要的，或者编译器（假设地）“在后台”发出转换。

例如做Int16算术：

short a = 2, b = 3;

short c = (short) (a + b);

这两个数字将扩展为 32 位，相加，然后截断回 16 位，这正是 MS 的预期。

使用短（或字节）的优势主要是在您拥有大量数据（图形数据、流媒体等）的情况下进行存储

Answer 12

没有为字节定义加法。因此它们被强制转换为 int 以进行加法。大多数数学运算和字节都是如此。 （请注意，这是过去在旧语言中的用法，我假设它今天仍然适用）。

Answer 13

我认为这是一个关于哪种操作更常见的设计决定......如果 byte+byte = byte 可能更多的人会因为在需要 int 作为结果时必须强制转换为 int 而烦恼。

Answer 14

来自 .NET Framework 代码：

// 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);

Answer 15

我已经测试了字节和整数之间的性能。
使用 int 值：

class Program
{
    private int a,b,c,d,e,f;

    public Program()
    {
        a = 1;
        b = 2;
        c = (a + b);
        d = (a - b);
        e = (b / a);
        f = (c * b);
    }

    static void Main(string[] args)
    {
        int max = 10000000;
        DateTime start = DateTime.Now;
        Program[] tab = new Program[max];

        for (int i = 0; i < max; i++)
        {
            tab[i] = new Program();
        }
        DateTime stop = DateTime.Now;

        Debug.WriteLine(stop.Subtract(start).TotalSeconds);
    }
}

字节值：

class Program
{
    private byte a,b,c,d,e,f;

    public Program()
    {
        a = 1;
        b = 2;
        c = (byte)(a + b);
        d = (byte)(a - b);
        e = (byte)(b / a);
        f = (byte)(c * b);
    }

    static void Main(string[] args)
    {
        int max = 10000000;
        DateTime start = DateTime.Now;
        Program[] tab = new Program[max];

        for (int i = 0; i < max; i++)
        {
            tab[i] = new Program();
        }
        DateTime stop = DateTime.Now;

        Debug.WriteLine(stop.Subtract(start).TotalSeconds);
    }
}

结果如下：
字节：3.57s 157mo、3.71s 171mo、3.74s 168mo with CPU ~= 30%
int : 4.05s 298mo, 3.92s 278mo, 4.28 294mo with CPU ~= 27%
结论：
byte 使用更多的 CPU，但它消耗更少的内存并且速度更快（可能是因为要分配的字节更少）

Answer 16

除了所有其他伟大的 cmets，我想我会添加一个小花絮。许多 cmets 想知道为什么 int、long 和几乎任何其他数字类型也不遵循此规则...返回“更大”类型以响应算术。

很多答案都与性能有关（嗯，32 位比 8 位快）。实际上，对于 32 位 CPU，8 位数字仍然是 32 位数字......即使添加两个字节，cpu 操作的数据块也将是 32 位......所以添加整数不会比添加两个字节“更快”……对cpu来说都是一样的。现在，添加两个整数将比在 32 位处理器上添加两个长整数更快，因为添加两个长整数需要更多的微操作，因为您使用的数字比处理器字宽。

我认为导致字节算术产生整数的根本原因非常清楚和直接：8 位并没有走得太远！ :D 使用 8 位，您的无符号范围为 0-255。这不是有很大的工作空间......在算术中使用它们时，您遇到字节限制的可能性非常高。但是，在使用整数、长整数或双精度数等时，您将用完位的可能性要低得多……足够低，以至于我们很少遇到需要更多位的情况。

从字节到整数的自动转换是逻辑，因为字节的规模是如此之小。从 int 到 long、float 到 double 等的自动转换是不合逻辑，因为这些数字具有很大的规模。