我正在看C ++中的系統(tǒng)錯誤處理-Andrei Alexandrescu，他聲稱這Exceptions in C++非常慢。我想知道這是否仍然適用 C++98
3 回答
慕運維8079593
TA貢獻1876條經(jīng)驗 獲得超5個贊
當今用于例外（Itanium ABI，VC ++ 64位）的主要模型是零成本模型例外。
這樣做的想法是，編譯器將生成一個邊表，該邊表將可能引發(fā)異常的任何點（程序計數(shù)器）映射到處理程序列表，而不是通過設(shè)置防護程序并在所有地方明確檢查是否存在異常來浪費時間。引發(fā)異常時，將查詢此列表以選擇正確的處理程序（如果有），并取消堆棧堆棧。
與典型if (error)策略相比：
顧名思義，零成本模型在沒有異常發(fā)生時是免費的
if發(fā)生異常時，費用約為10倍/ 20倍
然而，成本并不是微不足道的：
邊桌通常很冷，因此從內(nèi)存中獲取它要花費很長時間
確定正確的處理程序涉及到RTTI：要提取的許多RTTI描述符，分散在內(nèi)存中以及要運行的復(fù)雜操作（基本上是dynamic_cast對每個處理程序的測試）
因此，大多數(shù)緩存未命中，因此與純CPU代碼相比并不容易。
注意：有關(guān)更多詳細信息，請閱讀TR18015報告的第5.4節(jié)異常處理（pdf）
因此，是的，異常路徑在異常路徑上速度較慢，但與其他方式相比，它們通常比顯式檢查（if策略）更快。
注意：安德烈·亞歷山德列斯庫（Andrei Alexandrescu）似乎質(zhì)疑這種“快速”。我個人已經(jīng)看到事情發(fā)生了雙向變化，有些程序在例外情況下運行得更快，而在分支程序中運行得更快，因此在某些情況下確實確實缺乏優(yōu)化性。
有關(guān)系嗎 ？
我會聲稱沒有。編寫程序時應(yīng)考慮可讀性，而不要考慮性能（至少，不作為首要標準）。當人們期望調(diào)用者無法或不希望當場處理失敗并將失敗傳遞到堆棧時，將使用異常。獎勵：在C ++ 11中，可以使用標準庫在線程之間封送異常。
不過，這很微妙，我聲稱map::find不應(yīng)拋出，但是如果嘗試取消引用失敗，因為它為null，那么我可以map::find返回一個checked_ptrwhich拋出異常：在后一種情況下，就像Alexandrescu引入的類一樣，調(diào)用者選擇在顯式檢查和依賴異常之間。在不給呼叫者更多責任的情況下授權(quán)呼叫者通常是良好設(shè)計的標志。
慕少森
TA貢獻2019條經(jīng)驗 獲得超9個贊
這取決于編譯器。
例如，GCC以處理異常時的性能很差而著稱，但是在過去幾年中，這種情況變得更好了。
但是請注意，處理異常（顧名思義）應(yīng)該是異常，而不是軟件設(shè)計中的規(guī)則。當您的應(yīng)用程序每秒拋出如此多的異常以至于影響性能并且仍然被認為是正常操作時，您應(yīng)該寧愿以不同的方式去做。
異常是通過消除所有笨拙的錯誤處理代碼來提高代碼可讀性的好方法，但是一旦它們成為常規(guī)程序流程的一部分，它們就會變得很難遵循。請記住，a throw幾乎是goto catch偽裝的。
- 3 回答
- 0 關(guān)注
- 653 瀏覽
添加回答
舉報
0/150
提交
取消