Вопрос про названия арифметических типов C++

velkin velkin

С символьным типом всё понятно.

код размер тип полное название
char узкий символьный тип узкий символьный тип
wchar_t широкий символьный тип широкий символьный тип

С вещественным тоже.

код тип точность полное название
float вещественный тип одинарной точности вещественный тип одинарной точности
double вещественный тип двойной точности вещественный тип двойной точности
long double вещественный тип расширенной точности вещественный тип расширенной точности

А что насчёт целого типа?

код размер тип полное название
short короткий целый тип короткий целый тип
int ??? целый тип ??? целый тип
long длинный целый тип длинный целый тип
long long ??? целый тип ??? целый тип
Что-то с ходу не нахожу названий.
int — обычный, стандартный, нормальный, дефолтный, средний???
long long — длинный длинный, очень длинный, расширенный???

Может кто помнит из какой-нибудь книги, статьи или спецификации где это явно упоминалось?
SаNNy
SаNNy
15.10.2021 06:21
int — базовый целочисленный тип
velkin
velkin
15.10.2021 08:09
Здравствуйте, SаNNy, Вы писали:

SNN>int — базовый целочисленный тип


Хороший вариант, по-русски значит основной.
Patalog
Patalog
15.10.2021 08:24
Здравствуйте, velkin, Вы писали:

Какая-то уж совсем калька с английского. Почему для символьных широкий\узкий, а для целых длинный\короткий? А для вещественных — вообще одинарный\двойной\расширеный? Может размер задавать в байтах (или CHAR_BITS)? Смысл в этих широкий\узкий? А если уж очень надо, то может свести все к единообразному уменьшенный\базовый\увеличенный (расширеный). Хотя для вещественныхтда, имеет смысл оставить одинарный\двойной.

хъ

V>int — обычный, стандартный, нормальный, дефолтный, средний???


основной (базовый)

V>long long — длинный длинный, очень длинный, расширенный???

long — расширенный основной (базовый) (раз уж long double расширенный)
long long — увеличенный\двойной\расширенный двойной основной (базовый)
velkin
velkin
15.10.2021 08:56
Здравствуйте, Patalog, Вы писали:

P>Какая-то уж совсем калька с английского.


Так и есть.

P>Почему для символьных широкий\узкий, а для целых длинный\короткий?


Язык программирования C++. Специальное издание

4.3. Символьные типы


Тип wchar_t специально предназначен для хранения более широкого диапазона кодов, характерных, например, для кодировки Unicode. Размер этого типа данных зависит от реализации и всегда достаточен для хранения самого широкого символьного набора, поддерживающего ту или иную национальную специфику (см. §21.7и §С.З.З). Странное имя этого типа досталось от языка С. В языке С этот тип не является встроенным, а определяется с помощью оператора typedef (§4.9.7). Суффикс _t специально применяется с целью четкого указания на то, что тип определен с помощью typedef.

Так понимаю wchar_t это wide character — typedef. А обычный char зовут узким от английского narrow и это антоним широкому от английского wide.

Короткий и длинный это соответственно short и long.

P>А для вещественных — вообще одинарный\двойной\расширенный?


Язык программирования C++. Специальное издание

4.5. Типы с плавающей запятой


Типы с плавающей запятой соответствуют числам с плавающей запятой. Как и целые типы, они могут быть трех размеров: float (одинарная точность), double (двойная точность) и long double (расширенная точность).

Точный смысл каждого типа зависит от реализации. Выбор оптимальной точности в конкретных задачах требует изрядных знаний в области вычислений с плавающей запятой. Если у вас их нет, то проконсультируйтесь со специалистом, или основательно изучите предмет, или используйте тип double наудачу.

Конечно, это русский перевод, но я пока ориентируюсь на него. Если Страуструп говорит, что вот это одинарная, двойная и расширенная точность, то как создателю языка я ему верю.

