我正在閱讀C++的參考文獻，並且發現爲了確保定義爲const的對象的ROM性能：
1.類或結構必須沒有用戶定義的構造函數
2.不能有基類或具有用戶定義的構造函數或析構函數的成員對象。
我正在參考按位const而不是可變常量。
在我看來，第一個持有是因爲構造函數或析構函數修改了常量數據成員。所以，我們不要使用用戶定義的構造函數或析構函數。
但我不能得到第二點的好解釋。爲什麼類或結構必須沒有用戶定義的構造函數或析構函數來確保C++中的const的ROMability？
構造函數/析構函數會修改該對象，這會違背它存儲在ROM中。
如果類包含對象或繼承構造函數，那仍然是必須運行以構造對象的代碼（成員與父對象一起存儲）。在編譯時這是不可能的（當ROM對象被組裝時）。
關於構造函數的一點是不正確的：有編譯時可以運行的構造函數。在C++ 03中，它由編譯器做臨時編譯（編譯器不會阻止這樣做，並且一些編譯器會這樣做）：在C++ 11中，有明確的方法來堅持它發生（實際上）。有一個構造函數並不總是以任何基本的方式阻止存儲在相當於'ROM'的東西中。 – Yakk 2013-03-11 13:27:25
正如你所說，第一點是必要的，因爲具有用戶定義的構造函數的對象在運行時被初始化（在運行之前的動態初始化階段期間，如果它們具有靜態生命週期），所以不能放置在只讀存儲器中，因爲初始化必須修改對象的內存。
第二點來自第一點 - 如果（非靜態）成員或基礎子對象具有用戶定義的構造函數，則該構造函數還必須用於在運行時初始化成員或子對象。因此，至少部分對象不能存儲在只讀存儲器中;所以對象本身不能。
這看起來像C++ 03中的POD的定義。 POD表示普通的舊數據。一個const的全局實例可能被某個編譯器和平臺放置在ROM中。
C++ 11增加了可映射到ROM able的新語言功能。它們之間的構造函數和標準佈局類型對於某些編譯器可以放入ROM的內容可能是一組合理的限制。但這將取決於編譯器對數據的支持。
定義** ROMability **。這不是一個標準術語AFAIK。 – 2013-02-28 15:27:14
你必須定義「ROMability」是什麼意思？是將_code_放入ROM中，還是將一個完整的_object_放入ROM中？如果是後者，那麼這個類不能包含修改對象的任何代碼（你不能修改ROM），但如果只是存儲代碼，並且你在RAM中創建對象，那麼就沒有這樣的限制。 – 2013-02-28 15:28:31
如果一個對象被定義爲const，它將被放入ROM中，這在嵌入式系統編程中經常是一個重要的考慮因素。所以我在這個參考文獻中提出要確保這些點爲什麼能保持。 – 2013-02-28 15:29:02