看看这段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数组)更快(因为缓存命中)。但是大量的字节强制转换散布在代码中,使得代码更加难以阅读。


当前回答

我认为这是一个关于哪种操作更常见的设计决策……如果byte+byte = byte,可能更多的人会被强制转换为int类型的结果所困扰。

其他回答

这是由于溢出和携带。

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

例子:

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

我不确定,但我假设int型、long型和double型被赋予了更多的空间,因为它们确实相当大。此外,它们是4的倍数,这对计算机来说更有效,因为内部数据总线的宽度是4字节或32位(64位现在越来越普遍)宽。Byte和short的效率稍低,但它们可以节省空间。

我已经测试了字节和int之间的性能。 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, CPU ~= 30% int: 4.05s 298mo, 3.92s 278mo, 4.28 294mo with CPU ~= 27% 结论: 字节使用更多的CPU,但它消耗更少的内存,它更快(可能是因为有更少的字节分配)

我想我以前在什么地方见过这个。从这篇文章,旧的新事物:

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

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

在这个幻想世界里,i的值 应该是16岁!为什么?因为这两个 +操作符的操作数都是 字节,因此“b+c”的和计算为 一个字节,由于 整数溢出。(而且,正如我所指出的 之前,整数溢出是新的 安全攻击向量。)

编辑:Raymond实质上是在捍卫C和c++最初采用的方法。在评论中,他从语言向后兼容的角度为c#采用了相同的方法进行了辩护。

这是我对这个话题的大部分回答,首先是针对这里的一个类似问题。

默认情况下,所有小于Int32的整数运算在计算前四舍五入到32位。结果为Int32的原因仅仅是让它在计算后保持原样。如果检查MSIL算术操作码,它们操作的唯一整型数字类型是Int32和Int64。这是“故意的”。

如果您希望结果以Int16格式返回,则在代码中执行强制转换或编译器(假设)在“底层”发出转换都无关紧要。

例如,要执行Int16算术:

short a = 2, b = 3;

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

这两个数字将扩展为32位,然后相加,然后截短为16位,这是MS所希望的。

使用短(或字节)的优势主要是在有大量数据(图形数据、流等)的情况下存储。

在添加字节和将结果截断回字节时显示一些低效的答案是不正确的。X86处理器有专门为8位数的整数运算而设计的指令。

事实上,对于x86/64处理器,执行32位或16位操作的效率低于64位或8位操作,因为必须对操作数前缀字节进行解码。在32位机器上,执行16位操作需要同样的代价,但是仍然有专门的8位操作的操作码。

许多RISC架构都有类似的本地字/字节高效指令。那些通常没有存储并转换为某个比特长度的signed值的类型。

换句话说,这个决定必须基于对字节类型用途的感知,而不是由于硬件的底层低效率。