P>Может размер задавать в байтах (или CHAR_BITS)? Смысл в этих широкий\узкий? А если уж очень надо, то может свести все к единообразному уменьшенный\базовый\увеличенный (расширенный). Хотя для вещественных да, имеет смысл оставить одинарный\двойной.


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

предпочтительные встроенные типы данных


логический: bool
символьный: char
целый: int
вещественный: double
пустой: void

А для уточнения добавляю новые списки. С учётом комментариев выше вот так.

предпочтительная краткая форма записи встроенных целых типов данных


короткий: short
основной: int
длинный: long
расширенный: long long

Про long long пока не знаю, у меня есть новые книжки, но в основном пока смотрю по старым, а там такого даже и нет.
σ
σ
15.10.2021 11:35
V>Язык программирования C++. Специальное издание
V>

4.3. Символьные типы

Тип wchar_t специально предназначен для хранения более широкого диапазона кодов, характерных, например, для кодировки Unicode. Размер этого типа данных зависит от реализации и всегда достаточен для хранения самого широкого символьного набора, поддерживающего ту или иную национальную специфику (см. §21.7и §С.З.З). Странное имя этого типа досталось от языка С. В языке С этот тип не является встроенным, а определяется с помощью оператора typedef (§4.9.7). Суффикс _t специально применяется с целью четкого указания на то, что тип определен с помощью typedef.

V>Так понимаю wchar_t это wide character — typedef.

В C++ ­— не typedef.
σ
σ
15.10.2021 11:36
Совсем ОКР замучило?
AleksandrN
AleksandrN
15.10.2021 02:29
Здравствуйте, velkin, Вы писали:

V>Что-то с ходу не нахожу названий.

V>int — обычный, стандартный, нормальный, дефолтный, средний???
V>long long — длинный длинный, очень длинный, расширенный???

V>Может кто помнит из какой-нибудь книги, статьи или спецификации где это явно упоминалось?


В старых книгах по C упоминалось, что int — сокращение от integer.
А short и long можно записать как short int и long int.
unsigned int можно записывать как unsigned.

Раньше, в чистом Си можно было опускать int ещё в некоторых случаях. Например — если функция возвращает тип int, то его можно было не указывать и писать
main()
{
...
return 0;
}
velkin
velkin
15.10.2021 03:24
Здравствуйте, AleksandrN, Вы писали:

AN>В старых книгах по C упоминалось, что int — сокращение от integer.


Это думаю большинству известно, так же как bool это boolean, char это character и так далее. У меня так и написано — целый, от слова integer по английски. Другое дело прилагательное к int и long long int.

Язык программирования C++. Специальное издание

4.4. Целые типы

Как и тип char, каждый целый тип представим в трех формах: «просто» int, signed int и unsigned int. Кроме того, целые могут быть трех размеров: short int, «просто» int и long int. Вместо long int можно просто писать long. Аналогично, short есть синоним для short int, unsigned — для unsigned int, a signed — для signed int.

Беззнаковые (unsigned) целые типы идеальны для трактовки блоков памяти как битовых массивов. Использование unsigned вместо int с целью заполучить лишний бит для представления целых положительных значений почти всегда является неудачным решением. А попытки гарантировать положительность числовых значений объявлением целой переменной с модификатором unsigned опровергаются правилами неявных преобразований типов (§С.6.1, §С.6.2.1).

В отличие от типа «просто» char, типы «просто» int всегда знаковые (signed). Явное применение модификатора signed лишь подчеркивает этот факт.

Но я же не буду называть "int" как "просто int" или "просто целый", тогда уж лучше писать "целый" без "просто". Тем не менее в данном контексте есть пустое место, которое надо заполнить. Опять же long long или длинный длинный, звучит слишком по анимешному. Мне вот интересно чтобы они дальше придумали, если бы надо было ещё расширить размер целого типа. По хорошему могли бы изначально дать возможность явно указывать битность, но увы всё это не стандарт языка.
_NN_
_NN_
15.10.2021 05:27
Здравствуйте, velkin, Вы писали:
V>[/q]
V>Но я же не буду называть "int" как "просто int" или "просто целый", тогда уж лучше писать "целый" без "просто". Тем не менее в данном контексте есть пустое место, которое надо заполнить. Опять же long long или длинный длинный, звучит слишком по анимешному. Мне вот интересно чтобы они дальше придумали, если бы надо было ещё расширить размер целого типа. По хорошему могли бы изначально дать возможность явно указывать битность, но увы всё это не стандарт языка.

