I thought it is very curious when I discovered that the standard defines <code>std::unique_ptr</code> and <code>std::shared_ptr</code> in two totally different ways regarding a Deleter that the pointer may own. Here is the declaration from cppreference::unique_ptr and cppreference::shared_ptr: <pre class="prettyprint"><code>template< class T, class Deleter = std::default_delete<T> > class unique_ptr; template< class T > class shared_ptr; </code></pre> As you can see the unique_ptr "saves" the type of the the Deleter-object as a template argument. This can also be seen in the way the Deleter is retrieved from the pointer later on: <pre class="prettyprint"><code>// unique_ptr has a member function to retrieve the Deleter template< class T, class Deleter = std::default_delete<T> > Deleter& unique_ptr<T, Deleter>::get_deleter(); // For shared_ptr this is not a member function template<class Deleter, class T> Deleter* get_deleter(const std::shared_ptr<T>& p); </code></pre> Can someone explain the rational behind this difference? I clearly favor the concept for <code>unique_ptr</code> why is this not applied to <code>shared_ptr</code> aswell? Also, why would <code>get_deleter</code> be a non-member function in the latter case?

Here you can find the original proposal for smart pointers: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1450.html It answers your question quite precisely: <blockquote> Since the deleter is not part of the type, changing the allocation strategy does not break source or binary compatibility, and does not require a client recompilation. </blockquote> This is also useful because gives the clients of <code>std::shared_ptr</code> some more flexibility, for example <code>shared_ptr</code> instances with different deleters can be stored in the same container. Also, because the <code>shared_ptr</code> implementations needs a shared memory block anyhow (for storing the reference count) and because there alreay has to be some overhead compared to raw pointers, adding a type-erased deleter is not much of a big deal here. <code>unique_ptr</code> on the other hand are inteded to have no overhead at all and every instance has to embed its deleter, so making it a part of the type is the natural thing to do.

Deleter type in unique_ptr vs. shared

I thought it is very curious when I discovered that the standard defines std::unique_ptr and std::shared_ptr in two totally different ways regarding a Deleter that the pointer may own. Here is the declaration from cppreference::unique_ptr and cppreference::shared_ptr:

template<     class T,     class Deleter = std::default_delete<T> > class unique_ptr;  template< class T > class shared_ptr;

As you can see the unique_ptr "saves" the type of the the Deleter-object as a template argument. This can also be seen in the way the Deleter is retrieved from the pointer later on:

// unique_ptr has a member function to retrieve the Deleter template<     class T,     class Deleter = std::default_delete<T> > Deleter& unique_ptr<T, Deleter>::get_deleter();  // For shared_ptr this is not a member function template<class Deleter, class T> Deleter* get_deleter(const std::shared_ptr<T>& p);

Can someone explain the rational behind this difference? I clearly favor the concept for unique_ptr why is this not applied to shared_ptr aswell? Also, why would get_deleter be a non-member function in the latter case?

Why would you choose shared_ptr instead of unique_ptr?

In short: Use unique_ptr when you want a single pointer to an object that will be reclaimed when that single pointer is destroyed. Use shared_ptr when you want multiple pointers to the same resource.

Does unique_ptr delete itself?

unique_ptr objects automatically delete the object they manage (using a deleter) as soon as they themselves are destroyed, or as soon as their value changes either by an assignment operation or by an explicit call to unique_ptr::reset.

What is the difference between Auto_ptr and unique_ptr?

unique_ptr is a new facility with a similar functionality, but with improved security. auto_ptr is a smart pointer that manages an object obtained via new expression and deletes that object when auto_ptr itself is destroyed.

Can I convert shared_ptr to unique_ptr?

Afterword. The flawless conversion of an std::unique_ptr to a compatible std::shared_ptr makes it possible to write efficient and safe factory functions. However, note that an std::shared_ptr cannot be converted to an std::unique_ptr.

Here you can find the original proposal for smart pointers: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1450.html

It answers your question quite precisely:

Since the deleter is not part of the type, changing the allocation strategy does not break source or binary compatibility, and does not require a client recompilation.

This is also useful because gives the clients of std::shared_ptr some more flexibility, for example shared_ptr instances with different deleters can be stored in the same container.

Also, because the shared_ptr implementations needs a shared memory block anyhow (for storing the reference count) and because there alreay has to be some overhead compared to raw pointers, adding a type-erased deleter is not much of a big deal here.

unique_ptr on the other hand are inteded to have no overhead at all and every instance has to embed its deleter, so making it a part of the type is the natural thing to do.

Deleter type in unique_ptr vs. shared_ptr [duplicate]

Tags:

c++

c++11

shared-ptr

unique-ptr

WorldSEnder

People also ask

1 Answers

Horstling

Recent Activity

Donate For Us