Тип данных long

Здравствуйте.

1) long - это новый тип данных в c++?
2) Если первое верно, зачем вводить новый тип данных, если есть такой же int?
3) Если первое неверно, в чем отличие long от int?

Если я правильно понял, long - это long int. В языке C нет типа данных long, там int и long int. Вопрос: почему при компиляции переменной с типом long в языке C не выдается ошибка?

Спасибо.

1

Сообщение от globalhost А на компиляторы старше 2011 это тоже распространяется?

Конечно. Это же фундаментальный принцип вычислений. Если операнды имеют тип арифметический тип T, то они не должны приводиться к более узкому типу без явных на то указаний со стороны программиста:
Если бы операнд "a" приводился автоматически к int была бы возможна потеря данных на совершенно ровном месте. Не было бы смысла во введении более широких чем int типов.

0

Сообщение от Tulosba Если бы операнд "a" приводился автоматически к int была бы возможна потеря данных на совершенно ровном месте. Не было бы смысла во введении более широких чем int типов.

А как же тип short?
Выражения с переменными short приводятся к int, а с переменными long не приводятся?

Пруф.
http://bukin.su/share/Книги/cpp/Prata_C++.pdf (стр. 74, "Преобразование данных в выражениях").

0

Сообщение от globalhost Выражения с переменными short приводятся к int

Это называется promotion, который по смыслу действует только в сторону расширения типа и только для char/short (в целочисленных выражениях)

0

Сообщение от Evg типа и только для char/short (в целочисленных выражениях)

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

Добавлено через 15 минут

Сообщение от globalhost Пруф.

читаем

"Преобразование данных осуществляется, когда в выражении содержатся данные разных типов"

о чем и говорил Tulosba

Сообщение от Tulosba Зачем? Очевидно же, что это не так. 5/9 Expressions [expr]

0

Сообщение от ValeryS т.е без нужды не приводит типы к большему

По стандарту приводит. Ты видишь в коде результат работы оптимизаций. Т.е. в "нормальных" условиях коды

эквивалентны. Но помимо i386 в мире существует полно всяких различных процессоров, и вполне возможно, что на каком-то из них эти коды НЕ будут эквивалентны


К тому же ты, как и многие другие, ставишь "плохой" эксперимент, потому что для доказательства обратного используешь "хорошую" операцию. Замени операцию сложения на деление, и увидишь, что преобразование к int'у появится явным образом в коде

Добавлено через 33 минуты
Стандарт ISO/IEC 9899:1999 (E)

5.1.2.3 Program execution ... 10 EXAMPLE 2 In executing the fragment char c1, c2; /* ... */ c1 = c1 + c2; the ‘‘integer promotions’’ require that the abstract machine promote the value of each variable to int size and then add the two ints and truncate the sum. Provided the addition of two chars can be done without overflow, or with overflow wrapping silently to produce the correct result, the actual execution need only produce the same result, possibly omitting the promotions.

Добавлено через 1 минуту
Т.е. вариант построения кода на i386 отвечает требованиям "without overflow, or with overflow wrapping silently", т.к. переполнения не вызывают никаких сигналов (которые растут из аппаратных прерываний) и именно поэтому ты в коде не видишь операций преобразования в int

1

Сообщение от Evg Ты видишь в коде результат работы оптимизаций.

В Стандарте сказано: 5/9:

... the integral promotions (4.5) shall be performed on both operands.

При этом 4.5 Integral promotions [conv.prom]

A prvalue of an integer type other than bool, char16_t, char32_t, or wchar_t whose integer conversion rank (4.13) is less than the rank of int can be converted to a prvalue of type int if int can represent all the values of the source type; otherwise, the source prvalue can be converted to a prvalue of type unsigned int.

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

1

Сообщение от Evg Т.е. в "нормальных" условиях коды C++ 1 2 char a, b, c; a = b + c; /* Предполагаем отсутствие promotion */ C++ 1 2 char a, b, c; a = (char)((int)b + (int)c); эквивалентны. Но помимо i386 в мире

или я чего то не понимаю или для х86 они как раз не эквивалентны
есть приведение/ нет приведения
у х86 есть команды для работы и с 1 и с 2 и с 4 байтами
так что

Сообщение от Evg Замени операцию сложения на деление, и увидишь, что преобразование к int'у появится явным образом в коде

не вижу, если конечно не рассматривать что делимое расширяется до двойного размера(так это требование архитектуры а не языка Си), для результата один регистр для частного, другой для остатка,
а в умножении сомножители не увеличиваются, для результата два регистра(размерность удваивается)
но если взять ARM то там другое дело, сложение /вычитание для 32 бит вот там то и будет приведение к большему
вот там коды эквивалентны
правда появился режим THUMB, вот с ним я еще не разобрался

Сообщение от Evg По стандарту приводит.

А смысл???
допустим складываю я два чара и получил переполнение, так если я приведу к инту сложу а результат опять к чару, то результат то будет одинаков

Добавлено через 7 минут

Сообщение от Evg Добавлено через 33 минуты

отвечал пока ты уже расширил ответ

Сообщение от Evg Т.е. вариант построения кода на i386 отвечает требованиям "without overflow, or with overflow wrapping silently", т.к. переполнения не вызывают никаких сигналов (которые растут из аппаратных прерываний) и именно поэтому ты в коде не видишь операций преобразования в int

соответственно можно ли это назвать "требование" ужель от архитектуры зависит?
Я уже говорил что я прикладник, и мне эти тонкости как бы нафиг не нужны, работает и ладно
но иногда приходится заниматься "обратным инженерингом", и чаше всего для Винды, так что мои познания из практики

0

Сообщение от ValeryS или я чего то не понимаю или для х86 они как раз не эквивалентны

Под эквивалентностью я подразумевал что при одних и тех же значениях "a" и "b" в обоих кодах в "c" получится один и тот же числовой результат (т.е. без учёта взведения всяких флагов переполнения)

Сообщение от ValeryS не вижу, если конечно не рассматривать что делимое расширяется до двойного размера(так это требование архитектуры а не языка Си)

Согласен, пример с делением был не в кассу

Сообщение от ValeryS А смысл???

Лично для меня в языке Си немало мест, в которых я смысла не вижу. Язык разрабатывался в те года, когда памяти было мало, а процессоры были слабые. Поэтому, как мне кажется, некоторые вещи для людей тех времён очевидны и прозрачны, а нам непонятны. Но стандарт написан, а потому в вопросах "что будет" нужно ориентироваться именно на стандарт, а не на личные ощущения

Сообщение от ValeryS соответственно можно ли это назвать "требование" ужель от архитектуры зависит?

Да, это по сути зависит от архитектуры

Сообщение от Tulosba Т.е. это как бы не совсем та оптимизация, которая задается ключами компилятора

Никто не запрещает компилятору делать оптимизации и безо всяких ключей

0