diff --git a/include/boost/shared_ptr.hpp b/include/boost/shared_ptr.hpp index 3f988a7..debb9a7 100644 --- a/include/boost/shared_ptr.hpp +++ b/include/boost/shared_ptr.hpp @@ -5,7 +5,7 @@ // shared_ptr.hpp // // (C) Copyright Greg Colvin and Beman Dawes 1998, 1999. -// Copyright (c) 2001, 2002 Peter Dimov +// Copyright (c) 2001, 2002, 2003 Peter Dimov // // Permission to copy, use, modify, sell and distribute this software // is granted provided this copyright notice appears in all copies. diff --git a/include/boost/weak_ptr.hpp b/include/boost/weak_ptr.hpp index 8c2a977..9d56858 100644 --- a/include/boost/weak_ptr.hpp +++ b/include/boost/weak_ptr.hpp @@ -4,7 +4,7 @@ // // weak_ptr.hpp // -// Copyright (c) 2001, 2002 Peter Dimov +// Copyright (c) 2001, 2002, 2003 Peter Dimov // // Permission to copy, use, modify, sell and distribute this software // is granted provided this copyright notice appears in all copies. @@ -37,7 +37,7 @@ public: typedef T element_type; - weak_ptr(): px(0), pn() + weak_ptr(): px(0), pn() // never throws in 1.30+ { } @@ -92,7 +92,7 @@ public: #endif - void reset() + void reset() // never throws in 1.30+ { this_type().swap(*this); } diff --git a/shared_ptr.htm b/shared_ptr.htm index 6c7b012..b2f9dcf 100644 --- a/shared_ptr.htm +++ b/shared_ptr.htm @@ -8,6 +8,7 @@
Introduction
+ Motivation
Best Practices
Synopsis
Members
@@ -46,6 +47,8 @@
to shared_ptr<T const>, to shared_ptr<U>
where U is an accessible base of T, and to
shared_ptr<void>.
[...]
A simple guideline that nearly eliminates the possibility of memory leaks is: always use a named smart pointer variable to hold the result of new. @@ -262,22 +265,11 @@ template<class Y> shared_ptr(shared_ptr<Y> const & r); // never
-Effects: If r is empty, constructs an empty shared_ptr; otherwise, constructs a shared_ptr that shares ownership with r - and stores a copy of the pointer stored in r.
-Throws: bad_weak_ptr when
+ and stores a copy of the pointer stored in r. +r.use_count() == 0
.Throws: bad_weak_ptr when
r.use_count() == 0
.Exception safety: If an exception is thrown, the constructor has no effect.
[This constructor is an optional part of the specification; it depends on the - existence of weak_ptr. It is true that weak_ptr - support imposes overhead on every shared_ptr user, regardless - of whether weak pointers are used.
-On the other hand, cyclic references are a serious problem with all reference - counted designs. Not providing a solution within the library is unacceptable; - if users are forced to reinvent the weak pointer wheel, there is substantial - probability that they will get it wrong, as designing a safe weak_ptr - interface is non-trivial.
-My opinion is that the added functionality is worth the cost. weak_ptr - is provided in the reference implementation as a proof of concept.]
template<class Y> shared_ptr(std::auto_ptr<Y> & r);
Effects: Constructs a shared_ptr, as if by storing a copy of r.release().
@@ -580,45 +572,60 @@ p3.reset(new int(2)); // undefined, multiple writesQ. There are several variations of shared pointers, with different tradeoffs; why does the smart pointer library supply only a single implementation? It would be useful to be able to experiment with each type so - as to find the most suitable for the job at hand?
+
+ as to find the most suitable for the job at hand?A. An important goal of shared_ptr is to provide a standard shared-ownership pointer. Having a single pointer type is important for stable library interfaces, since different shared pointers typically cannot interoperate, i.e. a reference counted pointer (used by library A) cannot share - ownership with a linked pointer (used by library B.)
+ ownership with a linked pointer (used by library B.)
+Q. Why doesn't shared_ptr have template parameters supplying - traits or policies to allow extensive user customization?
+
+ traits or policies to allow extensive user customization?A. Parameterization discourages users. The shared_ptr template is carefully crafted to meet common needs without extensive parameterization. Some day a highly configurable smart pointer may be invented that is also very easy to use and very hard to misuse. Until then, shared_ptr is the smart pointer of choice for a wide range of applications. (Those interested in policy based smart pointers should read - Modern C++ Design by Andrei Alexandrescu.)
+ Modern C++ Design by Andrei Alexandrescu.)
+Q. I am not convinced. Default parameters can be used where appropriate - to hide the complexity. Again, why not policies?
+
+ to hide the complexity. Again, why not policies?A. Template parameters affect the type. See the answer to the first - question above.
-Q. Why doesn't shared_ptr use a linked list implementation?
+
+ question above.
+Q. Why doesn't shared_ptr use a linked list implementation?
+A. A linked list implementation does not offer enough advantages to offset the added cost of an extra pointer. See timings page. In addition, it is expensive to make a linked list implementation thread - safe.
-Q. Why doesn't shared_ptr (or any of the other Boost smart - pointers) supply an automatic conversion to T*?
-
- A. Automatic conversion is believed to be too error prone.Q. Why does shared_ptr supply use_count()?
+
+ safe.
+Q. Why doesn't shared_ptr (or any of the other Boost smart + pointers) supply an automatic conversion to T*?
++ A. Automatic conversion is believed to be too error prone.
+
+Q. Why does shared_ptr supply use_count()?
+A. As an aid to writing test cases and debugging displays. One of the progenitors had use_count(), and it was useful in tracking down bugs in a - complex project that turned out to have cyclic-dependencies.
-Q. Why doesn't shared_ptr specify complexity requirements?
+
+ complex project that turned out to have cyclic-dependencies.
+Q. Why doesn't shared_ptr specify complexity requirements?
+A. Because complexity requirements limit implementors and complicate the specification without apparent benefit to shared_ptr users. For example, error-checking implementations might become non-conforming if they had to meet - stringent complexity requirements.
-Q. Why doesn't shared_ptr provide a release() function?
+
+ stringent complexity requirements.
+Q. Why doesn't shared_ptr provide a release() function?
+A. shared_ptr cannot give away ownership unless it's unique() - because the other copy will still destroy the object.
+ because the other copy will still destroy the object.Consider:
-shared_ptr<int> a(new int); shared_ptr<int> b(a); // a.use_count() == b.use_count() == 2 @@ -627,17 +634,32 @@ int * p = a.release(); // Who owns p now? b will still call delete on it in its destructor.Q. Why doesn't shared_ptr provide (your pet feature here)?
+Furthermore, the pointer returned by
+release()
would be difficult + to deallocate reliably, as the source shared_ptr could have been created + with a custom deleter.
+Q. Why is
+operator->()
const, but its return value is a + non-const pointer to the element type?+ A. Shallow copy pointers, including raw pointers, typically don't + propagate constness. It makes little sense for them to do so, as you can always + obtain a non-const pointer from a const one and then proceed to modify the + object through it.shared_ptr is "as close to raw pointers as possible + but no closer".
+
+Q. Why doesn't shared_ptr provide (your pet feature here)?
+A. Because (your pet feature here) would mandate a reference counted implementation or a linked list implementation, or some other specific - implementation. This is not the intent.
+ implementation. This is not the intent.
+
$Date$
Copyright 1999 Greg Colvin and Beman Dawes. Copyright 2002 Darin Adler. - Copyright 2002, 2003 Peter Dimov. Permission to copy, use, modify, sell - and distribute this document is granted provided this copyright notice appears - in all copies. This document is provided "as is" without express or implied + Copyright 2002, 2003 Peter Dimov. Permission to copy, use, modify, sell and + distribute this document is granted provided this copyright notice appears in + all copies. This document is provided "as is" without express or implied warranty, and with no claim as to its suitability for any purpose.