「as-if rule」給予編譯器優化或重新排序表達式的權利,這些表達式在某些規則下不會影響程序的輸出和正確性,例如:as-if規則和刪除分配
§1.9.5
一致性實現執行合式程序應 產生相同的可觀察行爲的抽象機的相應實例的具有相同 程序可能執行 之一和相同的輸入。
的cppreference URL我上面鏈接特別提到了揮發性對象的值的特殊規則,以及爲「新的表現形式」,在C++ 14:
新表達有另外的異常從as-if規則:編譯器 可能會刪除對可替換分配函數的調用,即使提供了用戶定義的替換並且具有可觀察的副作用。
我承擔「替換」這裏是被談論例如在
§18.6.1.1.2
更換:C++程序可以定義使用此功能 簽名功能取代了由C++ 標準庫定義的默認版本。
它是正確的,下面mem
可以在AS-如果統治下被刪除或重新排序?
{
... some conformant code // upper block of code
auto mem = std::make_unique<std::array<double, 5000000>>();
... more conformant code, not using mem // lower block of code
}
有沒有一種方法可以確保它不會被移除,並停留在代碼的上下兩部分之間?一個放置良好的易失性(無論是/或揮發性標準偏差::陣列或左邊的自動)浮現在腦海,但由於沒有讀數mem
,我認爲即使這不會幫助在作爲,如果規則。
附註;我一直無法讓visual studio 2015優化mem
和分配。
說明:觀察的方式這將是對OS的分配調用來自兩個塊之間的任何I/O。這一點是針對測試用例和/或試圖在新位置分配對象的。
我相信volatile會幫助那裏,但還有一個問題:沒有任何東西取決於mem值,所以編譯器可以在代碼塊的任何地方移動分配。它可能會在開始時,結束時和其他地方進行分配。 –
@Revolver_Ocelot我不認爲揮發性甚至會有所作爲。 'make_unique'創建一個新對象,就我所知,由於潛在的副作用,C++編譯器不會優化對象的創建。他們可能會退出不必要的構造函數調用,但他們總是確保至少調用一個。否則,使用具有帶副作用的構造函數的RAII對象的代碼無法安全地依賴該模式,而不包含內存障礙。 – JAB
** [intro.execution]/8 **表示「根據抽象機器的規則嚴格評估對易失性對象的訪問」。我把它看作「as-if規則不能應用於volatile對象」,所以它應該有所幫助。 –