Возможность дали: https://en.cppreference.com/w/cpp/types/integer
Основные типы они платформенно-зависимые и их размер не фиксирован.
cppguard
cppguard
18.10.2021 09:35
Здравствуйте, velkin, Вы писали:

V>Может кто помнит из какой-нибудь книги, статьи или спецификации где это явно упоминалось?


Могу ошибаться, но после годов разработки на Си сложилось ощущение, что с помощью short и long пытались создать какое-то подобие бесконечно портируемой программы в том смысле, что один и тот же код работал бы (по идее создателей) одинаково, занимая при этом разное количество памяти. Типа объявил счётчик short, и на микроволновке этот счётчик займёт 1 байт, а на серверной платформе — 8. А типобезопастность (по идее) должна выстраиваться за счёт гарантий размера char <= short <= int <= long. Потому что кроме этих гарантий стандарт не наёт нам ничего, но зато охотно ставит подножки тут и там в виде неявных приведений к int. Судя по всему, все мечты разбились об острые камни реальности, потому что в С99 ввели типы фиксированного размера, после чего уже действительно стало легче писать платформонезависимый код.
velkin
velkin
18.10.2021 02:59
Здравствуйте, cppguard, Вы писали:

C>Могу ошибаться, но после годов разработки на Си сложилось ощущение, что с помощью short и long пытались создать какое-то подобие бесконечно портируемой программы в том смысле, что один и тот же код работал бы (по идее создателей) одинаково, занимая при этом разное количество памяти.


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

А потом оставили всё для обратной совместимости старых программ, так как тем не мог повредить переход на более высокую разрядность, хотя оптимизация бы пострадала. С другой стороны в обратном случае получаем неопределённое поведение. Так что надо было бы сразу давать программистам обозначать размер типа, но как писал выше до этого просто сразу не додумались.

Плюс старые имена в C++ выражают некие идеи, типа char — character символьные, хотя по факту это int8, или bool — boolean двоичные, но могли бы просто обозначить как int1, даже если бы реализация была сделана с помощью int8 или лучше сказать соответствующими командами процессора.

У меня Qt под виндой 32-битный, а под GNU/Linux 64-битный, и вот результат команды sizeof() в mingw32/gcc64.
тип x32 значение x64 значение x32 указатель x64 указатель
bool 1 1 4 8
char 1 1 4 8
short 2 2 4 8
int 4 4 4 8
long 4 8 4 8
long long 8 8 4 8
float 4 4 4 8
double 8 8 4 8
long double 12 16 4 8
Когда дело касается указателей для каждого типа, то получаем ожидаемое. Но когда дело касается размеров значений, то это не то, чтобы я хотел видеть. Более того, это ладно ещё 32-ух и 64-ёх битная архитектура, а не более младшие. Я бы скорее ожидал от long поведение long long.

На фоне этого тот же long double более приемлем, типа хочешь ещё больше точности после float и double, чем есть, иди меняй процессор. А вот с целым long всё запутано, как будь-то он перешёл с 16-битной архитектуры. И опять у меня в таблице лишь одна из реализаций компиляторов языка.

И возникает вопрос, если забить на 16-битную архитектуру, то в каких случаях можно и нужно использовать long? Сидишь такой и думаешь, мне в общем-то и 4 байт для данных хватило бы, но если будет 8 байт, то вроде бы и хорошо, но 8 байт не гарантированы.

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

Тема то, конечно, про названия, а не размеры типов.