C++核心準(zhǔn)則C.31:類請(qǐng)求的所有資源必須在析構(gòu)函數(shù)釋放
C.31: All resources acquired by a class must be released by the class's destructor
類申請(qǐng)的所有資源必須在析構(gòu)函數(shù)釋放
Reason（原因）
Prevention of resource leaks, especially in error cases.
避免資源泄露，特別是在發(fā)生錯(cuò)誤的情況下。
Note（注意）
For resources represented as classes with a complete set of default operations, this happens automatically.
如果資源表現(xiàn)為實(shí)現(xiàn)了全套默認(rèn)操作的類，這些會(huì)自動(dòng)發(fā)生。
Example（示例）
class X {ifstream f; // may own a file// ... no default operations defined or =deleted ...};
X's ifstream implicitly closes any file it may have open upon destruction of its X.
X類的ifstream成員通過(guò)析構(gòu)函數(shù)隱式關(guān)閉任何它打開(kāi)的任何文件。
Example, bad（反面示例）
class X2 { // badFILE* f; // may own a file// ... no default operations defined or =deleted ...};
X2 may leak a file handle.
X2存在泄露文件句柄的可能性。（具體講通常是漏掉關(guān)閉文件，譯者注）
Note（注意）
What about a sockets that won't close? A destructor, close, or cleanup operation should never fail. If it does nevertheless, we have a problem that has no really good solution. For starters, the writer of a destructor does not know why the destructor is called and cannot "refuse to act" by throwing an exception. See discussion. To make the problem worse, many "close/release" operations are not retryable. Many have tried to solve this problem, but no general solution is known. If at all possible, consider failure to close/cleanup a fundamental design error and terminate.
sokcet（通信，譯者注）沒(méi)有被關(guān)閉會(huì)怎么樣？首先，析構(gòu)函數(shù)，關(guān)閉或清除操作永遠(yuǎn)不應(yīng)該失敗。如果它確實(shí)會(huì)失敗，這問(wèn)題還沒(méi)有真正好的解決方案。對(duì)于（通信，譯者注）起始模塊，析構(gòu)函數(shù)的作者并不知道析構(gòu)函數(shù)因?yàn)槭裁幢徽{(diào)用，而且沒(méi)有辦法通過(guò)拋出異常來(lái)“拒絕處理”。參見(jiàn)討論（https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Sd-never-fail）。更為嚴(yán)重的是，許多“關(guān)閉/釋放”操作都無(wú)法重試。為了解決這個(gè)問(wèn)題有過(guò)許多嘗試，不是沒(méi)有找到通用的解決方案。如果可能，可以將關(guān)閉或清除的失敗看作根本性錯(cuò)誤并終止。
Note（注意）
A class can hold pointers and references to objects that it does not own. Obviously, such objects should not be deleted by the class's destructor. For example:
類可以持有指向那些它并不擁有所有權(quán)的對(duì)象的指針或引用。顯然，這樣的對(duì)象不應(yīng)該被該類的析構(gòu)函數(shù)銷毀。例如：
Preprocessor pp { /* ... */ };Parser p { pp, /* ... */ };Type_checker tc { p, /* ... */ };
Here p refers to pp but does not own it.
這里p指向了pp但是并不擁有pp。
Enforcement（實(shí)施建議）
(Simple) If a class has pointer or reference member variables that are owners (e.g., deemed owners by using gsl::owner), then they should be referenced in its destructor.
(簡(jiǎn)單)如果類包含具有所有權(quán)（例如通過(guò)gsl::owner宣示所有權(quán)）的指針或引用成員，則它們應(yīng)該在析構(gòu)函數(shù)中被引用。
譯者注：個(gè)人覺(jué)得應(yīng)該是在析構(gòu)函數(shù)中釋放。
(Hard) Determine if pointer or reference member variables are owners when there is no explicit statement of ownership (e.g., look into the constructors).
(困難)在指針或引用類型的成員變量沒(méi)有明確陳述所有權(quán)時(shí)判斷它們是否是所有者（例如通過(guò)走查構(gòu)造函數(shù)等方式）。
原文鏈接：
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c31-all-resources-acquired-by-a-class-must-be-released-by-the-classs-destructor
覺(jué)得本文有幫助？請(qǐng)分享給更多人。
關(guān)注【面向?qū)ο笏伎肌枯p松學(xué)習(xí)每一天！
面向?qū)ο箝_(kāi)發(fā)，面向?qū)ο笏伎迹?/span>