In a piece of code I reviewed lately, which compiled fine with `g++-4.6`, I encountered a strange try to create a `std::shared_ptr` from `std::unique_ptr`:

    std::unique_ptr&lt;Foo&gt; foo...
    std::make_shared&lt;Foo&gt;(std::move(foo));

This seems rather odd to me. This should be `std::shared_ptr&lt;Foo&gt;(std::move(foo));` afaik, though I&#39;m not perfectly familiar with moves (and I know `std::move` is only a cast, nothing get&#39;s moved).

Checking with different compilers on this SSC(NUC*)E

    
    #include &lt;memory&gt;

    int main()
    {
       std::unique_ptr&lt;int&gt; foo(new int);
       std::make_shared&lt;int&gt;(std::move(foo));
    }

Results of compilation:

- g++-4.4.7     gives compilation error
- g++-4.6.4     compiles without any error
- g++-4.7.3     gives **internal compiler error**
- g++-4.8.1     gives compilation error
- clang++-3.2.1 compiles without any error

So the question is: which compiler is right in terms of the standard? Does the standard require this to be an invalid statement, a valid statement or is this simply undefined?


**Addition**

We&#39;ve agreed on that some of these compilers, such as clang++ and g++-4.6.4, permit the conversion while they shouldn&#39;t. However with g++-4.7.3 (which produces an internal compiler error on `std::make_shared&lt;Foo&gt;(std::move(foo));`), correctly rejects `int bar(std::move(foo));` 

Because of this huge difference in behavior, I&#39;m leaving the question as it is, although part of it would be answerable with the reduction to `int bar(std::move(foo));`. 

----------
*) NUC: Not universally compilable

creating a shared_ptr from unique_ptr

As it was the case in Boost, C++11 provides some functions for casting `shared_ptr`:

    std::static_pointer_cast
    std::dynamic_pointer_cast
    std::const_pointer_cast

I am wondering, however, why there are no equivalents functions for `unique_ptr`.

Consider the following simple example:

    class A { virtual ~A(); ... }
    class B : public A { ... }
        
    unique_ptr&lt;A&gt; pA(new B(...));

    unique_ptr&lt;A&gt; qA = std::move(pA); // This is legal since there is no casting
    unique_ptr&lt;B&gt; pB = std::move(pA); // This is not legal

    // I would like to do something like:
    // (Of course, it is not valid, but that would be the idea)
    unique_ptr&lt;B&gt; pB = std::move(std::dynamic_pointer_cast&lt;B&gt;(pA));

Is there any reason why this usage pattern is discouraged, and thus, equivalent functions to the ones present in `shared_ptr` are not provided for `unique_ptr`?

Dynamic casting for unique_ptr

I, and I think many others, have had great success using smart pointers to wrap up unsafe memory operations in C++, using things like RAII, et cetera. However, wrapping memory management is easier to implement when you have destructors, classes, operator overloading, et cetera.

For someone writing in raw C99, where could you point (no pun intended) to help with safe memory management?

Thanks.

Smart pointers/safe memory management for C?

I have a factory that returns a smart pointer. Regardless of what smart pointer I use, I can&#39;t get Google Mock to mock the factory method.

The mock object is the implementation of a pure abstract interface where all methods are virtual. I have a prototype:

    MOCK_METHOD0(Create, std::unique_ptr&lt;IMyObjectThing&gt;());

And I get:

    &quot;...gmock/gmock-spec-builders.h(1314): error C2248: &#39;std::unique_ptr&lt;_Ty&gt;::unique_ptr&#39; : cannot access private member declared in class &#39;std::unique_ptr&lt;_Ty&gt;&#39;&quot;

The type pointed to in the smart pointer is defined.

And I get it&#39;s trying to access one of the constructors declared private, but I don&#39;t understand why. When this was an std::auto_ptr&lt;T&gt;, the error said there was no copy constructor, which confuses me.

Anyway, is there a way to Mock a method that returns a smart pointer? Or is there a better way to build a factory? Is my only resolve to return a raw pointer (blech...)?

My environment is Visual Studio 2010 Ultimate and Windows 7. I&#39;m not using CLI.

Can Google Mock a method with a smart pointer return type?

`std::unique_ptr` has support for arrays, for instance:

    std::unique_ptr&lt;int[]&gt; p(new int[10]);

but is it needed? probably it is more convenient to use `std::vector` or `std::array`.

Do you find any use for that construct?

Is there any use for unique_ptr with array?

