2017-08-04 32 views
-2

在C++中,編譯器優化可能通過利用程序中未定義的行爲(如帶符號整數溢出和解引用空指針)產生「意外」程序行爲。如果在生產中使用發佈版本,則在發佈版本中測試程序非常重要。在調試和發佈版本中C#可能存在的不同行爲

在C#中,未定義的行爲很少見。是否有更多的理由使用其它的製造比

  1. 不安全代碼
  2. 多線程定時
  3. 調試/釋放模式啓用/禁用代碼(例如的#if)
之前測試在發佈版本的程序

優化是否可以產生不同的程序行爲,如C++?

+0

例如在UWP項目中,編譯版本與編譯調試時有很大不同(因爲.NET原生工具鏈),您應該始終測試版本。還有像'#if DEBUG'這樣的開關,您應該知道。我會說,測試發行版本總是一個很好的做法。 – Kedrzu

+0

[堆棧可能因優化而崩潰](https://www.hanselman.com/blog/ReleaseISNOTDebug64bitOptimizationsAndCMethodInliningInReleaseBuildCallStacks.aspx)。關於[尾部呼叫優化](http://blogs.msdn.com/davbr/pages/tail-call-jit-conditions.aspx)的鏈接文章提到了各種條件,這些條件會阻止優化以防止行爲差異,但是如果你的應用程序依賴調用堆棧條件在發現的情況下,你會得到不同的行爲 – Martheen

+0

https://thedailywtf.com/articles/nature-in-its-volatility –

回答

1

這與多線程時序有關:在發佈模式下,編譯器可以通過重新排列指令或用常量替換值來執行某些優化,以改變代碼的運行時行爲(包括在看似正確的代碼中引入無限循環)。關於易失性和非易失性存儲器讀取,這裏是related question,正如漢斯在評論中指出的,an article from The Daily WTF關於C#編譯器用常量值替換變量作爲優化。

+0

我認爲你的意思是「缺乏內存同步」。 Violatile對此不利。一般來說,Lock更好。 – keithyip

相關問題