C.31: All resources acquired by a class must be released by the class's destructor
All resource application must release destructor
Reason (reason)
Prevention of resource leaks, especially in error cases.
Avoid resource leaks, especially in the event of an error.
Note (Note)
For resources represented as classes with a complete set of default operations, this happens automatically.
If the resource performance for the realization of the full set of default action of classes, which will happen automatically.
Example (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.
by members of class X ifstream destructor implicitly close any open any document it.
Example, bad (negative sample)
class X2 { // badFILE* f; // may own a file// ... no default operations defined or =deleted ...};
X2 may leak a file handle.
The possibility of leaks file handles exist X2. (Specifically usually missing close the file, Translator's Note)
Note (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 (communication, translator's note) has not been shut down what happens? First, destructor, off or clear operation should never fail. If it does fail, this problem is not really a good solution. For (communication, translator's note) head module, the author does not know destructor destructor because of what is called, and there is no way by throwing an exception "refused to deal with." See the discussion (https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Sd-never-fail). More seriously, many "close / release" operation can not be retried. To solve this problem there have been many attempts, not without to find common solutions. If possible, turn off or remove the failed viewed as a fundamental error and terminates.
Note (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:
Class can hold a pointer to an object that it does not have ownership of, or reference. Clearly, such an object should not be destroyed class destructor. E.g:
Preprocessor pp { /* ... */ };Parser p { pp, /* ... */ };Type_checker tc { p, /* ... */ };
Here p refers to pp but does not own it.
Where p points to pp but does not possess pp.
Enforcement (Suggestions)
-
(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.
(Simple) If the class contains a proprietary (e.g., by declaring ownership gsl :: owner) pointer or reference member, then they should be referenced in the destructor.
Translator's Note: personally think it should be released in the destructor.
-
(Hard) Determine if pointer or reference member variables are owners when there is no explicit statement of ownership (e.g., look into the constructors).
-
(Difficult) to determine when the pointer or reference type member variables not explicitly stated whether the ownership of which is the owner (for example, through walk-constructors, etc.).
Original link:
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c31-all-resources-acquired-by-a-class-must-be-released-by-the-classs-destructor
I think this article helpful? Welcome thumbs up and share it with more people.
Read more updated articles, please pay attention to micro-channel public number of object-oriented thinking []
