1、除了内存资源以外，Other common resources include file descriptors, mutex locks, fonts and brushes in graphical user interfaces (GUIs), database connections, and network sockets. Regardless of the resource, it's important that it be released when you're finished with it.
<Item 13>Use objects to manage resources
2、In fact, that's half the idea behind this Item: by putting resources inside objects, we can rely on C++'s automatic destructor invocation to make sure that the resources are released.
3、Many resources are dynamically allocated on the heap, are used only within a single block or function, and should be released when control leaves that block or function. The standard library's auto_ptr is tailor-made for this kind of situation. auto_ptr is a pointer-like object (a smart pointer) whose destructor automatically calls delete on what it points to. Here's how to use auto_ptr to prevent f's potential resource leak:
class Investment { ... }; // root class of hierarchy of
// investment types
Investment* createInvestment(); // return ptr to dynamically allocated
// object in the Investment hierarchy;
// the caller must delete it
// (parameters omitted for simplicity)
void f()
{
Investment *pInv = createInvestment(); // call factory function
... // use pInv 此处可能提前return或者抛出异常导致不能delete pInv
delete pInv; // release object
}
void f()
{
std::auto_ptr<Investment> pInv(createInvestment()); // call factory
// function
... // use pInv as
// before
} // automatically
// delete pInv via
// auto_ptr's dtor
auto_ptr解决的是在堆栈(heap)上面分配一个对象后的安全释放问题，它的存在来源于C++对exception的支持。auto_ptr不能存在容器中，多个auto_ptr不能共享同一个对象的使用权，也不能通过它引用一个对象数组并进行释放。现在已经不推荐使用auto_ptr，建议使用unique_ptr.
4、上面代码示例展示了使用对象管理资源的两个重要方面
-
Resources are acquired and immediately turned over to resource-managing objects.
In fact, the idea of using objects to manage resources is often called Resource Acquisition Is Initialization (RAII), because it's so common to acquire a resource and initialize a resource-managing object in the same statement. Sometimes acquired resources are assigned to resource-managing objects instead of initializing them, but either way, every resource is immediately turned over to a resource-managing object at the time the resource is acquired.
-
Resource-managing objects use their destructors to ensure that resources are released.
Things can get tricky when the act of releasing resources can lead to exceptions being thrown, but that's a matter addressed by Item 8, so we'll not worry about it here.
5、Because an auto_ptr automatically deletes what it points to when the auto_ptr is destroyed, it's important that there never be more than one auto_ptr pointing to an object. If there were, the object would be deleted more than once, and that would put your program on the fast track to undefined behavior. To prevent such problems, auto_ptrs have an unusual characteristic: copying them (via copy constructor or copy assignment operator) sets them to null, and the copying pointer assumes sole ownership of the resource! STL containers require that their contents exhibit "normal" copying behavior, so containers of auto_ptr aren't allowed.
std::auto_ptr<Investment> // pInv1 points to the
pInv1(createInvestment()); // object returned from
// createInvestment std::auto_ptr<Investment> pInv2(pInv1); // pInv2 now points to the
// object; pInv1 is now null pInv1 = pInv2; // now pInv1 points to the
// object, and pInv2 is null
6、An alternative to auto_ptr is a reference-counting smart pointer (RCSP). An RCSP is a smart pointer that keeps track of how many objects point to a particular resource and automatically deletes the resource when nobody is pointing to it any longer. As such, RCSPs offer behavior that is similar to that of garbage collection. Unlike garbage collection, however, RCSPs can't break cycles of references (e.g., two otherwise unused objects that point to one another).
TR1's tr1::shared_ptr (see Item 54) is an RCSP, so you could write f this way:
void f()
{
...
std::tr1::shared_ptr<Investment>
pInv(createInvestment()); // call factory function ... // use pInv as before
} // automatically delete
// pInv via shared_ptr's dtor
tr1::shared_ptr 在用法上与auto_ptr 差不多，但是赋值时表现与auto_ptr 不同。
void f()
{
...
std::tr1::shared_ptr<Investment> // pInv1 points to the
pInv1(createInvestment()); // object returned from
// createInvestment std::tr1::shared_ptr<Investment> // both pInv1 and pInv2 now
pInv2(pInv1); // point to the object pInv1 = pInv2; // ditto — nothing has
// changed
...
} // pInv1 and pInv2 are
// destroyed, and the
// object they point to is
// automatically deleted
Because copying tr1::shared_ptrs works "as expected," they can be used in STL containers and other contexts where auto_ptr's unorthodox copying behavior is inappropriate.
7、Both auto_ptr and tr1::shared_ptr use delete in their destructors, not delete []. (Item 16 describes the difference.) That means that using auto_ptr or TR1::shared_ptr with dynamically allocated arrays is a bad idea, though, regrettably, one that will compile:
std::auto_ptr<std::string> // bad idea! the wrong
aps(new std::string[]); // delete form will be used std::tr1::shared_ptr<int> spi(new int[]); // same problem
在C++标准库中没有针对数组的智能指针，TR1中也没有，可以用vector或者string代替数组。 If you still think it would be nice to have auto_ptr- and TR1::shared_ptr-like classes for arrays, look to Boost (see Item 55). There you'll be pleased to find the boost::scoped_array and boost::shared_array classes that offer the behavior you're looking for.
8、Things to Remember
To prevent resource leaks, use RAII objects that acquire resources in their constructors and release them in their destructors.
Two commonly useful RAII classes are TR1::shared_ptr and auto_ptr. tr1::shared_ptr is usually the better choice, because its behavior when copied is intuitive. Copying an auto_ptr sets it to null.
<Item 14>Think carefully about copying behavior in resource-managing classes.
9、what should happen when an RAII object is copied? Most of the time, you'll want to choose one of the following possibilities:
class Lock {
public:
explicit Lock(Mutex *pm)
: mutexPtr(pm)
{ lock(mutexPtr); } // acquire resource
~Lock() { unlock(mutexPtr); } // release resource
private:
Mutex *mutexPtr;
};
-
Prohibit copying
In many cases, it makes no sense to allow RAII objects to be copied. This is likely to be true for a class like Lock, because it rarely makes sense to have "copies" of synchronization primitives. 参考item6具体实现如下
class Lock: private Uncopyable { // prohibit copying — see
public: // Item 6
... // as before
};
-
Reference-count the underlying resource.
Sometimes it's desirable to hold on to a resource until the last object using it has been destroyed. When that's the case, copying an RAII object should increment the count of the number of objects referring to the resource. This is the meaning of "copy" used by tr1::shared_ptr.Fortunately, tr1::shared_ptr allows specification of a "deleter" — a function or function object to be called when the reference count goes to zero. (This functionality does not exist for auto_ptr, which always deletes its pointer.) The deleter is an optional second parameter to the tr1::shared_ptr constructor, so the code would look like this
class Lock {
public:
explicit Lock(Mutex *pm) // init shared_ptr with the Mutex
: mutexPtr(pm, unlock) // to point to and the unlock func
{ // as the deleter
lock(mutexPtr.get()); // see Item 15 for info on "get"
}
private:
std::tr1::shared_ptr<Mutex> mutexPtr; // use shared_ptr
}; // instead of raw pointer
- In this example, notice how the Lock class no longer declares a destructor. That's because there's no need to. Item 5 explains that a class's destructor (regardless of whether it is compiler-generated or user-defined) automatically invokes the destructors of the class's non-static data members. 最好加上注释说明不是忘记在析构函数中释放锁资源。
-
Copy the underlying resource.
That is, copying a resource-managing object performs a "deep copy."
Transfer ownership of the underlying resource
10、Things to Remember
Copying an RAII object entails copying the resource it manages, so the copying behavior of the resource determines the copying behavior of the RAII object.
Common RAII class copying behaviors are disallowing copying and performing reference counting, but other behaviors are possible.