64 位機器上的 C++ 內存對齊

Question

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

  private:
     uint16 temp_var;
};

有什么理由不應該讓這個變量 uint16 變成完整的 uint64？ 這樣做（uin16），我會在對象中留下內存“漏洞”嗎？，我被告知處理器在處理完整的 uint64 時效率更高。 為了澄清起見， temp_var 是唯一的成員變量。 並且沒有我將它用於 size(temp_var) 或用作循環回零的計數器

謝謝大家的意見，謝謝。。

Answer 1

如果問題是，編譯器是否可以進行替換：

你要求一個uint16所以它給了你一個uint16 。 得到其他東西會令人驚訝。

例如，想象一下如果開發人員指望整數上溢或下溢的行為。 在這種情況下，如果編譯器在幕后替換了uint64 ，那么對於開發人員來說，這將是一個令人驚訝的問題。

同樣，人們會期望sizeof(temp_var)等於sizeof(uint16) 。

在其他情況下，這種替換可能會導致開發人員無法預料的意外行為。

---

如果問題是，您是否可以讓開發人員選擇其他內容：

當然，如果你想要一個這樣大小的變量，你可以。 那么，你不會的一些可能性如何......

如果您依賴uint16上溢/下溢行為，那么您當然希望堅持這一點。

或者，也許這些數據將被傳遞到某個僅支持uint16范圍內的值的更遠的位置，因此保留該大小可能具有邏輯意義，以嘗試隱式記錄有效內容和/或避免編譯器警告。

同樣，出於與程序其他部分相關的某些邏輯原因，您可能希望sizeof(temp_var)為 2 個字節而不是 8 個字節。

我也希望有一些可以使用包裝 pragma 玩的游戲，但我認為這與預期的問題無關。

根據程序的目標，代碼的邏輯一致性或清晰度可能比最大可能的性能更重要（尤其是在關注成員變量的大小/類型的微觀層面）。 換句話說， uint16對於許多用例來說仍然足夠快。

但是，在某些情況下，不會有任何令人信服的理由以一種或另一種方式做出決定。 在這一點上，我會根據個人感受選擇任何似乎最有意義的東西。