Выравнивание памяти в C ++ на 64-битной машине

Question

Class A
{
  public:
    void fun1();
    void fun2();

  private:
     uint16 temp_var;
};

Есть ли причина, по которой мне не следует просто превращать эту переменную uint16 в полную uint64? Делая это таким образом (uin16), я оставляю «дыры» в памяти объекта?, И мне говорят, что процессор более эффективен в работе с полными uint64s. для пояснения, temp_var является единственной переменной-членом. И не там, где я использовал его для размера (temp_var) или в качестве счетчика для l oop обратно в ноль

Спасибо всем за ваш вклад, ценю это ..

Answer 1

Если вопрос в том, может ли компилятор выполнить подстановку:

Вы запросили uint16, поэтому он дал вам uint16. Было бы удивительно получить что-то еще.

Например, представьте, рассчитывает ли разработчик на поведение целочисленного переполнения или недостаточного заполнения. В этом случае, если компилятор заменит uint64 за кулисами, это будет проблематичным для разработчика.

В том же ключе можно ожидать, что sizeof(temp_var) будет равно sizeof(uint16).

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

---

Если вопрос, можете ли вы, разработчик, выбрать что-нибудь еще:

Конечно, вы можете, если вы хотите переменную этого размера. Итак, как насчет некоторых возможностей, в которых вы бы не ...

Если вы полагаетесь на поведение переполнения / переполнения uint16, тогда, конечно, вы захотите придерживаться этого.

Или, возможно, эти данные будут передаваться в какое-то другое местоположение, которое поддерживает только значения в диапазоне uint16, поэтому оставление этого размера может иметь логический смысл, чтобы попытаться неявно документировать то, что является допустимым, и / или избегать предупреждений компилятора.

Точно так же вы можете захотеть, чтобы sizeof(temp_var) составляло 2 байта вместо 8 по некоторой логической причине, относящейся к другим частям программы.

Я также ожидаю, что есть некоторые игры, в которые можно играть прагма упаковки, но я полагаю, что это не имеет отношения к намеченному вопросу.

В зависимости от цели вашей программы, логическая последовательность или ясность кода могут быть более важными, чем максимально возможная производительность (особенно в микро уровень озабоченности размером / типом переменной-члена). Чтобы сформулировать это по-другому, uint16 все еще достаточно быстр для многих случаев использования.

В некоторых ситуациях, тем не менее, не будет никаких веских причин для принятия решения, так или иначе. В этот момент я бы go со всем, что кажется наиболее разумным с точки зрения личной чувствительности.