Я думаю, что этот вопрос состоит из двух частей:

1. Какие размеры примитивных типов разрешены быть.
   Это определяется стандартами C и C ++: типы имеют допустимые диапазоны минимальных значений, которые они должны иметь, что неявно устанавливает нижнюю границу их размера в битах (например, long must быть не менее 32 бит, чтобы соответствовать стандарту).
   В стандартах не указывается размер в байтах, потому что определение байта зависит от реализации, например char - это байт, но размер байта (макрос CHAR_BIT) может быть 16 бит.

2. Фактический размер, определенный реализацией.
   Это, как уже указывалось в других ответах, зависит от реализации: компилятора. А реализация компилятора, в свою очередь, сильно зависит от целевой архитектуры. Поэтому вполне вероятно, что два компилятора будут работать в одной ОС и с одной архитектурой, но имеют разный размер int. Единственное предположение, которое вы можете сделать, - это то, что указано в стандарте (при условии, что компилятор его реализует).
   Также могут быть дополнительные требования к ABI (например, фиксированный размер перечислений).

В первую очередь, это зависит от компилятора. Компилятор, в свою очередь, обычно зависит от архитектуры, процессора, среды разработки и т. Д., Потому что он их учитывает. Так что вы можете сказать, что это комбинация всего. Но я бы НЕ сказал этого. Я бы сказал, компилятор, поскольку на одной машине у вас могут быть разные размеры POD и встроенных типов, если вы используете разные компиляторы. Также обратите внимание, что ваш исходный код вводится в компилятор, поэтому именно компилятор принимает окончательное решение о размерах POD и встроенных типов. Однако верно и то, что на это решение влияет архитектура, лежащая в основе целевой машины. В конце концов, настоящий полезный компилятор должен генерировать эффективный код, который в конечном итоге запускается на целевой машине.

Компиляторы тоже предоставляют options. Некоторые из них также могут повлиять на размер!

РЕДАКТИРОВАТЬ: Что говорят стандарты,

Размер char, signed char и unsigned char определяется самим стандартом C ++! Размеры всех остальных типов определяются компилятором.

C ++ 03 Standard $ 5.3.3 / 1 говорит:

sizeof (char), sizeof (подписанный char) и sizeof (unsigned char) равны 1; результат применения sizeof к любому другому фундаментальному типу (3.9.1) определяется реализацией. [Примечание: в частности, sizeof (bool) и sizeof (wchar_t) определяются реализацией.69)

Стандарт C99 ($ ​​6.5.3.4) также сам определяет размер char, signed char и unsigned char равным 1, но оставляет размер других типов определяемым компилятором!

РЕДАКТИРОВАТЬ:

Я нашел эту главу часто задаваемых вопросов по C ++ действительно хорошей. Вся глава. Хотя это очень крошечная глава. :-)

http://www.parashift.com/c++-faq-lite/intrinsic-types.html

Также читайте комментарии ниже, есть несколько хороших аргументов!

Если вы спрашиваете о размере примитивного типа, такого как int, я бы сказал, что это зависит от указанного вами фактора.

Пара компилятор / среда (где среда часто означает ОС), безусловно, является ее частью, поскольку компилятор может отображать различные «разумные» размеры на встроенных типах разными способами по разным причинам: например, компиляторы на x86_64 Windows обычно будут иметь 32-битный long и 64-битный long long, чтобы избежать нарушения кода, продуманного для простого x86; в x86_64 Linux вместо этого long обычно 64-битный, потому что это более «естественный» выбор, а приложения, разработанные для Linux, обычно более независимы от архитектуры (поскольку Linux работает на гораздо большем разнообразии архитектур).

Процессор, безусловно, имеет значение в решении: int должен быть "естественным размером" процессора, обычно размером регистров общего назначения процессора. Это означает, что этот тип будет работать быстрее в текущей архитектуре. long вместо этого часто считается типом, который жертвует производительностью в пользу расширенного диапазона (это редко бывает верно для обычных ПК, но для микроконтроллеров это нормально).

Если вместо этого вы также говорите о structs & co. (которые, если они соблюдают некоторые правила, являются POD), компилятор и процессор снова влияют на их размер, поскольку они состоят из встроенных типов и соответствующих отступов, выбранных компилятором для достижения наилучшего производительность на целевой архитектуре.

Как я прокомментировал в ответе @Nawaz, технически это зависит исключительно от компилятора.

Компилятору просто поручено взять действительный код C ++ и вывести действительный машинный код (или любой другой язык, на который он нацелен).

Таким образом, компилятор C ++ мог решить сделать int размером 15 и потребовать, чтобы он был выровнен по 5-байтовым границам, и он мог решить вставить произвольное заполнение между переменными в POD. Ничто в стандарте не запрещает этого, и он все равно может генерировать рабочий код.

Просто было бы намного медленнее.

Таким образом, на практике компиляторы получают некоторые подсказки от системы, в которой они работают, двумя способами: - ЦП имеет определенные предпочтения: например, он может иметь 32-битные регистры, поэтому создание int 32-битной ширины будет хорошая идея, и обычно требуется, чтобы переменные были естественным образом выровнены (например, переменная шириной 4 байта должна быть выровнена по адресу, кратному 4), поэтому разумный компилятор уважает эти предпочтения, потому что он дает более быстрый код. - ОС тоже может иметь некоторое влияние, поскольку, если она использует другой ABI, чем компилятор, выполнение системных вызовов будет излишне трудным.

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

Последнее слово остается за компилятором, и он может полностью игнорировать как ЦП, так и ОС. Пока он генерирует рабочий исполняемый файл с семантикой, указанной в стандарте C ++.

Это зависит от реализации (компилятора).

Implementation-defined behavior означает неопределенное поведение, при котором каждая реализация документирует, как сделан выбор.

struct также может быть POD, и в этом случае вы можете явно контролировать возможное заполнение между членами с помощью #pragma pack на некоторых компиляторах.