Вопрос про названия арифметических типов C++
15.10.2021
|
velkin |
С символьным типом всё понятно.
код | размер | тип | полное название |
---|---|---|---|
char | узкий | символьный тип | узкий символьный тип |
wchar_t | широкий | символьный тип | широкий символьный тип |
С вещественным тоже.
код | тип | точность | полное название |
---|---|---|---|
float | вещественный тип | одинарной точности | вещественный тип одинарной точности |
double | вещественный тип | двойной точности | вещественный тип двойной точности |
long double | вещественный тип | расширенной точности | вещественный тип расширенной точности |
А что насчёт целого типа?
код | размер | тип | полное название |
---|---|---|---|
short | короткий | целый тип | короткий целый тип |
int | ??? | целый тип | ??? целый тип |
long | длинный | целый тип | длинный целый тип |
long long | ??? | целый тип | ??? целый тип |
int — обычный, стандартный, нормальный, дефолтный, средний???
long long — длинный длинный, очень длинный, расширенный???
Может кто помнит из какой-нибудь книги, статьи или спецификации где это явно упоминалось?
15.10.2021 11 комментариев |
SNN>int — базовый целочисленный тип
Хороший вариант, по-русски значит основной.
Какая-то уж совсем калька с английского. Почему для символьных широкий\узкий, а для целых длинный\короткий? А для вещественных — вообще одинарный\двойной\расширеный? Может размер задавать в байтах (или CHAR_BITS)? Смысл в этих широкий\узкий? А если уж очень надо, то может свести все к единообразному уменьшенный\базовый\увеличенный (расширеный). Хотя для вещественныхтда, имеет смысл оставить одинарный\двойной.
хъ
V>int — обычный, стандартный, нормальный, дефолтный, средний???
основной (базовый)
V>long long — длинный длинный, очень длинный, расширенный???
long — расширенный основной (базовый) (раз уж long double расширенный)
long long — увеличенный\двойной\расширенный двойной основной (базовый)
P>Какая-то уж совсем калька с английского.
Так и есть.
P>Почему для символьных широкий\узкий, а для целых длинный\короткий?
Язык программирования C++. Специальное издание
Так понимаю wchar_t это wide character — typedef. А обычный char зовут узким от английского narrow и это антоним широкому от английского wide.
Короткий и длинный это соответственно short и long.
P>А для вещественных — вообще одинарный\двойной\расширенный?
Язык программирования C++. Специальное издание
Конечно, это русский перевод, но я пока ориентируюсь на него. Если Страуструп говорит, что вот это одинарная, двойная и расширенная точность, то как создателю языка я ему верю.
P>Может размер задавать в байтах (или CHAR_BITS)? Смысл в этих широкий\узкий? А если уж очень надо, то может свести все к единообразному уменьшенный\базовый\увеличенный (расширенный). Хотя для вещественных да, имеет смысл оставить одинарный\двойной.
Для меня главный смысл в том, чтобы случайно не выдумать отсебятину, которую другие люди не будут понимать или которая может вводить в заблуждение. Потому я создал список предпочтительных типов данных.
А для уточнения добавляю новые списки. С учётом комментариев выше вот так.
Про long long пока не знаю, у меня есть новые книжки, но в основном пока смотрю по старым, а там такого даже и нет.
V> V>Так понимаю wchar_t это wide character — typedef.
В C++ — не typedef.
V>Что-то с ходу не нахожу названий.
V>int — обычный, стандартный, нормальный, дефолтный, средний???
V>long long — длинный длинный, очень длинный, расширенный???
V>Может кто помнит из какой-нибудь книги, статьи или спецификации где это явно упоминалось?
В старых книгах по C упоминалось, что int — сокращение от integer.
А short и long можно записать как short int и long int.
unsigned int можно записывать как unsigned.
Раньше, в чистом Си можно было опускать int ещё в некоторых случаях. Например — если функция возвращает тип int, то его можно было не указывать и писать
main()
{
...
return 0;
}
AN>В старых книгах по C упоминалось, что int — сокращение от integer.
Это думаю большинству известно, так же как bool это boolean, char это character и так далее. У меня так и написано — целый, от слова integer по английски. Другое дело прилагательное к int и long long int.
Язык программирования C++. Специальное издание
Но я же не буду называть "int" как "просто int" или "просто целый", тогда уж лучше писать "целый" без "просто". Тем не менее в данном контексте есть пустое место, которое надо заполнить. Опять же long long или длинный длинный, звучит слишком по анимешному. Мне вот интересно чтобы они дальше придумали, если бы надо было ещё расширить размер целого типа. По хорошему могли бы изначально дать возможность явно указывать битность, но увы всё это не стандарт языка.
V>[/q]
V>Но я же не буду называть "int" как "просто int" или "просто целый", тогда уж лучше писать "целый" без "просто". Тем не менее в данном контексте есть пустое место, которое надо заполнить. Опять же long long или длинный длинный, звучит слишком по анимешному. Мне вот интересно чтобы они дальше придумали, если бы надо было ещё расширить размер целого типа. По хорошему могли бы изначально дать возможность явно указывать битность, но увы всё это не стандарт языка.
Возможность дали: https://en.cppreference.com/w/cpp/types/integer
Основные типы они платформенно-зависимые и их размер не фиксирован.
V>Может кто помнит из какой-нибудь книги, статьи или спецификации где это явно упоминалось?
Могу ошибаться, но после годов разработки на Си сложилось ощущение, что с помощью short и long пытались создать какое-то подобие бесконечно портируемой программы в том смысле, что один и тот же код работал бы (по идее создателей) одинаково, занимая при этом разное количество памяти. Типа объявил счётчик short, и на микроволновке этот счётчик займёт 1 байт, а на серверной платформе — 8. А типобезопастность (по идее) должна выстраиваться за счёт гарантий размера char <= short <= int <= long. Потому что кроме этих гарантий стандарт не наёт нам ничего, но зато охотно ставит подножки тут и там в виде неявных приведений к int. Судя по всему, все мечты разбились об острые камни реальности, потому что в С99 ввели типы фиксированного размера, после чего уже действительно стало легче писать платформонезависимый код.
C>Могу ошибаться, но после годов разработки на Си сложилось ощущение, что с помощью short и long пытались создать какое-то подобие бесконечно портируемой программы в том смысле, что один и тот же код работал бы (по идее создателей) одинаково, занимая при этом разное количество памяти.
Может и так, но тогда идея делать типы не фиксированными для портируемости странная, так как скорее достигается обратный эффект. Это лишь мои догадки, но мне кажется дело в том, что разрядность команд процессоров увеличивалась, а старые программы оставались. До создателей стандарта языка заранее не дошло, что разрядность команд процессоров будет увеличиваться, потому они и сделали то, что сделали.
А потом оставили всё для обратной совместимости старых программ, так как тем не мог повредить переход на более высокую разрядность, хотя оптимизация бы пострадала. С другой стороны в обратном случае получаем неопределённое поведение. Так что надо было бы сразу давать программистам обозначать размер типа, но как писал выше до этого просто сразу не додумались.
Плюс старые имена в C++ выражают некие идеи, типа char — character символьные, хотя по факту это int8, или bool — boolean двоичные, но могли бы просто обозначить как int1, даже если бы реализация была сделана с помощью int8 или лучше сказать соответствующими командами процессора.
У меня Qt под виндой 32-битный, а под GNU/Linux 64-битный, и вот результат команды sizeof() в mingw32/gcc64.
На фоне этого тот же long double более приемлем, типа хочешь ещё больше точности после float и double, чем есть, иди меняй процессор. А вот с целым long всё запутано, как будь-то он перешёл с 16-битной архитектуры. И опять у меня в таблице лишь одна из реализаций компиляторов языка.
И возникает вопрос, если забить на 16-битную архитектуру, то в каких случаях можно и нужно использовать long? Сидишь такой и думаешь, мне в общем-то и 4 байт для данных хватило бы, но если будет 8 байт, то вроде бы и хорошо, но 8 байт не гарантированы.
А если хватит 4 байт, то зачем тогда использовать 8 байт. Мне в голову приходит лишь хранение указателя на память в ячейке значений, да и то это вилами по воде писано, так как похоже является лишь совпадением, а не стандартом языка.
Тема то, конечно, про названия, а не размеры типов.