What is wrong with this program?

    #include &lt;memory&gt;
    #include &lt;vector&gt;
    
    int main()
    {
    	std::vector&lt;std::unique_ptr&lt;int&gt;&gt; vec;
    
    	int x(1);
    	std::unique_ptr&lt;int&gt; ptr2x(&amp;x);
    	vec.push_back(ptr2x); //This tiny command has a vicious error.
    
    	return 0;
    }

The error:

    In file included from c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/mingw32/bits/c++allocator.h:34:0,
                     from c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/bits/allocator.h:48,
                     from c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/memory:64,
                     from main.cpp:6:
    c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/bits/unique_ptr.h: In member function &#39;void __gnu_cxx::new_allocator&lt;_Tp&gt;::construct(_Tp*, const _Tp&amp;) [with _Tp = std::unique_ptr&lt;int&gt;, _Tp* = std::unique_ptr&lt;int&gt;*]&#39;:
    c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/bits/stl_vector.h:745:6:   instantiated from &#39;void std::vector&lt;_Tp, _Alloc&gt;::push_back(const value_type&amp;) [with _Tp = std::unique_ptr&lt;int&gt;, _Alloc = std::allocator&lt;std::unique_ptr&lt;int&gt; &gt;, value_type = std::unique_ptr&lt;int&gt;]&#39;
    main.cpp:16:21:   instantiated from here
    c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/bits/unique_ptr.h:207:7: error: deleted function &#39;std::unique_ptr&lt;_Tp, _Tp_Deleter&gt;::unique_ptr(const std::unique_ptr&lt;_Tp, _Tp_Deleter&gt;&amp;) [with _Tp = int, _Tp_Deleter = std::default_delete&lt;int&gt;, std::unique_ptr&lt;_Tp, _Tp_Deleter&gt; = std::unique_ptr&lt;int&gt;]&#39;
    c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/ext/new_allocator.h:105:9: error: used here
    In file included from c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/vector:69:0,
                     from main.cpp:7:
    c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/bits/unique_ptr.h: In member function &#39;void std::vector&lt;_Tp, _Alloc&gt;::_M_insert_aux(std::vector&lt;_Tp, _Alloc&gt;::iterator, _Args&amp;&amp; ...) [with _Args = {const std::unique_ptr&lt;int&gt;&amp;}, _Tp = std::unique_ptr&lt;int&gt;, _Alloc = std::allocator&lt;std::unique_ptr&lt;int&gt; &gt;, std::vector&lt;_Tp, _Alloc&gt;::iterator = __gnu_cxx::__normal_iterator&lt;std::unique_ptr&lt;int&gt;*, std::vector&lt;std::unique_ptr&lt;int&gt; &gt; &gt;, typename std::vector&lt;_Tp, _Alloc&gt;::_Base::_Tp_alloc_type::pointer = std::unique_ptr&lt;int&gt;*]&#39;:
    c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/bits/stl_vector.h:749:4:   instantiated from &#39;void std::vector&lt;_Tp, _Alloc&gt;::push_back(const value_type&amp;) [with _Tp = std::unique_ptr&lt;int&gt;, _Alloc = std::allocator&lt;std::unique_ptr&lt;int&gt; &gt;, value_type = std::unique_ptr&lt;int&gt;]&#39;
    main.cpp:16:21:   instantiated from here
    c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/bits/unique_ptr.h:207:7: error: deleted function &#39;std::unique_ptr&lt;_Tp, _Tp_Deleter&gt;::unique_ptr(const std::unique_ptr&lt;_Tp, _Tp_Deleter&gt;&amp;) [with _Tp = int, _Tp_Deleter = std::default_delete&lt;int&gt;, std::unique_ptr&lt;_Tp, _Tp_Deleter&gt; = std::unique_ptr&lt;int&gt;]&#39;
    c:\mingw\bin\../lib/gcc/mingw32/4.5.0/include/c++/bits/vector.tcc:314:4: error: used here

Why can I not push_back a unique_ptr into a vector?

Ok, so the last time I wrote C++ for a living, `std::auto_ptr` was all the std lib had available, and `boost::shared_ptr` was all the rage. I never really looked into the other smart pointer types boost provided. I understand that C++11 now provides some of the types boost came up with, but not all of them. 

