Каков «размер максимально возможного объекта на целевой платформе»? с точки зрения size_t
Я читаю статью о size_t в C / C ++ http://web.archive.org/web/20081006073410/http://www.embedded.com/columns/programmingpointers/200900195 (ссылка найдена через Stackoverflow).
Цитата из статьи:
Тип size_t является typedef, который является псевдонимом для некоторого целого числа без знака
тип, обычно unsigned int или unsigned long, но, возможно, даже
без знака долго долго. Каждая реализация стандарта C должна
выберите целое число без знака, достаточно большое, но не больше
needed—представлять размер максимально возможного объекта на
целевая платформа.
Как я могу определить размер максимально возможного объекта на моей машине?
Что влияет на размер самого большого объекта (кроме процессора)?
Ссылка на подробное объяснение приветствуется.
Решение
Редактировать: я думаю, что важно учитывать, что этот тип не означает строго, что вы МОЖЕТЕ иметь объект такого размера — просто это целое число, которое достаточно большое, чтобы содержать размер максимально возможного объекта — это не значит, что вы можете использовать SIZE_MAX выделить память. Это просто гарантирует, что максимально возможный объект не может быть БОЛЬШЕ, чем SIZE_MAX,
Это архитектурное решение при реализации компилятора (обычно в зависимости от ОС, на которую ориентирован компилятор, но ОС может предложить БОЛЬШЕ, чем компилятор, или компилятор может поддерживать теоретический объем, превышающий ОС позволяет, просто, что он потерпит неудачу, когда вы попросите это).
На практике это почти всегда определяет процессор — size_t почти всегда соответствует разрядности процессора — например, это 32 бита в 32-битном процессоре и 64 бита в 64-битном процессоре. Но было бы возможно спроектировать систему, в которой она будет 32-битной на 64-битном процессоре — один «объект» не может быть больше 4 ГБ, на самом деле это не такое уж большое ограничение. Это просто означает, что вы не можете использовать один единственный вектор int заполнить более 4 ГБ, поэтому не более 1G записей в vector (или 4G char записей).
Конечно, другим ограничивающим фактором является доступная память — если у вас очень старая машина с 256 МБ ОЗУ, она не позволит вам выделить 4 ГБ, даже если size_t позволяет это. Но дайте той же машине больше памяти, и вы сможете перейти к гораздо большему размеру.
Во многих 32-разрядных системах максимально допустимая память для приложения составляет менее 4 ГБ (полный 32-разрядный диапазон), поскольку некоторая часть памяти «зарезервирована» для других целей. Итак, еще раз, size_t 32 бита, то есть 4 ГБ, но на самом деле он не поддерживает полный объем памяти, который может использоваться одним приложением — с другой стороны, 32-разрядный компьютер может иметь более 4 ГБ ОЗУ и использовать его между несколькими приложениями.
Кроме того, если система была ограничена (по некоторым архитектурным причинам), скажем, до 16 МБ памяти, size_t скорее всего, все еще 32-разрядное целое число без знака — потому что большинство процессоров не делают 24-разрядные целые числа [некоторые DSP могут делать это, но обычные 16 или 32-разрядные процессоры этого не делают].
Другие решения
Компилятору не имеет смысла предоставлять вам информацию о «размере максимально возможного объекта», потому что это зависит от того, чем еще занимается ваша программа. Размер одного объекта может быть ограничен до 231-1 байт в 32-разрядной архитектуре, чтобы избежать проблем переполнения со знаком типа ptrdiff_tили разработчики, возможно, решили не устанавливать такое произвольное ограничение, и в этом случае размер, который может иметь один объект, зависит от того, сколько виртуального пространства зарезервировано для стека, для кода, для переменных области файла, какой ОС ‘ рандомизация адресов Стратегия … Нет единого точного «размера самого большого объекта», если только вы не имеете в виду очевидную верхнюю границу, такую как размер виртуального адресного пространства.
Тип size_t гарантированно позволяет представить размер самого большого объекта, который вы можете выделить при наилучших обстоятельствах: небольшой код, минимальный стек, отсутствие потерь при рандомизации адресного пространства, никаких других переменных. Например, я ожидаю, что некоторые 64-битные ядра (на архитектуре x86-64) могут оставить весь 4 ГБ виртуального адресного пространства для 32-битного процесса, такого как программа, сгенерированная 32-битным компилятором с SIZE_MAX = 232-1, и в этом случае объект может находиться в пределах нескольких мегабайт от теоретического предела. Наибольшее, что я наблюдал на практике, было 2.5GiB для 32-разрядного size_t,