From ae60bcaffb4986363ea9384229f333ec20b9d386 Mon Sep 17 00:00:00 2001
From: Peter Dimov
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. +
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. Every occurence of the new keyword in the code should have the form:
shared_ptr<T> p(new Y);@@ -172,7 +172,7 @@ void bad()
Exception safety: If an exception is thrown, the constructor has no effect.
-[The poscondition of use_count() == 1 is too strong. Having the nothrow
+ [The postcondition of use_count() == 1 is too strong. Having the nothrow
guarantee is important, since reset() is specified in terms of
the default constructor, but the current specification requires that a count be
allocated. Therefore, this postcondition will be dropped in a future release.
@@ -221,15 +221,15 @@ void bad()
Another possible implementation is to use a global pointer-to-count map instead
of intrusive counting. shared_from_this would no longer be
O(1), which is a concern for some users, although I do not expect any
- performance problems, since the operation is rare. Maintaining a global
- map is difficult; it needs to be initialized before any shared_ptr
- instances are constructed, and the initialization needs to be thread safe.
- In addition, under the Windows dynamic library model, it is possible for
- several maps to exist. It is not yet clear which implementation should be used, or whether the
specification should allow both; nevertheless, the ability to make a shared_ptr
- from this is considered essential by experienced smart
- pointer users.]
template<typename Y, typename D> shared_ptr(Y * p, D d);
Requirements: p must be convertible to T *. D @@ -263,8 +263,7 @@ void bad() requires an overload set that breaks on many compilers due to 14.5.5.2 problems (and of course it will break on compilers that don't do partial ordering at all.)
-The requrement will be removed when the aforementioned issues are - resolved.]
+The requrement will be removed when the aforementioned issues are resolved.]
shared_ptr(shared_ptr const & r); // never throws template<typename Y> shared_ptr(shared_ptr<Y> const & r); // never throws@@ -336,7 +335,7 @@ q = p;both assignments may be no-ops.
[Some experts consider the note to be redundant, as it appears to essentially - mirror the "as if" rile. However, experience suggests that when C++ code is + mirror the "as if" rule. However, experience suggests that when C++ code is used to describe effects, it is often misinterpreted as required implementation. In addition, it is not entirely clear whether the "as if" rule actually applies here, so it's better to be explicit about the possible @@ -398,8 +397,8 @@ q = p;
conversions
operator unspecified-bool-type () const; // never throws-Returns: an unspecified value that, when used in boolean contexts, - is equivalent to
+get() != 0
.Returns: an unspecified value that, when used in boolean contexts, is + equivalent to
get() != 0
.Throws: nothing.
Notes: This conversion operator allows shared_ptr objects to be used in boolean contexts, like
if (p && p->valid()) {}
. @@ -432,9 +431,9 @@ q = p;template<typename T> bool operator<(shared_ptr<T> const & a, shared_ptr<T> const & b); // never throws-Returns: an unspecified value such that operator< is a - strict weak ordering as described in section 25.3
+[lib.alg.sorting]
- of the C++ standard.Returns: an unspecified value such that operator< is a strict + weak ordering as described in section 25.3
[lib.alg.sorting]
of + the C++ standard.Throws: nothing.
Notes: Allows shared_ptr objects to be used as keys in associative containers.
@@ -555,12 +554,12 @@ q = p; type.Thread Safety
shared_ptr objects offer the same level of thread safety as - built-in types. A shared_ptr instance can be "read" - (accessed using only const operations) simultaneously by multiple threads. - Different shared_ptr instances can be "written to" (accessed - using mutable operations such as operator= or reset) - simultaneosly by multiple threads (even when these instances are copies, and - share the same reference count underneath.)
+ built-in types. A shared_ptr instance can be "read" (accessed + using only const operations) simultaneously by multiple threads. Different shared_ptr + instances can be "written to" (accessed using mutable operations such as operator= + or reset) simultaneosly by multiple threads (even + when these instances are copies, and share the same reference count + underneath.)Any other simultaneous accesses result in undefined behavior.
Examples: