make_shared
name.make_shared
proposed wording to use variadic templates
and changed the Throws clause to reflect the semantics. Remarks added.
While shared_ptr
has already proven its utility time and again, we
have observed frequent requests for enhancements in several legitimate and key areas:
new
expression;shared_ptr
in "mostly
unique" ownership situations such as containers;shared_ptr
that is atomic, that is, safe to be
manipulated from multiple threads without synchronization; shared_ptr
structures; shared_ptr
that is confined to a single thread and uses
unsynchronized reference count updates. This document proposes additions to the C++0x standard to address the first six. Some of the proposed additions are essentially a subset of those presented in N1851 by Kliatchko and Rocha. We refer the interested reader to that paper for a more extensive rationale.
This proposal makes use of variadic templates and rvalue references. These C++0x features markedly improve the usability and effectiveness of several of the proposed additions.
The default behavior of shared_ptr
is to allocate its control block
using new
. This precludes its use in contexts where uncontrolled dynamic
allocations are not allowed. The proposed addition allows the user to supply an
allocator that shared_ptr
will use.
Boost users have repeatedly been asking for the ability to control the internal
control block allocation; one particularly amusing occurence was the desire to use
a shared_ptr
in the implementation of ::operator new
. Typical environments
where shared_ptr
cannot be used as-is include embedded systems and
computer and video games. Paul Pedriana (one of the primary authors of the Electronic
Arts STL implementation) writes in
N2271 that
EASTL's shared_ptr/weak_ptr allow the user to specify an allocator instead of implicitly using global new
and explains that
As described in the game software issues section, global new usage is often verboten in game software development, at least for console platforms. Thus any library facility which uses global operator new or any memory allocation that cannot be controlled by the user is unacceptable.
Asked to comment on the proposed addition, Paul kindly offered the following quote:
Certainly we (I can speak for all of Electronic Arts here) are in support of your proposal and you can document it as such. You could probably get other game developers and embedded developers to agree as well.
Vladimir Kliatchko and Ilougino Rocha offer additional arguments in favor of this functionality in N1851, complete with proposed wording. The suggested changes in this paper are a subset of those.
The key part of this proposal is that the allocator is not made part of
shared_ptr
's type. It is instead supplied as a parameter to
the shared_ptr
constructor in the same manner as the deleter is. This
is made possible by the already existing deleter support infrastructure. Coupled
with the fact that shared_ptr
only allocates memory once in its constructor,
and only deallocates it when the last instance in an ownership group is destroyed,
this allows us to avoid all common sources of allocator problems. The allocator
used for the creation of a particular shared_ptr
instance remains purely
an implementation detail for the user of that shared_ptr
.
Why use the std::allocator
interface if it's widely perceived as "broken"?
The simple answer is that it works for our (and our users') purposes and is already
in the Standard.
[Acknowledgments: this allocator interface has been independently suggested by Doug Gregor, Joe Gottman, Greg Colvin and others on the Boost list, as well as in N1851.]
This feature extends the interface of shared_ptr
in a backward-compatible
way, allowing its broader use, and is therefore strongly recommended to be added
to the C++0x standard. It does not impact existing uses, nor does it introduce binary
compatibility issues.
Add to shared_ptr
[util.smartptr.shared] the following constructor:
template<class Y, class D, class A> shared_ptr( Y * p, D d, A a );
and the following member function:
template<class Y, class D, class A> void reset( Y * p, D d, A a );
Change the section:
template<class Y, class D> shared_ptr( Y * p, D d );Requires:
p
shall be convertible toT*
.D
shall beCopyConstructible
. The copy constructor and destructor ofD
shall not throw exceptions. The expressiond(p)
shall be well-formed, shall have well defined behavior, and shall not throw exceptions.Effects: Constructs a
shared_ptr
object that owns the pointerp
and the deleterd
.
in [util.smartptr.shared.const] to:
template<class Y, class D> shared_ptr( Y * p, D d ); template<class Y, class D, class A> shared_ptr( Y * p, D d, A a );Requires:
p
shall be convertible toT*
.D
shall beCopyConstructible
. The copy constructor and destructor ofD
shall not throw. The expressiond(p)
shall be well-formed, shall have well defined behavior, and shall not throw.A
shall be an allocator [allocator.requirements]. The copy constructor and destructor ofA
shall not throw.Effects: Constructs a
shared_ptr
object that owns the pointerp
and the deleterd
. The second constructor shall use a copy ofa
to allocate memory for internal use.
Add the following to [util.smartptr.shared.mod]:
template<class Y, class D, class A> void reset( Y * p, D d, A a );Effects: Equivalent to
shared_ptr( p, d, a ).swap( *this )
.
This feature has been added to boost::shared_ptr
and will be part of
Boost 1.35. See:
http://boost.cvs.sourceforge.net/*checkout*/boost/boost/boost/shared_ptr.hpp
http://boost.cvs.sourceforge.net/*checkout*/boost/boost/libs/smart_ptr/test/shared_ptr_alloc2_test.cpp
for reference.
Advanced users often require the ability to create a shared_ptr
instance
p
that shares ownership with another (master) shared_ptr
q
but points to an object that is not a base of *q
.
*p
may be a member or an element of *q
, for example. This
section proposes an additional constructor that can be used for this purpose.
An interesting side effect of this increase of expressive power is that now the
*_pointer_cast
functions can be implemented in user code. The make_shared
factory function presented later in this document can also be implemented using
only the public interface of shared_ptr
via the aliasing constructor.
This feature extends the interface of shared_ptr
in a backward-compatible
way that increases its expressive power and is therefore strongly recommended to
be added to the C++0x standard. It introduces no source- and binary compatibility
issues.
Add to shared_ptr
[util.smartptr.shared] the following constructor:
template<class Y> shared_ptr( shared_ptr<Y> const & r, T * p );
Add the following to [util.smartptr.shared.const]:
template<class Y> shared_ptr( shared_ptr<Y> const & r, T * p );Effects: Constructs a
shared_ptr
instance that storesp
and shares ownership withr
.Postconditions:
get() == p && use_count() == r.use_count()
.Throws: nothing.
[Note: To avoid the possibility of a dangling pointer, the user of this constructor must ensure that
p
remains valid at least until the ownership group ofr
is destroyed. --end note.][Note: This constructor allows creation of an empty
shared_ptr
instance with a non-NULL stored pointer. --end note.]
This feature has been added to boost::shared_ptr
and will be part of
Boost 1.35. See:
http://boost.cvs.sourceforge.net/*checkout*/boost/boost/boost/shared_ptr.hpp
http://boost.cvs.sourceforge.net/*checkout*/boost/boost/libs/smart_ptr/test/shared_ptr_alias_test.cpp
for reference.
Consistent use of shared_ptr
can eliminate the need to use an explicit
delete
, but it currently provides no support in avoiding explicit
new
. There have been repeated requests from users for a factory function
that creates an object of a given type and returns a shared_ptr
to
it. Besides convenience and style, such a function is also exception safe and considerably
faster because it can use a single allocation for the object and its corresponding
control block, eliminating a significant portion of shared_ptr
's construction
overhead. This function eliminates one of the major efficiency complaints about
shared_ptr
.
This section proposes a family of overloaded function templates, make_shared<T>
and allocate_shared<T>
, to address this need. make_shared
uses the global operator new
to allocate memory, whereas allocate_shared
uses an user-supplied allocator, allowing finer control consistent with
section II of this document.
The rationale for choosing the name make_shared
is that the expression
make_shared<Widget>()
can be read aloud and conveys the intended
meaning. A free function also enables a non-intrusive implementation that can be
delivered without modifications to an existing shared_ptr
implementation.
This feature does not affect the interface of shared_ptr
. It is possible
to implement in a non-intrusive way using only the public interface, as long
as aliasing support is present. Access to implementation details can
eliminate between 5 and 8 bytes of storage overhead on a typical 32 bit platform.
The addition is a strong candidate for the C++0x standard, but can be relegated to a technical report.
namespace std { template<class T, class... Args> shared_ptr<T> make_shared( Args && ... args ); template<class T, class... Args> shared_ptr<T> allocate_shared( A const & a, Args && ... args ); }
template<class T, class... Args> shared_ptr<T> make_shared( Args && ... args ); template<class T, class... Args> shared_ptr<T> allocate_shared( A const & a, Args && ... args );Requires: The expression
new( pv ) T( std::forward<Args>(args)... )
, wherepv
is avoid*
pointing to storage suitable to hold an object of typeT
, shall be well-formed.A
shall be an allocator [allocator.requirements]. The copy constructor and destructor ofA
shall not throw.Effects: Allocates memory suitable for an object of type
T
and constructs an object in it via the placement new expressionnew( pv ) T()
ornew( pv ) T( std::forward<Args>(args)... )
.allocate_shared
uses a copy ofa
to allocate memory. If an exception is thrown, has no effect.Returns: A
shared_ptr
instance that stores and owns the address of the newly constructed object of typeT
.Postconditions:
get() != 0 && use_count() == 1
.Throws:
bad_alloc
, or an exception thrown fromA::allocate
or the constructor ofT
.Remarks: Implementations are encouraged, but not required, to perform no more than one memory allocation. [Note: This provides efficiency equivalent to an intrusive smart pointer. --end note]
[Note: These functions will typically allocate more memory than
sizeof(T)
to allow for internal bookkeeping structures such as the reference counts. --end note]
A proof of concept non-intrusive implementation is available at:
http://www.pdimov.com/cpp/make_shared.cpp
This implementation uses variadic templates and rvalue references. When these features are not available, it falls back on a family of overloaded function templates taking arguments by const reference.
Users often express concerns over the cost of copying a shared_ptr
in situations where the source of the copy is no longer needed. To address this
use case,
N1851 proposes a separate smart pointer, managed_ptr
, that
is convertible from and to shared_ptr
and enforces unique ownership.
The current proposal does not take this approach. Instead, we propose that move
constructors and move assignment operators be added to shared_ptr
.
This allows a shared_ptr
to be as efficient as an auto_ptr
or the proposed unique_ptr
when the source of the copy or assignment
is a temporary or no longer needed. Move-aware standard containers will automatically
take advantage of this optimization. As an example of the consequences, reallocating
a vector< shared_ptr<T> >
will no longer entail any reference
count updates.
This feature affects the interface of shared_ptr
in a way that reduces
its copy overhead and is in line with the rvalue recommendations for the standard
library presented in
N1859-N1862.
We believe that it is a strong candidate for addition to the C++0x standard.
Add to shared_ptr
[util.smartptr.shared] the following:
shared_ptr( shared_ptr && r ); template<class Y> shared_ptr( shared_ptr<Y> && r ); shared_ptr& operator=( shared_ptr && r ); template<class Y> shared_ptr& operator=( shared_ptr<Y> && r );
Add the following to [util.smartptr.shared.const]:
shared_ptr( shared_ptr && r ); template<class Y> shared_ptr( shared_ptr<Y> && r );Requires: For the second constructor
Y*
shall be convertible toT*
.Effects: Move-constructs a
shared_ptr
instance fromr
.Postconditions:
*this
contains the old value ofr
.r
is empty.Throws: nothing.
Add the following to [util.smartptr.shared.assign]:
shared_ptr& operator=( shared_ptr && r ); template<class Y> shared_ptr& operator=( shared_ptr<Y> && r );Effects: Equivalent to
shared_ptr( move( r ) ).swap( *this )
.Returns:
*this
.
This feature has been added to boost::shared_ptr
and will be part of
Boost 1.35.
Thanks to Joe Gottman for his comments on the move support.
Thanks to Jens Maurer for his comments on the make_shared
wording.
--end