byte + byte = int почему?

Третья строка вашего фрагмента кода:

byte z = x + y;

на самом деле означает

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

Таким образом, для байтов нет операции +, байты сначала преобразуются в целые числа, а результатом сложения двух целых чисел является (32-битное) целое число.

С точки зрения «почему это вообще происходит», это потому, что C # не определяет никаких операторов для арифметики с байтами, sbyte, short или ushort, как говорили другие. Этот ответ о том, почему не определены эти операторы.

Я считаю, что это в основном ради производительности. Процессоры имеют встроенные операции, позволяющие очень быстро выполнять 32-битные арифметические операции. Выполнение обратного преобразования результата в байт автоматически может быть выполнено, но приведет к снижению производительности в случае, если вы на самом деле не хотите такого поведения.

Я думаю, что это упоминается в одном из аннотированных стандартов C #. Смотрящий...

РЕДАКТИРОВАТЬ: досадно, что теперь я просмотрел аннотированную спецификацию ECMA C # 2, аннотированную спецификацию MS C # 3 и спецификацию аннотации CLI, и ни один из них не упоминает об этом, насколько я могу видеть. Я уверен, что я видел причину, указанную выше, но меня взорвет, если я знаю, где. Извинения, ссылочные фанаты :(

Я подумал, что видел это где-то раньше. Из этой статьи, The Old New Thing:

Предположим, мы живем в фантастическом мире, где операции с байтом приводят к байту.

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

В этом фантастическом мире значение i было бы 16! Почему? Поскольку два операнда оператора + являются байтами, сумма «b + c» вычисляется как байт, что дает 16 из-за целочисленного переполнения. (И, как я отмечал ранее, целочисленное переполнение - это новый вектор атаки на безопасность.)

РЕДАКТИРОВАТЬ: Раймонд, по сути, защищает исходный подход C и C ++. В комментариях он защищает тот факт, что C # использует тот же подход, исходя из обратной совместимости языка.

C#

ECMA-334 утверждает, что добавление разрешено только для int + int, uint + uint, long + long и ulong + ulong (ECMA-334 14.7.4). Таким образом, это операции-кандидаты, которые следует учитывать в отношении 14.4.2. Поскольку существуют неявные преобразования байтов в 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

CLI работает только с 6 типами (int32, native int, int64, F, O и &). (ECMA-335, раздел 3, раздел 1.5)

Byte (int8) не является одним из этих типов и автоматически приводится к int32 перед добавлением. (ECMA-335, раздел 3, раздел 1.6)

Ответы, указывающие на некоторую неэффективность добавления байтов и усечения результата до байта, неверны. Процессоры x86 имеют инструкции, специально разработанные для целочисленных операций с 8-битными величинами.

Фактически, для процессоров x86 / 64 выполнение 32-битных или 16-битных операций менее эффективно, чем 64-битные или 8-битные операции из-за байта префикса операнда, который необходимо декодировать. На 32-битных машинах выполнение 16-битных операций влечет за собой такие же штрафы, но все еще есть специальные коды операций для 8-битных операций.

Многие архитектуры RISC имеют аналогичные встроенные команды, эффективные для слов и байтов. Те, которые обычно не имеют значения длины в битах для хранения и преобразования в знаковое значение.

Другими словами, это решение должно было быть основано на восприятии того, для чего предназначен байтовый тип, а не из-за лежащей в основе неэффективности оборудования.

Я помню, как однажды читал что-то от Джона Скита (сейчас не могу найти, буду искать) о том, как байт на самом деле не перегружает оператор +. Фактически, при добавлении двух байтов, как в вашем примере, каждый байт фактически неявно преобразуется в int. Результатом этого, очевидно, является тип int. Теперь что касается того, ПОЧЕМУ это было разработано таким образом, я подожду, пока сам Джон Скит опубликует сообщение :)

РЕДАКТИРОВАТЬ: Нашел! Подробная информация по этой теме здесь.

Это из-за переполнения и уноса.

Если вы сложите два 8-битных числа, они могут вылиться в 9-й бит.

Пример:

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

Я не знаю наверняка, но предполагаю, что ints, longs иdoubles имеют больше места, потому что они и так довольно большие. Кроме того, они кратны 4, что более эффективно для компьютеров, так как ширина внутренней шины данных составляет 4 байта или 32 бита (сейчас 64 бита становятся все более распространенными). Byte и short немного менее эффективны, но они могут сэкономить место.

Из спецификации языка C # 1.6.7.5 7.2.6.2 Двоичные числовые предложения он преобразует оба операнда в int, если он не может поместиться в несколько других категорий. Я предполагаю, что они не перегружали оператор +, чтобы он принимал байт в качестве параметра, но хотят, чтобы он работал нормально, поэтому они просто используют тип данных int.

