Почему является результатом вычитания параметра Int16 от переменной Int16 Int32? [дубликат]
# print section of file based on line numbers
sed -n '16224 ,16482p' # method 1
sed '16224,16482!d' # method 2
5 ответов
Это не просто вычитание, просто не существует короткой (или байтовой / сбайтной) арифметики.
short a = 2, b = 3;
short c = a + b;
Выдает ошибку, которая не может преобразовать int (a + b) в short (c) .
Еще одна причина почти никогда не использовать короткие.
Дополнительно: при любых вычислениях short и sbyte всегда будут «расширены» до int, ushort и byte до uint. Такое поведение восходит к K&R C (и, вероятно, даже старше этого).
(старой) причиной этого были проблемы с эффективностью и переполнением при работе с char. Эта последняя причина уже не так сильна для C #, где char составляет 16 бит и не может быть неявно преобразован в int. Но очень удачно, что числовые выражения C # остаются совместимыми с C и C ++ в очень высокой степени.
All operations with integral numbers smaller than Int32 are widened to 32 bits before calculation by default. The reason why the result is Int32 is simply to leave it as it is after calculation. If you check the MSIL arithmetic opcodes, the only integral numeric type they operate with are Int32 and Int64. It's "by design".
If you desire the result back in Int16 format, it is irrelevant if you perform the cast in code, or the compiler (hypotetically) emits the conversion "under the hood".
Also, the example above can easily be solved with the cast
short a = 2, b = 3;
short c = (short) (a + b);
The two numbers would expand to 32 bits, get subtracted, then truncated back to 16 bits, which is how MS intended it to be.
The advantage of using short (or byte) is primarily storage in cases where you have massive amounts of data (graphical data, streaming, etc.)
P.S. Oh, and the article is "a" for words whose pronunciation starts with a consonant, and "an" for words whose pronunciated form starts with a vowel. A number, AN int. ;)
Эффект, который вы видите ...
short - short = int
... подробно обсуждается в этом вопросе по стеку: [ссылка] байт + байт = int… почему?
Есть много полезной информации и несколько интересных дискуссий о том, почему это так.
Вот ответ, получивший наибольшее количество голосов. :
Я считаю, что это в основном ради производительности. (С точки зрения «почему это вообще случается "потому что там нет никаких операторов, определенных C # для арифметика с байтом, sbyte, short или ushort, как говорили другие. это Ответ о том, почему эти операторы не определены.)
Процессоры имеют собственные операции для выполнять арифметические операции с 32 битами очень быстро. Выполнение конвертации обратно от результата до байта может быть выполнено автоматически, но будет привести к штрафам за производительность в случай, когда вы на самом деле не хотите такое поведение.
- Джон Скитс
Наслаждайтесь,
Роберт С. Картаино
Я думаю, что это делается автоматически, чтобы избежать переполнения,
позволяет сказать, что вы делаете что-то вроде этого.
Short result = Short.MaxValue + Short.MaxValue;
Результат явно не подходит для краткости.
одно. Я не понимаю, почему бы не сделать это и для int32, который автоматически конвертируется в long ???
Другие ответы в этой теме, а также приведенные здесь обсуждения поучительны:
(1) Почему требуется ли приведение для вычитания байтов в C #?
(2) byte + byte = int… почему?
(3) Почему требуется приведение для вычитания байтов в C #?
Но просто чтобы добавить еще одну морщину, это может зависеть от того, какие операторы вы используете. Операторы инкремента (++) и декремента (-), а также операторы присваивания сложения (+ =) и присваивания вычитания (- =) перегружены для множества числовых типов,