байт + байт = int… чому?

Дивлячись на цей 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?

Трохи довідки: я виконую довгий список обчислень на "малі числа" (тобто <8) і зберігаю проміжні результати у великому масиві. Використання байтового масиву (замість масиву int) швидше (через хіти кешу). Але широкі байтові коди, розповсюджені через код, роблять його набагато нечитабельнішим.

Третій рядок фрагмента коду:

byte z = x + y;

насправді означає

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

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

З точки зору "чому це взагалі трапляється", це тому, що не існує жодних операторів, визначених C # для арифметики з байтом, sbyte, коротким або ушортом, як це сказали інші. Ця відповідь стосується того, чому ці оператори не визначені.

Я вважаю, що це в основному заради продуктивності. Процесори мають власні операції, щоб робити арифметичні з 32 бітами дуже швидко. Здійснення автоматичного перетворення з результату в байт автоматично може бути здійснено, але це призведе до штрафних покарань у тому випадку, коли ви насправді не бажаєте такої поведінки.

Я думаю, що це згадується в одному з анотованих стандартів C #. Дивлячись ...

EDIT: Напорядливо я переглянув коментовану специфікацію C # 2 ECMA, анотовану специфікацію MS C # 3 та специфікацію CLI анотації, і жодна з них не згадує про це, наскільки я бачу. Я впевнений, що бачив причину, наведену вище, але мене здувало, якщо я знаю, де. Вибачення, шанувальники посилання :(

Я думав, що бачив це десь раніше. З цієї статті "Стара нова річ" :

Припустимо, ми жили у світі фантазій, де операції над «байтом» призводили до «байту».

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

У цьому світі фантазій цінність i була б 16! Чому? Оскільки два операнди до оператора + є обома байтами, тож сума "b + c" обчислюється як байт, в результаті чого 16 відбувається через ціле переповнення. (І, як я вже зазначав, цілий переповнення - це новий вектор атаки безпеки.)

EDIT : Реймонд захищає, по суті, підхід 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) до довгого (T2), оскільки є неявна передача від int до long:

• Якщо існує неявна конверсія з T1 в T2, а неявна конверсія з T2 в T1 не існує, C1 є кращою конверсією.

Отже, використовується функція int + int, яка повертає int.

Що є дуже довгим способом сказати, що він похований дуже глибоко в специфікації C #.

CLI

CLI працює лише на 6 типів (int32, native int, int64, F, O і &). (Розділ 3 розділу ECMA-335, розділ 1.5)

Байт (int8) не є одним із таких типів і автоматично додається до int32 перед додаванням. (Розділ 3 розділу ECMA-335, розділ 1.6)

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

Насправді для процесорів x86 / 64 виконання 32-бітних або 16-бітних операцій є менш ефективними, ніж 64-бітні або 8-бітні операції через байт префікса операнду, який повинен бути декодований. На 32-бітних машинах виконання 16-бітових операцій тягне за собою однакове покарання, але все ще є виділені опкоди для 8-бітних операцій.

У багатьох архітектурах RISC є схожі інструкції щодо ефективного використання слів / байтів. Ті, які зазвичай не мають "зберігати та перетворювати" в "підписані" значення "якогось біта".

Іншими словами, це рішення повинно було базуватися на уявленні того, для чого тип байту, а не через неефективність апаратних засобів.

Я пам'ятаю, як одного разу читав щось від Джона Скіта (не можу його зараз знайти, я продовжую шукати) про те, як байт насправді не перевантажує + оператора. Насправді, додаючи два байти, як у вашому зразку, кожен байт насправді неявно перетворюється на int. Результат цього, очевидно, є int. Тепер щодо того, ЧОМУ це було розроблено таким чином, я зачекаю, коли сам Джон Скіт викладе повідомлення :)

EDIT: Знайшов! Чудова інформація про цю саму тему тут .

Це через переповнення і несе.

Якщо додати два 8-бітних числа, вони можуть переповнюватися в 9-й біт.

Приклад:

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

Я не знаю точно, але я вважаю , що ints, longsі doublesдають більше простору , тому що вони досить великий , як вона є. Крім того, вони є кратними 4, які є більш ефективними для роботи з комп'ютерами, оскільки ширина внутрішньої шини даних становить 4 байти або 32 біта (64 біта стає все більш поширеним). Байт і короткий трохи більш неефективні, але вони можуть заощадити місце.

З мовної специфікації C # 1.6.7.5 7.2.6.2 Бінарні числові акції перетворюють обидва операнди в int, якщо він не може вписати його в декілька інших категорій. Я здогадуюсь, що вони не перевантажували оператора +, щоб взяти байт як параметр, але хочуть, щоб він діяв нормально, щоб вони просто використовували тип даних int.

C # мова Spec

Я підозрюю, що C # насправді викликає operator+визначений int(який повертає, intякщо ви не знаходитесь у checkedблоці), і неявно викидає обидва ваші bytes/ shortsдо 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 для додавання. Це справедливо для більшості математичних операцій та байтів. (зауважте, так це було раніше у старих мовах; я припускаю, що це актуально і сьогодні).

Я думаю, що це рішення дизайну щодо того, яка операція була більш поширеною ... Якщо байт + байт = байт, можливо, набагато більше людей буде занепокоєно тим, що потрібно кидати в 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 з процесором ~ = 30%
int: 4,05s 298mo, 3,92s 278mo, 4,28 294mo з CPU ~ = 27%
Висновок:
байт більше використовує процесор, але це коштує менше пам'яті, і це швидше (можливо, тому що менше байтів для виділення)

На додачу до всіх інших чудових коментарів, я думав, що додам ще одну маленьку примху. Багато коментарів задаються питанням, чому int, long і майже будь-який інший числовий тип також не дотримується цього правила ... поверніть "більший" тип у відповідь на арифметичний.

Дуже багато відповідей стосується продуктивності (ну, 32 біт швидше, ніж 8 біт). Насправді 8-бітове число - це все-таки 32-бітове число до 32-бітового процесора .... навіть якщо ви додасте два байти, шматок даних, на якому працює процесор, буде 32-бітним незалежно ... тому додавання ints не збирається будь-який "швидший", ніж додавання двох байтів ... його все одно на процесор. ЗАРАЗ, додавання двох ints БУДЕ швидше, ніж додавання двох довгих 32-бітових процесорів, тому що для додавання двох довгих потрібно більше мікрооперацій, оскільки ви працюєте з числами, ширшими, ніж слово процесорів.

Я думаю, що фундаментальна причина того, що арифметика байтів призводить до ints, є досить чіткою і прямою: 8bit просто не надто далеко! : D З 8 бітами у вас діапазон без підпису 0-255. Це не багато можливостей для роботи ... ймовірність того, що ви збираєтеся зіткнутися з обмеженнями в байтах, ДУЖЕ висока при використанні їх в арифметиці. Однак ймовірність того, що у вас будуть вичерпані шматочки, коли ви працюєте з ints, або longs, або doublelies тощо, значно нижчий ... досить низький, що ми дуже рідко стикаємося з потребою в більшому.

Автоматичне перетворення від байта до int є логічним, оскільки масштаб байта настільки малий. Автоматичне перетворення з int в long, плаваюче в подвійне тощо не є логічним, оскільки ці числа мають значну шкалу.