Спецификация языка C #

Я подозреваю, что C # на самом деле вызывает operator+, определенный в int (который возвращает int, если вы не находитесь в блоке checked), и неявно преобразует оба ваших _5 _ / _ 6_ в ints. Вот почему поведение кажется непоследовательным.

Вероятно, это было практическое решение со стороны разработчиков языка. В конце концов, int - это Int32, 32-битное целое число со знаком. Всякий раз, когда вы выполняете целочисленную операцию с типом, меньшим, чем int, он в любом случае будет преобразован в 32-битный подписанный int почти любым 32-битным процессором. Это, в сочетании с вероятностью переполнения небольших целых чисел, вероятно, заключило сделку. Это избавляет вас от рутинной работы по постоянной проверке переполнения / недостаточного потока, и когда конечный результат выражения в байтах будет в диапазоне, несмотря на то, что на каком-то промежуточном этапе он будет вне диапазона, вы получите правильный результат.

Другая мысль: необходимо смоделировать переполнение / недостаточный поток для этих типов, поскольку это не произойдет естественным образом на наиболее вероятных целевых процессорах. Зачем беспокоиться?

По большей части это мой ответ, относящийся к этой теме, который сначала был отправлен на аналогичный вопрос здесь.

По умолчанию все операции с целыми числами меньше Int32 перед вычислением округляются до 32 бит. Причина, по которой результатом является Int32, заключается в том, чтобы просто оставить его таким, каким он был после расчета. Если вы проверите арифметические коды операций MSIL, единственными целочисленными типами, с которыми они работают, являются Int32 и Int64. Это «по замыслу».

Если вы хотите вернуть результат в формате Int16, не имеет значения, выполняете ли вы приведение кода или компилятор (гипотетически) испускает преобразование «под капотом».

Например, чтобы выполнить арифметику Int16:

short a = 2, b = 3;

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

Два числа расширятся до 32 бит, будут добавлены, а затем снова усечены до 16 бит, как и предполагала MS.

Преимущество использования коротких (или байтовых) значений заключается в первую очередь в хранении в случаях, когда у вас есть большие объемы данных (графические данные, потоковая передача и т. Д.).

Для байтов сложение не определено. Таким образом, они приводятся к типу int для добавления. Это верно для большинства математических операций и байтов. (обратите внимание, что это было так в старых языках, я предполагаю, что это верно и сегодня).

Я думаю, что это дизайнерское решение о том, какая операция была более распространенной ... Если byte + byte = byte, может быть, гораздо больше людей будут беспокоиться о необходимости приводить к int, когда в результате требуется int.

Из кода .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);

Я тестировал производительность между байтом и 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 с CPU ~ = 27%
Заключение:
байт использует больше ЦП, но требует меньше памяти и быстрее (возможно, потому, что нужно выделить меньше байтов)

В дополнение ко всем другим замечательным комментариям, я подумал, что добавлю один небольшой лакомый кусочек. Многие комментарии задаются вопросом, почему int, long и почти любой другой числовой тип также не следует этому правилу ... возвращать «больший» тип в ответ на арифметический.

Многие ответы были связаны с производительностью (ну, 32 бита быстрее, чем 8 бит). На самом деле, 8-битное число по-прежнему является 32-битным числом для 32-битного процессора ... даже если вы добавите два байта, фрагмент данных, с которым работает процессор, будет 32-битным независимо ... поэтому добавление int не будет будь «быстрее», чем добавление двух байтов ... все равно процессору. СЕЙЧАС добавление двух целых чисел БУДЕТ быстрее, чем добавление двух длинных чисел на 32-битном процессоре, потому что добавление двух длинных чисел требует больше микроопераций, так как вы работаете с числами шире, чем слово процессора.

Я думаю, что основная причина того, что байтовая арифметика приводит к целым числам, довольно ясна и прямолинейна: 8-битные просто не идут очень далеко! : D С 8 битами у вас есть беззнаковый диапазон от 0 до 255. Это не много места для работы ... вероятность того, что вы столкнетесь с ограничениями по байтам, ОЧЕНЬ высока при их использовании в арифметике. Однако вероятность того, что у вас закончатся биты при работе с целыми, длинными, двойными и т. Д., Значительно ниже ... достаточно мала, чтобы мы очень редко сталкивались с потребностью в большем количестве.

Автоматическое преобразование байта в int является логическим, потому что размер байта очень мал. Автоматическое преобразование из int в long, float в double и т. Д. нелогично, потому что эти числа имеют значительный масштаб.