資源、數據、狀態

http://blog.csdn.net/u013540854/article/details/30721675

結論1：異常安全函數即使發生異常也不會泄漏資源或允許任何數據結構敗壞。這樣的函數區分為三種可能的保證：基本型、強烈型、不拋異常型。

"異常安全“有兩個條件：不泄漏任何資源和不允許數據敗壞。解決資源泄漏問題可用對象管理資源。對於數據敗壞，異常安全函數提供三個保證：

基本承諾：如果異常被拋出，程序內的任何事物仍然保持在有效狀態下。沒有任何對象或數據結構會因此而敗壞，所有對象都處於一種內部前後一致的狀態。然而程序的現實狀態（exact state）恐怕不可預料，程序有可能處於任何狀態，只要那是個合法狀態。

強烈保證：如果異常被拋出，程序狀態不改變。調用這樣的函數需有這樣的認知：如果函數成功，就是完全成功，如果函數失敗，程序會回復到”調用函數之前“的狀態。

不拋擲保證：承諾絕不拋出異常，因為它們總是能夠完成它們原先承諾的功能。作用於內置類型身上的所有操作都提供不拋擲保證。

結論2：”強烈保證“往往能夠以copy-and-swap實現出來，但“強烈保證”並非對所有函數都可實現或具備現實意義。

copy-and-swap原則很簡單：為打算修改的對象（原件）做一份副本，然後在那副本身上做一切必要修改。若有任何修改動作拋出異常，原對象仍保持未改變狀態。待所有改變都成功後，再將修改過的那個副本和原對象在一個不拋出異常的操作中置換。

實際上通常將所有“隸屬對象的數據”從原對象放進另一個對象內，然後賦予原對象一個指針，指向那個所謂的實現對象（即副本）。這種手法被稱為pimpl idiom。

如果函數只操作局部狀態，便相對容易提供強烈保證。但當函數對“非局部數據”有連帶影響時，提供強烈保證就困難得多。另一個在提供強烈保證時需要考慮的主題是效率。當“強烈保證”不切實際時，就必須提供“基本保證"。

結論3：函數提供的“異常安全保證”通常最高只等於其所調用之各個函數的“異常安全保證”中的最弱者。

條款29：為“異常安全”而努力是值得的