HandBooks Professional Java-C-Scrip-SQL part 39 ppsx

never throws. T* operator->() const; The operator returns the stored pointer. This, together with operator* is what makes the smart pointer look like an ordinary pointer. This operator never throws. T* get() const; The get function is the preferred way of retrieving the stored pointer when it might be null (in which case operator* and operator-> leads to undefined behavior). Note that it is also possible to test whether a shared_ptr contains a valid pointer by using the implicit Boolean conversion. This function never throws. bool unique() const; This function returns true if the shared_ptr is the sole owner of the stored pointer; otherwise, it returns false. unique never throws. long use_count() const; The use_count function returns the reference count for the pointer. It is especially useful for debugging purposes, because it can be used to get snapshots of the reference count at critical points of program execution. Use it sparingly. For some possible implementations of the shared_ptr interface, calculating the reference count may be expensive or even impossible. The function never throws. operator unspecified-bool-type() const; This implicit conversion to a type, unspecified-bool-type, makes it possible to test a smart pointer in Boolean contexts. The value is TRue if the shared_ptr is currently storing a valid pointer; otherwise, it is false. Note that the type that this conversion function returns is not specified. Using bool as the return type allows for some nonsensical operations, so typically, an implementation uses the safe bool idiom, [8] which is a nifty way of ensuring that only applicable Boolean tests can be used. The function never throws. [8] Invented by Peter Dimov. void swap(shared_ptr<T>& b); It is sometimes convenient to swap the contents of two shared_ptrs. The swap function exchanges the stored pointers (and their reference counts). This function never throws. Free Functions template <typename T,typename U> shared_ptr<T> static_pointer_cast(const shared_ptr<U>& r); To perform a static_cast on a pointer stored in a shared_ptr, we could retrieve the pointer and then cast it, but we couldn't store it in another shared_ptr; the new shared_ptr would think it was the first to manage the resource the pointer refers to. This is remedied by static_pointer_cast. Using this function ensures that the reference count for the pointee remains correct. static_pointer_cast never throws exceptions. Usage The primary problem solved by shared_ptr is knowing the correct time to delete a resource that is shared by more than one client. Here's a straightforward example, where two classes, A and B, are sharing an instance of int. To start using boost::shared_ptr, you need to include "boost/shared_ptr.hpp". #include "boost/shared_ptr.hpp" #include <cassert> class A { boost::shared_ptr<int> no_; public: A(boost::shared_ptr<int> no) : no_(no) {} void value(int i) { *no_=i; } }; class B { boost::shared_ptr<int> no_; public: B(boost::shared_ptr<int> no) : no_(no) {} int value() const { return *no_; } }; int main() { boost::shared_ptr<int> temp(new int(14)); A a(temp); B b(temp); a.value(28); assert(b.value()==28); } The classes A and B both store a shared_ptr<int>. When creating the instances of A and B, the shared_ptr temp is passed to their constructors. This means that all three shared_ptrsa, b, and tempare now referring to the same instance of an int. Had we used pointers to achieve such sharing of an int, A and B would have had a hard time figuring out when (and if!) it should be deleted. In the example, the reference count is 3 until the end of main, where all of the shared_ptrs go out of scope, decreasing the count until it reaches 0, allowing the last of the smart pointers to delete the shared int. The Pimpl Idiom Revisited The pimpl idiom was previously presented in conjunction with scoped_ptr, which works well as a means of storing the dynamically allocated instance of the pimpl, if copying is not permitted for the class using the idiom. That is not appropriate for all classes that would benefit from using the pimpl idiom (note that scoped_ptr can still be used, but copy construction and assignment need to be implemented by hand). For those classes that can handle shared implementation details, shared_ptr comes into play. When ownership of the pimpl is passed to a shared_ptr, the copying and assignment operators come for free. You'll recall that when using scoped_ptr to handle the lifetime of the pimpl class, copying of the outer class is not allowed, because scoped_ptrs are not copyable. This means that to support copying and assignment in such classes, a copy constructor and assignment operator must be defined manually. When using shared_ptr to handle the lifetime of the pimpl, a user-defined copy constructor may not even be needed. Note that the pimpl instance will be shared among the objects of the class, so if there is state that only applies to one instance of the class, a handcrafted copy constructor is still required. The solution is very similar to what we saw for scoped_ptr; just make it a shared_ptr, instead. shared_ptr and Standard Library Containers Storing objects directly in a container is sometimes troublesome. Storing objects by value means clients get copies of the container elements, which may be a performance problem for types where copying is an expensive operation. Furthermore, some containers, notably std::vector, copy elements when resizing as you add more elements, further adding to the performance problems. Finally, value semantics means no polymorphic behavior. If you need to store polymorphic objects in a container and you don't want to slice them, you must use pointers. If you use raw pointers, the complexity of maintaining the integrity of the elements skyrockets. That is, you must know whether clients of the container still refer to elements of the container when erasing them from the container, never mind coordinating multiple clients using the same element. Such problems are solved handily by shared_ptr. The following example shows how to store shared pointers in a Standard Library container. #include "boost/shared_ptr.hpp" #include <vector> #include <iostream> class A { public: virtual void sing()=0; protected: virtual ~A() {}; }; class B : public A { public: virtual void sing() { std::cout << "Do re mi fa so la"; } }; boost::shared_ptr<A> createA() { boost::shared_ptr<A> p(new B()); return p; } int main() { typedef std::vector<boost::shared_ptr<A> > container_type; typedef container_type::iterator iterator; container_type container; for (int i=0;i<10;++i) { container.push_back(createA()); } std::cout << "The choir is gathered: \n"; iterator end=container.end(); for (iterator it=container.begin();it!=end;++it) { (*it)->sing(); } } The two classes, A and B, contain a single virtual member function sing. B derives publicly from A, and as you can see, the factory function createA returns a dynamically allocated instance of B wrapped in a shared_ptr<A>. In main, a std::vector containing shared_ptr<A> is filled with 10 elements, and finally sing is invoked on each element. Had we been using raw pointers as elements, the objects would need to be manually deleted. In the example, this deletion is automatic, because the reference count of each shared_ptr in the container is 1 as long as the vector is kept alive; when the vector is destroyed, the reference counters all go down to zero, and the objects are deleted. It is interesting to note that even if the destructor of A had not been declared virtual, shared_ptr would have correctly invoked the destructor of B! A powerful technique is demonstrated in the example, and it involves the protected destructor in A. Because the function createA returns a shared_ptr<A>, it won't be possible to invoke delete on the pointer returned by shared_ptr:: get. This means that if the pointer in the shared_ptr is retrievedperhaps in order to pass it to a function expecting a raw pointerit won't be possible to accidentally delete it, which would wreak havoc. So, how is it that the shared_ptr is allowed to delete the object? It's because of the actual type of the pointer, which is B; B's destructor is not protected. This is a very useful way of adding extra safety to objects kept in shared_ptrs. shared_ptr and Other Resources Sometimes, you'll find yourself in need for using shared_ptr with a type that