HandBooks Professional Java-C-Scrip-SQL part 38 pdf

scoped_array Header: "boost/scoped_array.hpp" The need for dynamically allocated arrays is usually best handled by std:: vector, but there are two cases when it makes good sense to use arrays: for optimization, as there is some overhead in size and speed for vector; and for expression of intent, making it clear that bounds are fixed. [5] Dynamically allocated arrays are exposed to the same dangers as ordinary pointers, with the added (and all too common) mistake of invoking the delete operator instead of the delete[] operator. I've seen that mistake in places one could hardly imagine, such as in widely used, proprietary container classes! scoped_array does for arrays what scoped_ptr does for pointers to single objects: It deletes the memory. The difference is that scoped_array does it using the delete[] operator. [5] These are not clear-cut advantages. Indeed, it is usually best to use std::vector until performance measurements suggest the benefits of scoped_array are warranted. The reason that scoped_array is a separate class rather than being a specialization of scoped_ptr is because it is not possible to distinguish between pointers to single objects and pointers to arrays using metaprogramming techniques. Despite efforts to make that distinction, no one has found a reliable way to do that because arrays decay so easily into pointers that carry no type information indicating that they point to arrays. As a result, the onus is on you to use scoped_array rather than scoped_ptr, just as you must otherwise choose to use the delete[] operator rather than the delete operator. The benefits are that scoped_array handles deletion for you, and that scoped_array conveys that we are dealing with an array, whereas a raw pointer doesn't. scoped_array is very similar to scoped_ptr, with the differences that it provides operator[] to mimic a raw array. scoped_array is a superior alternative to ordinary, dynamically allocated arrays. It handles lifetime management of dynamically allocated arrays, similar to how scoped_ptr manages lifetime for pointers to objects. Remember though, in most cases, std::vector is preferable as it is more flexible and powerful. When you need to clearly state that the size of the array is constant, use scoped_array rather than std::vector. shared_ptr Header: "boost/shared_ptr.hpp" Almost all non-trivial programs need some form of reference-counted smart pointers. These smart pointers eliminate the need to write complicated logic to control the lifetime of objects shared among two or more other objects. When the reference count drops to zero, no more objects are interested in the shared object, and so it is deleted automatically. Reference-counted smart pointers can be categorized as intrusive or non-intrusive. The former expects the classes that it manages to provide certain functionality or data members with which to manage the reference count. That means designing classes with the foresight to work with an intrusive, reference-counted smart pointer class, or retrofitting. Non-intrusive, reference-counted smart pointers don't require anything of the types they manage. Reference-counted smart pointers assume ownership of the memory associated with their stored pointers. The problem with sharing objects without the help of smart pointers is that someone must, eventually, delete the shared memory. Who, and when? Without reference-counted smart pointers, one must impose lifetime management externally to the memory being managed, which typically means stronger dependencies among the collective owners. That, in turn, impedes reusability and adds complexity. The class to be managed may have properties that make it a good candidate for use with a reference-counted smart pointer. For example, the fact that it is expensive to copy, or that part of its representation needs to be shared between instances, make shared ownership desirable. There are also situations in which there is no explicit owner of a shared resource. Using reference-counted smart pointers makes possible sharing ownership among the objects that need access to the shared resource. Reference-counted smart pointers also make it possible to store pointers to objects in Standard Library containers without risk of leaks, especially in the face of exceptions or when removing elements from the containers. When you store pointers in containers, you can take advantage of polymorphism, improved efficiency (if copying is expensive), and the ability to store the same objects in multiple, associated containers for specialized lookups. After you've determined that the use of a reference-counted smart pointer is warranted, how do you choose whether to use an intrusive or non-intrusive design? Non-intrusive smart pointers are almost always the better choice on account of their general applicability, lack of impact on existing code, and flexibility. You can use non-intrusive, reference-counted smart pointers with classes that you cannot or don't wish to change. The usual way to adapt a class to work with an intrusive, reference-counted smart pointer is to derive from a reference-counted base class. That change may be more expensive than appears at first glance. At the very least, it adds dependencies and decreases reusability. [6] It also typically increases object size, which may limit usability in some contexts. [7] [6] Consider the need to use more than one reference-counted smart pointer class with the same type. If both are intrusive designs, the different base classes may not be compatible and will certainly be wasteful. If only one is an intrusive design, the overhead of the base class is for naught when using the non-intrusive smart pointer. [7] On the other hand, non-intrusive smart pointers require additional storage for the actual smart pointer. A shared_ptr can be constructed from a raw pointer, another shared_ptr, a std::auto_ptr, or a boost::weak_ptr. It is also possible to pass a second argument to the constructor of shared_ptr, known as a deleter. The deleter is later called upon to handle deletion of the shared resource. This is useful for resource management where the resource is not allocated with new and destroyed with delete (we shall see examples of creating custom deleters later). After the shared_ptr has been constructed, it is used just like an ordinary pointer, with the obvious exception that it must not be explicitly deleted. This is a partial synopsis for shared_ptr; the most important members and accompanying free functions are shown and subsequently briefly discussed. namespace boost { template<typename T> class shared_ptr { public: template <class Y> explicit shared_ptr(Y* p); template <class Y,class D> shared_ptr(Y* p,D d); ~shared_ptr(); shared_ptr(const shared_ptr & r); template <class Y> explicit shared_ptr(const weak_ptr<Y>& r); template <class Y> explicit shared_ptr(std::auto_ptr<Y>& r); shared_ptr& operator=(const shared_ptr& r); void reset(); T& operator*() const; T* operator->() const; T* get() const; bool unique() const; long use_count() const; operator unspecified-bool-type() const; void swap(shared_ptr<T>& b); }; template <class T,class U> shared_ptr<T> static_pointer_cast(const shared_ptr<U>& r); } Members template <class Y> explicit shared_ptr(Y* p); This constructor takes ownership of the supplied pointer p. The argument p must be a valid pointer to Y. The reference count is set to 1 after construction. The only exception that may be thrown from the constructor is std::bad_alloc (which can only happen in the unlikely event that the reference counter cannot be allocated from the free store). template <class Y,class D> shared_ptr(Y* p,D d); This constructor takes two arguments. The first is the resource that the shared_ptr should take ownership of, and the second is an object that is responsible for releasing that resource when the shared_ptr is destroyed. The stored resource is passed to the object as d(p). Thus, valid values of p depend upon d. If the reference counter cannot be allocated, shared_ptr tHRows an exception of type std::bad_alloc. shared_ptr(const shared_ptr& r); The stored resource in r is shared by the constructed shared_ptr, and the reference count is increased by one. This copy constructor never throws. template <class Y> explicit shared_ptr(const weak_ptr<Y>& r); Constructs a shared_ptr from a weak_ptr (covered later in this chapter). This enables thread-safe usage of weak_ptr, because the reference count of the shared resource pointed to by the weak_ptr argument will be incremented (weak_ptrs do not affect the reference count of shared resources). If the weak_ptr is empty (r.use_count()==0), shared_ptr tHRows an exception of type bad_weak_ptr. template <typename Y> shared_ptr(std::auto_ptr<Y>& r); The construction from an auto_ptr takes ownership of the pointer stored in r by storing a copy of the pointer and calling release on the auto_ptr. The reference count after construction is 1. r is, of course, emptied. Throws std::bad_alloc if the reference counter cannot be allocated. ~shared_ptr(); The shared_ptr destructor decreases the reference count by one. If the count is then zero, the stored pointer is deleted. Deleting the pointer is done through a call to operator delete or, if a custom deleter object was supplied to handle destruction, that object will be called with the stored pointer as its sole argument. The destructor never throws. shared_ptr& operator=(const shared_ptr& r); The copy assignment operator shares the resource in r and stops sharing the resource currently being shared. The copy assignment operator never throws. void reset(); The reset function is used to stop sharing ownership of the stored pointer. The reference count for the shared resource is decremented. T& operator*() const; This operator returns a reference to the object pointed to by the stored pointer. If the pointer is null, invoking operator* results in undefined behavior. This operator . a reference-counted smart pointer. For example, the fact that it is expensive to copy, or that part of its representation needs to be shared between instances, make shared ownership desirable ordinary pointer, with the obvious exception that it must not be explicitly deleted. This is a partial synopsis for shared_ptr; the most important members and accompanying free functions are