Многие источники, в том числе Microsoft, ссылаться как на тип int, так и на тип long как 4 байта и иметь диапазон (со знаком) от -2 147 483 648 до 2 147 483 647. Какой смысл иметь длинный примитивный тип, если он на самом деле не предоставляет больший диапазон значений?
Единственное, что гарантировано для целочисленных типов:
sizeof(char) == 1
sizeof(char) <= sizeof(short)
sizeof(short) <= sizeof(int)
sizeof(int) <= sizeof(long)
sizeof(long) <= sizeof(long long)
sizeof(char) * CHAR_BIT >= 8
sizeof(short) * CHAR_BIT >= 16
sizeof(int) * CHAR_BIT >= 16
sizeof(long) * CHAR_BIT >= 32
sizeof(long long) * CHAR_BIT >= 64
Другие вещи определены реализацией. Благодаря (4), оба long
а также int
может иметь одинаковый размер, но он должен быть не менее 32 бит (благодаря (9)).
Стандарт C ++ только указывает, что long
является по крайней мере, такой большой как int
так что в сценарии нет ничего криминального точно такой же большойЭто полностью зависит от реализации. На разных платформах размеры могут иметь значение, например у меня int
размером 4 и long
размером 8 на данный момент на моей машине Linux.
Как уже отмечалось, предположение, лежащее в основе вопроса, верно лишь частично, то есть не подходит для некоторых платформ. Если вы действительно хотите понять, как мы пришли к нынешней ситуации, длинный путь до 64 бит Дж. Маши даст вам хорошее представление о различных силах в присутствии и о том, как они взаимодействовали.
Краткое резюме, C началось с char
(8 бит) и int
(16 бит). Затем один добавил short
(16 бит) и long
(32 бита), в то время как int
может быть 16 или 32 бита в зависимости от того, что было естественным на платформе и давления обратной совместимости. Когда пришло 64 бита, long long
был добавлен как 64-битный тип, и были внесены некоторые изменения в меньшие типы на 64-битных платформах. Вещи, стабилизированные с 32 битами int
, но long
сохранил различные определения, некоторые 64-битные платформы имеют 64-битные long
в то время как другие (возможно, только Windows?) держали long
до 32 бит, вероятно, из-за разного давления обратной совместимости (Unix долгое время предполагал long
равный размеру указателя, в Windows было больше остатков API того времени, когда int
было 16 битов и, таким образом, long
был единственный 32-битный тип). BTW typedefs (intXX_t
, intptr_t
) были добавлены, чтобы помочь прояснить намерение, рискуя intXX_t
семья, чтобы заставить постоянный размер, где никто не был действительно необходим.
Нет, это только 4 байта на определенных платформах. Стандарт C ++ оставляет размер как определяемый реализацией.
На других платформах он может быть другого размера.
Это не обязательно должно быть больше. Например, GCC, как правило, long
быть определенным как 8 байтов, когда я использовал это на своей машине. Формулировка стандарта обычно гласит, что эти типы должны быть размером не менее X (например, посмотрите наконец-нормируется long long
в C ++ 11.
По сути, любой человек может делать то, что он хочет, если это соответствует требованиям. Согласно стандарту, кто-то может сделать long long
256 бит, и это было бы совершенно законно.
Спецификация языка C ++ просто утверждает, что размер long
должен быть как минимум размером с int
,
Раньше было стандартно иметь int
= 2 байта и long
= 4 байта. По какой-то причине int
вырос и long
остался прежним (по крайней мере на компиляторах Windows). Я могу только предположить, что long
был сохранен тот же по причинам обратной совместимости …
Никто не ответил на ваш актуальный вопрос, кроме, может быть, AProgrammer.
Стандарт C / C ++ определяется как описано Griwes. Это позволяет реализовать язык C и C ++, где поставщик компилятора может определить размеры, наиболее удобные для архитектуры компьютера. Некоторое время (для Windows 3.1 и ранее, то есть до Windows 95) код C для Windows имел 16-битное значение типа int, тогда как многие платформы UNIX, такие как Solaris, HPUX и AIX, имели 32-разрядное значение типа int.
Тем не менее, современные микрокомпьютеры (начиная с 386) имеют полные 32-битные регистры, и адресация памяти, выровненная по 32 битам, выполняется намного быстрее, чем доступ к 16-битным приращениям. Таким образом, код гораздо эффективнее с 32-битным int, особенно для массивов int, чем с 16-битным int.
Чтобы симулировать 16-битное int в 32-битном регистре, вам также нужно переполнить 16-й бит вместо 32-го. Так что с 32-битным int проще, даже если у вас есть только 32-битные доступные долго.
Я думаю, что это зависит от реализации. Они могут различаться, но поставщик должен их поставлять. Однако некоторые поставщики просто делают это так, чтобы они синтаксически «поддерживались» (т.е. вы можете поместить их в свой код, и они будут компилироваться, но не будут отличаться). Время от времени вы сталкиваетесь с такой особенностью языка.