So does someone have a simple algorithm to determine when to use which smart pointer? Preferably including advice regarding dumb pointers (raw pointers like `T*`) and the rest of the boost smart pointers. (Something like [this](https://stackoverflow.com/a/2139254/140719) would be great). 

Which kind of pointer do I use when?

What is the difference between the following set of pointers? When do you use each pointer in production code, if at all?

Examples would be appreciated!

 1. `scoped_ptr`

 2. `shared_ptr`

 3. `weak_ptr`

 4. `intrusive_ptr`

Do you use boost in production code?

smart pointers (boost) explained

With the new standard coming (and parts already available in some compilers), the new type `std::unique_ptr` is supposed to be a replacement for `std::auto_ptr`.  

Does their usage exactly overlap (so I can do a global find/replace on my code (not that I would do this, but if I did)) or should I be aware of some differences that are not apparent from reading the documentation?

Also if it is a direct replacement, why give it a new name rather than just improve the `std::auto_ptr`?

std::auto_ptr to std::unique_ptr

In practice with C++, what is [RAII][1], what are [smart pointers][2], how are these implemented in a program and what are the benefits of using RAII with smart pointers?

  [1]: http://en.wikipedia.org/wiki/Resource_acquisition_is_initialization
  [2]: http://en.wikipedia.org/wiki/Smart_pointers

RAII and smart pointers in C++

I have been looking through the [Clang source code][1] and I found this snippet: 

    void CompilerInstance::setInvocation(
        std::shared_ptr&lt;CompilerInvocation&gt; Value) {
      Invocation = std::move(Value);
    }
 
Why would I want to `std::move` an `std::shared_ptr`? 

Is there any point transferring ownership on a shared resource? 

Why wouldn&#39;t I just do this instead?

    void CompilerInstance::setInvocation(
        std::shared_ptr&lt;CompilerInvocation&gt; Value) {
      Invocation = Value;
    }

  [1]: https://clang.llvm.org/doxygen/CompilerInstance_8cpp_source.html#l00069

Why would I std::move an std::shared_ptr?

I&#39;m having trouble understanding the usage of smart pointers as class members in C++11. I have read a lot about smart pointers and I think I do understand how `unique_ptr` and `shared_ptr`/`weak_ptr` work in general. What I don&#39;t understand is the real usage. It seems like everybody recommends using `unique_ptr` as the way to go almost all the time. But how would I implement something like this:

    class Device {
    };
    
    class Settings {
        Device *device;
    public:
        Settings(Device *device) {
            this-&gt;device = device;
        }

        Device *getDevice() {
            return device;
        }
    };    

    int main() {
        Device *device = new Device();
        Settings settings(device);
        // ...
        Device *myDevice = settings.getDevice();
        // do something with myDevice...
    }

Let&#39;s say I would like to replace the pointers with smart pointers. A `unique_ptr` would not work because of `getDevice()`, right? So that&#39;s the time when I use `shared_ptr` and `weak_ptr`? No way of  using `unique_ptr`? Seems to me like for most cases `shared_ptr` makes more sense unless I&#39;m using a pointer in a really small scope?

    class Device {
    };
    
    class Settings {
        std::shared_ptr&lt;Device&gt; device;
    public:
        Settings(std::shared_ptr&lt;Device&gt; device) {
            this-&gt;device = device;
        }

        std::weak_ptr&lt;Device&gt; getDevice() {
            return device;
        }
    };
        
    int main() {
        std::shared_ptr&lt;Device&gt; device(new Device());
        Settings settings(device);
        // ...
        std::weak_ptr&lt;Device&gt; myDevice = settings.getDevice();
        // do something with myDevice...
    }

Is that the way to go? Thanks very much!

Using smart pointers for class members

Does `std::make_unique` have any efficiency benefits like `std::make_shared`?

Compared to manually constructing `std::unique_ptr`:

    std::make_unique&lt;int&gt;(1);         // vs
    std::unique_ptr&lt;int&gt;(new int(1));

Differences between std::make_unique and std::unique_ptr with new

I read in a few articles that raw pointers should almost never be used. Instead they should always be wrapped inside smart pointers, whether it&#39;s scoped or shared pointers.

However, I noticed that frameworks like Qt, wxWidgets and libraries like Boost never return nor expect smart pointers, as if they were not using them at all. Instead, they return or expect raw pointers. Is there any reason for that? Should I stay away from smart pointers when I write a public API, and why?

Just wondering why smart pointers are recommended when many major projects seem to avoid them.

Why do C++ libraries and frameworks never use smart pointers?

How much is the overhead of smart pointers compared to normal pointers in C++11? In other words, is my code going to be slower if I use smart pointers, and if so, how much slower?

Specifically, I&#39;m asking about the C++11 `std::shared_ptr` and `std::unique_ptr`.

*Obviously, the stuff pushed down the stack is going to be larger (at least I think so), because a smart pointer also needs to store its internal state (reference count, etc), the question really is, how much is this going to affect my performance, if at all?*

For example, I return a smart pointer from a function instead of a normal pointer:

    std::shared_ptr&lt;const Value&gt; getValue();
    // versus
    const Value *getValue();

Or, for example, when one of my functions accept a smart pointer as parameter instead of a normal pointer:

    void setValue(std::shared_ptr&lt;const Value&gt; val);
    // versus
    void setValue(const Value *val);

How much is the overhead of smart pointers compared to normal pointers in C++?

**Comparisons, Pros, Cons, and When to Use?**
----------------------------------------

This is a spin-off from a [garbage collection thread][1] where what I thought was a simple answer generated a lot of comments about some specific smart pointer implementations so it seemed worth starting a new post.

Ultimately the question is what are the various implementations of smart pointers in C++ out there and how do they compare?  Just simple pros and cons or exceptions and gotchas to something you might otherwise think should work.

I&#39;ve posted some implementations that I&#39;ve used or at least glossed over and considered using as an answer below and my understanding of their differences and similarities which may not be 100% accurate so feel free to fact check or correct me as needed.

The goal is to learn about some new objects and libraries or correct my usage and understanding of existing implementations already widely in use and end up with a decent reference for others.

  [1]: https://stackoverflow.com/questions/5009869/how-to-implement-garbage-collection-in-c/5010007#5010007

What C++ Smart Pointer Implementations are available?

What is the best method to go about passing a `shared_ptr` of a derived type to a function that takes a `shared_ptr` of a base type?

I generally pass `shared_ptr`s by reference to avoid a needless copy:

    int foo(const shared_ptr&lt;bar&gt;&amp; ptr);

but this doesn&#39;t work if I try to do something like

    int foo(const shared_ptr&lt;Base&gt;&amp; ptr);

    ...

    shared_ptr&lt;Derived&gt; bar = make_shared&lt;Derived&gt;();
    foo(bar);

I could use

    foo(dynamic_pointer_cast&lt;Base, Derived&gt;(bar));

but this seems sub-optimal for two reasons:

- A `dynamic_cast` seems a bit excessive for a simple derived-to-base cast.
- As I understand it, `dynamic_pointer_cast` creates a copy (albeit a temporary one) of the pointer to pass to the function.

Is there a better solution?

## Update for posterity:

It turned out to be an issue of a missing header file. Also, what I was trying to do here is considered an antipattern. Generally,

- Functions that don&#39;t impact an object&#39;s lifetime (i.e. the object remains valid for the duration of the function) should take a plain reference or pointer, e.g. `int foo(bar&amp; b)`.

- Functions that *consume* an object (i.e. are the final users of a given object) should take a `unique_ptr` by value, e.g. `int foo(unique_ptr&lt;bar&gt; b)`. Callers should `std::move` the value into the function.

- Functions that extend the lifetime of an object should take a `shared_ptr` by value, e.g. `int foo(shared_ptr&lt;bar&gt; b)`. The usual advice to avoid [circular references](https://en.wikipedia.org/wiki/Circular_reference) applies.

See Herb Sutter&#39;s [Back to Basics talk](https://www.youtube.com/watch?v=xnqTKD8uD64) for details.

Passing shared_ptr&lt;Derived&gt; as shared_ptr&lt;Base&gt;

C++ is all about memory ownership - aka **ownership semantics**.

It is the responsibility of the owner of a chunk of dynamically allocated memory to release that memory. So the question really becomes who owns the memory.

In C++ ownership is documented by the type a *raw* pointer is wrapped inside thus in a good (IMO) C++ program it is very rare (*rare*, not *never*) to see raw pointers passed around (as raw pointers have no inferred ownership thus we can not tell who owns the memory and thus without careful reading of the documentation you can&#39;t tell who is responsible for ownership).

Conversely, it is rare to see raw pointers stored in a class each raw pointer is stored within its own smart pointer wrapper. (**N.B.:** If you don&#39;t own an object you should not be storing it because you can not know when it will go out of scope and be destroyed.)

So the question:

- What type of ownership semantic have people come across?
- What standard classes are used to implement those semantics?
- In what situations do you find them useful?

Lets keep 1 type of semantic ownership per answer so they can be voted up and down individually.

## Summary:

Conceptually, smart pointers are simple and a naive implementation is easy. I have seen many attempted implementations, but invariably they are broken in some way that is not obvious to casual use and examples. Thus I recommend always using well tested smart pointers from a library rather than rolling your own. `std::auto_ptr` or one of the Boost smart pointers seem to cover all my needs.


### `std::auto_ptr&lt;T&gt;`:

  Single person owns the object. Transfer of ownership is allowed.

  Usage: This allows you to define interfaces that show the explicit transfer of ownership.

### `boost::scoped_ptr&lt;T&gt;`

  Single person owns the object. Transfer of ownership is NOT allowed.

  Usage: Used to show explicit ownership. Object will be destroyed by destructor or when explicitly reset.

### `boost::shared_ptr&lt;T&gt;` (`std::tr1::shared_ptr&lt;T&gt;`)

  Multiple ownership. This is a simple reference counted pointer. When the reference count reaches zero, the object is destroyed.

  Usage: When an object can have multiple owers with a lifetime that can not be determined at compile time.

### `boost::weak_ptr&lt;T&gt;`:

  Used with `shared_ptr&lt;T&gt;` in situations where a cycle of pointers may happen.

  Usage: Used to stop cycles from retaining objects when only the cycle is maintaining a shared refcount.


Smart pointers: who owns the object?

Let&#39;s say I have a class with a method that returns a `shared_ptr`.

What are the possible benefits and drawbacks of returning it by reference or by value?

Two possible clues:

 - **Early object destruction.** If I return the `shared_ptr` by (const) reference, the reference counter is not incremented, so I incur the risk of having the object deleted when it goes out of scope in another context (e.g. another thread). Is this correct? What if the environment is single-threaded, can this situation happen as well?
 - **Cost.** Pass-by-value is certainly not free. Is it worth avoiding it whenever possible?

Thanks everybody.

How to return smart pointers (shared_ptr), by reference or by value?

The question really fits in the title: I am curious to know what is the technical reason for this difference, but also the rationale ?

    std::shared_ptr&lt;void&gt; sharedToVoid; // legal;
    std::unique_ptr&lt;void&gt; uniqueToVoid; // ill-formed;

Why is shared_ptr&lt;void&gt; legal, while unique_ptr&lt;void&gt; is ill-formed?

I am so frustrated right now after several hours trying to find where shared_ptr is located. None of the examples I see show complete code to include the headers for `shared_ptr` (and working). Simply stating `std`, `tr1` and `&lt;memory&gt;` is not helping at all! I have downloaded boosts and all but still it doesn&#39;t show up!  Can someone help me by telling exactly where to find it?

Thanks for letting me vent my frustrations!

EDIT:
I see my title has been changed. Sorry about that.
So... it was also because it was not clear to me that shared_ptr is &quot;C++ version dependant&quot; --&gt; that&#39;s why I did not state my environment --&gt; therefore probably why it was so difficult for me to find it.

I am working on MSVS2008.

EDIT 2:
I don&#39;t know why,  but I was including [memory] and [boost/tr1/memory.hpp] and [boost/tr1/tr1/memory] while looking everywhere for the shared_ptr.. of course, i couldn&#39;t.

Thanks for all the responses.

Where is shared_ptr?

This is a bit of a two part question, all about the atomicity of `std::shared_ptr`:

**1.**
As far as I can tell, `std::shared_ptr` is the only smart pointer in `&lt;memory&gt;` that&#39;s atomic. I&#39;m wondering if there is a non-atomic version of `std::shared_ptr` available (I can&#39;t see anything in `&lt;memory&gt;`, so I&#39;m also open to suggestions outside of the standard, like those in Boost). I know `boost::shared_ptr` is also atomic (if `BOOST_SP_DISABLE_THREADS` isn&#39;t defined), but maybe there&#39;s another alternative? I&#39;m looking for something that has the same semantics as `std::shared_ptr`, but without the atomicity.

**2.** I understand why `std::shared_ptr` is atomic; it&#39;s kinda nice. However, it&#39;s not nice for every situation, and C++ has historically had the mantra of &quot;only pay for what you use.&quot; If I&#39;m not using multiple threads, or if I am using multiple threads but am not sharing pointer ownership across threads, an atomic smart pointer is overkill. My second question is *why wasn&#39;t a non-atomic version of `std::shared_ptr` provided in C++11*? (assuming there is a *why*) (if the answer is simply &quot;a non-atomic version was simply never considered&quot; or &quot;no one ever asked for a non-atomic version&quot; that&#39;s fine!).

With question #2, I&#39;m wondering if someone ever proposed a non-atomic version of `shared_ptr` (either to Boost or the standards committee) (not to replace the atomic version of `shared_ptr`, but to coexist with it) and it was shot down for a specific reason.

Is there a non-atomic equivalent of std::shared_ptr? And why isn&#39;t there one in &lt;memory&gt;?

What is a smart pointer and when should I use one?

I heard `auto_ptr` is being deprecated in C++11. What is the reason for this?

Also I would like to know the difference between `auto_ptr` and `shared_ptr`.

Why is auto_ptr being deprecated?

[Mr. Lidstr&#246;m and I had an argument](https://stackoverflow.com/questions/3899688/default-virtual-dtor/3899726#3899726) :)

Mr. Lidstr&#246;m&#39;s claim is that a construct `shared_ptr&lt;Base&gt; p(new Derived);` doesn&#39;t require Base to have a virtual destructor:

&gt; **Armen Tsirunyan**: &quot;Really? Will the *shared_ptr* clean up correctly? Could you please in this case demonstrate how that effect could be implemented?&quot;
&gt;
&gt; **Daniel Lidstr&#246;m**: &quot;The *shared_ptr* uses its own destructor to delete the Concrete instance. This is known as RAII within the C++ community. My advice is that you learn all you can about RAII. It will make your C++ coding so much easier when you use RAII in all situations.&quot;
&gt;
&gt; **Armen Tsirunyan**: &quot;I know about RAII, and I also know that eventually the *shared_ptr* destructor may delete the stored px when pn reaches 0. But if px had static type pointer to `Base` and dynamic type pointer to `Derived`, then unless `Base` has a virtual destructor, this will result in undefined behavior. Correct me if I am wrong.&quot;
&gt; 
&gt; **Daniel Lidstr&#246;m**: &quot;The *shared_ptr* knows the static type is Concrete. It knows this since I passed it in its constructor! Seems a bit like magic, but I can assure you it is by design and extremely nice.&quot;

So, judge us. How is it possible (if it is) to implement *shared_ptr* without requiring polymorphic classes to have virtual destructor?
Thanks in advance

shared_ptr magic :)

    class B;
    
    class A
    {
    public:
        A ()
            : m_b(new B())
        {
        }

        shared_ptr&lt;B&gt; GimmeB ()
        {
            return m_b;
        }
    
    private:
        shared_ptr&lt;B&gt; m_b;
    };

Let&#39;s say B is a class that semantically should not exist outside of the lifetime of A, i.e., it makes absolutely no sense for B to exist by itself. **Should &lt;code&gt;GimmeB&lt;/code&gt; return a &lt;code&gt;shared_ptr&amp;lt;B&amp;gt;&lt;/code&gt; or a &lt;code&gt;B*&lt;/code&gt;?**

**In general, is it good practice to completely avoid using raw pointers in C++ code, in lieu of smart pointers?**

I am of the opinion that &lt;code&gt;shared_ptr&lt;/code&gt; should only be used when there is explicit transfer or sharing of ownership, which I think is quite rare outside of cases where a function allocates some memory, populates it with some data, and returns it, and there is understanding between the caller and the callee that the former is now &quot;responsible&quot; for that data.

When to use shared_ptr and when to use raw pointers?

 1. Will auto_ptr be deprecated in incoming C++ standard?
 2. Should unique_ptr be used for ownership transfer instead of shared_ptr?
 3. If unique_ptr is not in the standard, then do I need to use shared_ptr instead?

 

Is auto_ptr deprecated?

Hi I asked a question today about [How to insert different types of objects in the same vector array ][1] and my code in that question was 

     gate* G[1000];
    G[0] = new ANDgate() ;
    G[1] = new ORgate;
    //gate is a class inherited by ANDgate and ORgate classes
    class gate
    {
     .....
     ......
     virtual void Run()
       {   //A virtual function
       }
    };
    class ANDgate :public gate 
      {.....
       .......
       void Run()
       {
        //AND version of Run
       }  

    };
     class ORgate :public gate 
      {.....
       .......
       void Run()
       {
        //OR version of Run
       }  

    };      
    //Running the simulator using overloading concept
     for(...;...;..)
     {
      G[i]-&gt;Run() ;  //will run perfectly the right Run for the right Gate type
     } 
and I wanted to use vectors so someone wrote that I should do that :

    std::vector&lt;gate*&gt; G;
    G.push_back(new ANDgate); 
    G.push_back(new ORgate);
    for(unsigned i=0;i&lt;G.size();++i)
    {
      G[i]-&gt;Run();
    }

but then he and many others suggested that I would better use [Boost pointer containers  
][2] or `shared_ptr`. I have spent the last 3 hours reading about this topic, but the documentation seems pretty advanced to me . ****Can anyone give me a small code example of `shared_ptr` usage and why they suggested using `shared_ptr`. Also are there other types like `ptr_vector`, `ptr_list` and `ptr_deque`**  **

  
Edit1: I have read a code example too that included:

    typedef boost::shared_ptr&lt;Foo&gt; FooPtr;
    .......
    int main()
    {
      std::vector&lt;FooPtr&gt;         foo_vector;
    ........
    FooPtr foo_ptr( new Foo( 2 ) );
      foo_vector.push_back( foo_ptr );
    ...........
    }

And I don&#39;t understand the syntax!





[1]: https://stackoverflow.com/questions/3475030/different-types-of-objects-in-the-same-vector-array
  [2]: http://www.boost.org/doc/libs/1_43_0/libs/ptr_container/doc/guidelines.html

Example to use shared_ptr?

I have code like this:

    class RetInterface {...}

    class Ret1: public RetInterface {...}

    class AInterface
    {
      public:
         virtual boost::shared_ptr&lt;RetInterface&gt; get_r() const = 0;
         ...
    };

    class A1: public AInterface
    {
      public:
         boost::shared_ptr&lt;Ret1&gt; get_r() const {...}
         ...
    };

**This code does not compile.**

In visual studio it raises

&gt; C2555: overriding virtual function return type differs and is not
&gt; covariant

If I do not use `boost::shared_ptr` but return raw pointers, the code compiles (I understand this is due to [covariant return types][1] in C++). I can see the problem is because `boost::shared_ptr` of `Ret1` is not derived from `boost::shared_ptr` of `RetInterface`. But I want to return `boost::shared_ptr` of `Ret1` for use in other classes, else I must cast the returned value after the return.   

1. Am I doing something wrong? 
2. If not, why is the language like this - it should be extensible to handle conversion between smart pointers in this scenario? Is there a desirable workaround?

[1]: http://en.wikipedia.org/wiki/Parameter_covariance#C.2B.2B

How can I use covariant return types with smart pointers?

Given the common situation where the lifespan of an owned object is linked to its owner, I can use a unique pointer one of 2 ways . . 

**It can be assigned:**

    class owner
    {
        std::unique_ptr&lt;someObject&gt; owned;    
    public:
        owner()
        {
            owned=std::unique_ptr&lt;someObject&gt;(new someObject());        
        }
    };

**The reset method can be utilised:**

    class owner
    {
        std::unique_ptr&lt;someObject&gt; owned;    
    public:
        owner()
        {
            owned.reset(new someObject());
        }
    };

In the interests of best practice, should I prefer one form over the other?

**EDIT:** Sorry folks. I over simplified this. The heap allocation occurs in an initialise method and not in the ctor. Therefore, I cannot use initialiser lists.

Should I assign or reset a unique_ptr?

I recently watched a great talk by Herb Sutter about &quot;Leak Free C++...&quot; at CppCon 2016 where he talked about using smart pointers to implement RAII (Resource acquisition is initialization) - Concepts and how they solve most of the memory leaks issues.

Now I was wondering. If I strictly follow RAII rules, which seems to be a good thing, why would that be any different from having a garbage collector in C++? I know that with RAII the programmer is in full control of when the resources are freed again, but is that in any case beneficial to just having a garbage collector? Would it really be less efficient? I even heard that having a garbage collector can be more efficient, as it can free larger chunks of memory at a time instead of freeing small memory pieces all over the code.

RAII vs. Garbage Collector

If I understand correctly, a `weak_ptr` doesn&#39;t increment the reference count of the managed object, therefore it doesn&#39;t represent ownership. It simply lets you access an object, the lifetime of which is managed by someone else.
So I don&#39;t really see why a `weak_ptr` can&#39;t be constructed from a `unique_ptr`, but only a `shared_ptr`.

Can someone briefly explain this?

Why can&#39;t a weak_ptr be constructed from a unique_ptr?

After reading [this answer][1], it looks like it is a best practice to use [smart pointers][2] as much as possible, and to reduce the usage of &quot;normal&quot;/raw pointers to minimum.

Is that true?

  [1]: https://stackoverflow.com/questions/2585247/code-reading-where-can-i-read-great-modern-and-well-documented-c-code/2585397#2585397
  [2]: http://www.boost.org/doc/libs/1_47_0/libs/smart_ptr/smart_ptr.htm

When should I use raw pointers over smart pointers?

The [`std::unique_ptr`][1] template has two parameters: the type of the pointee, and the type of the deleter. This second parameter has a default value, so you usually just write something like `std::unique_ptr&lt;int&gt;`.

The [`std::shared_ptr`][2] template has only one parameter though: the type of the pointee. But you can use a custom deleter with this one too, even though the deleter type is not in the class template. The usual implementation uses type erasure techniques to do this.

Is there a reason the same idea was not used for `std::unique_ptr`?

  [1]: http://en.cppreference.com/w/cpp/memory/unique_ptr
  [2]: http://en.cppreference.com/w/cpp/memory/shared_ptr


Why does unique_ptr have the deleter as a type parameter while shared_ptr doesn&#39;t?

I have a series of factories that return `unique_ptr&lt;Base&gt;`. Under the hood, though, they are providing pointers to various derived types, i.e `unique_ptr&lt;Derived&gt;`, `unique_ptr&lt;DerivedA&gt;`, `unique_ptr&lt;DerivedB&gt;`etc.

Given `DerivedA : Derived` and `Derived : Base` we&#39;d have:

    unique_ptr&lt;Base&gt; DerivedAFactory() {
        return unique_ptr&lt;Base&gt;(new DerivedA);
    }

What I need to do is to &quot;cast&quot; the pointer from the returned `unique_ptr&lt;Base&gt;` to some derived level (not necessarily the original internal one). To illustrate in pseudo code:

    unique_ptr&lt;Derived&gt; ptr = static_cast&lt;unique_ptr&lt;Derived&gt;&gt;(DerivedAFactory());

I&#39;m thinking of doing this by releasing the object from the `unique_ptr`, then using a function that casts the raw pointer and reassigns that to another `unique_ptr` of the desired flavor (the `release` would be explicitly done by the caller prior to the call):

    unique_ptr&lt;Derived&gt; CastToDerived(Base* obj) {
        return unique_ptr&lt;Derived&gt;(static_cast&lt;Derived*&gt;(obj));
    }

Is this valid, or is / will there be something funky going on?

---

_PS. There is an added complication in that some of the factories reside in DLLs that are dynamically loaded at run-time, which means I need to make sure the produced objects are destroyed in the same context (heap space) as they were created. The transfer of ownership (which typically happens in another context) must then supply a deleter from the original context. But aside from having to supply / cast a deleter along with the pointer, the casting problem should be the same._

&quot;Downcasting&quot; unique_ptr&lt;Base&gt; to unique_ptr&lt;Derived&gt;

What&#39;s the difference between:

    std::shared_ptr&lt;int&gt; p = std::shared_ptr&lt;int&gt;( new int );

and 

    std::shared_ptr&lt;int&gt; p = std::make_shared&lt; int &gt;();

?

Which one should I prefer and why?

P. S. Pretty sure this must have been answered already, but I can&#39;t find a similar question.

std::shared_ptr initialization: make_shared&lt;Foo&gt;() vs shared_ptr&lt;T&gt;(new Foo)

I have something like `shared_ptr&lt;Type&gt; t(makeSomething(), mem_fun(&amp;Type::deleteMe))`
I now need to call C styled function that requires a pointer to `Type`. How do I get it from `shared_ptr`?

getting a normal ptr from shared_ptr?

How do smart pointers handle arrays? For example,

    void function(void)
    {
        std::unique_ptr&lt;int&gt; my_array(new int[5]);
    }

When `my_array` goes out of scope and gets destructed, does the entire integer array get re-claimed? Is only the first element of the array reclaimed? Or is there something else going on (such as undefined behavior)?

smart pointers and arrays

With the advent of `std::unique_ptr`, the blemished `std::auto_ptr` can finally be put to rest.  So for the last several days, I have been changing my code to use smart pointers and to eliminate all `delete` from my code.

Although valgrind says my code is memory-clean, the semantic richness of smart pointers will make for cleaner and easier-to-understand code.

In most of the code, the translation is simple: use `std::unique_ptr` for in place of the raw pointers held by the owning objects, throw out `delete`, and carefully sprinkle `get()`, `reset()` and `move()` calls, as needed, to interface well with the rest of the code.

I am at the point where I am translating **non-owning raw pointers** to smart pointers now.

Since I was careful with the lifetimes of my objects (I ensure my modules only depend in one direction), valgrind tells me that I don&#39;t have any uninitialized reads, dangling pointers, or leaks.  So, technically, I could just leave those **non-owning raw pointers** alone now.

However, one option is to change those **non-owning raw pointers** to `std::shared_ptr` because I know they are acyclic.  Or, would it be better to leave them as raw pointers?

*I need some advice from veteran users of smart pointers as to what rules of thumb you use to decide whether to keep **non-owning raw pointers** as-is, or to translate them into `std::shared_ptr`,* keeping in mind that I constantly unit-test and valgrind my code.

EDIT:  I might be misunderstanding the use of `std::shared_ptr` - can they be used in conjunction with `std::unique_ptr`, or is it the case that if I use `std::shared_ptr`, all handles should also be `std::shared_ptr`?

All Smart Pointers Solutions on Gang of Coders

Total of 39 Smart Pointers Solutions