Это во многом зависит от использования.
- Обычно вы можете заставить компилятор оптимизировать пространство.
- Доступ к объектам более оптимален при выравнивании по границе памяти, которая является кратный их размеру (на большинстве архитектур).
Таким образом, компилятор может вводить пространство для лучшего выравнивания.
Обычно это происходит, когда требуется, чтобы объекты разных размеров находились рядом друг с другом. - Компилятору НЕ разрешено изменять порядок переменных в структуре (если они находятся в одном и том же частном / публичном / защищенном разделе).
- Я не верю, что существуют какие-либо требования упорядочение переменных в фрейме локального стека. Таким образом, компилятор должен иметь возможность оптимально упаковать локальные переменные и оптимально использовать все доступное пространство (даже потенциально повторно использовать пространство для переменных POD или никогда не использовать пространство, если он может хранить его в регистре).
Но если у вас есть структура, которая использует объекты того же размера.
struct X
{
short var1;
short var2;
}
Тогда, скорее всего, в вышеуказанной структуре не будет заполнения (нет гарантии, но, скорее всего, нет заполнения).
Из-за пункта 3 выше: если вы хотите помочь вашему компилятору оптимально упаковать структуру, то компилятору, безусловно, будет проще упорядочивать ваши элементы от самых больших до самых маленьких, так как это упрощает упаковку без необходимости заполнения ( но стандарт не предъявляет никаких требований к заполнению).
// if we assume sizeof(int) == 8
struct Y
{
char x; // 1 byte;
// Compiler will (prob) insert 7 bytes of padding here.
// to make sure that y is on an 8 byte boundry
// for most effecient reads.
int y;
char z; // 1 byte
// Compiler will (prob) insert 7 bytes of padding here.
// to make sure that the whole structure has a size
// that is a multiple of 8 (the largest object)
// This allows for optimal packing of arrays of type
// Y.
};
Компилятор все еще может добиться оптимальной упаковки и быстрого доступа, если вы расположите объект следующим образом:
struct Y
{
int y;
char x;
char z;
// probably add 6 bytes of padding.
// So that we get optimal access to objects in an array.
};
для примера давайте предположим, что для определенного современного компьютера:
Если мы предполагаем современный хороший компилятор, такой как clang или g ++, на обычной машине с стандартной архитектурой. Даже если мы предположим, что не оптимизируем по скорости.
Будет ли короткое время фактически занимать меньше памяти
Да. Современный компилятор максимально упакует объекты и, вероятно, использует только требуемую память. Примечание: большинство компиляторов по умолчанию будут оптимизировать по скорости, поэтому будут поддерживать оптимальное выравнивание по скорости, поэтому будут дополняться, если это необходимо (если объекты в структуре, которую они не могут переупорядочить, имеют разные размеры).
или он будет просто сохранен в первой половине WORD с неиспользуемой памятью во второй половине?
Маловероятно, если нет каких-либо требований, которые должен поддерживать компилятор , Как порядок структуры.
Попытается ли когда-нибудь компилятор C / C ++ упаковать две или более переменные меньшего размера в одно WORD
Да. Все время. По умолчанию обычно. 1 Оптимизация по скорости. 2 Оптимизация по размеру (не всегда взаимоисключающая). Вы также можете заставить современные компиляторы оптимизировать пространство и упаковать структуры без заполнения.
или это пространство всегда будет потрачено впустую?
Маловероятно.