&lt;!-- language-all: lang-cpp --&gt;

I&#39;m new to move semantics in C++11 and I don&#39;t know very well how to handle `unique_ptr` parameters in constructors or functions. Consider this class referencing itself:

    #include &lt;memory&gt;

    class Base
    {
      public:
    
        typedef unique_ptr&lt;Base&gt; UPtr;
    
        Base(){}
        Base(Base::UPtr n):next(std::move(n)){}
    
        virtual ~Base(){}
    
        void setNext(Base::UPtr n)
        {
          next = std::move(n);
        }
    
      protected :
    
        Base::UPtr next;
    
    };

Is this how I should write functions taking `unique_ptr` arguments?

And do I need to use `std::move` in the calling code?

    Base::UPtr b1;
    Base::UPtr b2(new Base());
    
    b1-&gt;setNext(b2); //should I write b1-&gt;setNext(std::move(b2)); instead?


How do I pass a unique_ptr argument to a constructor or a function?

`unique_ptr&lt;T&gt;` does not allow copy construction, instead it supports move semantics. Yet, I can return a `unique_ptr&lt;T&gt;` from a function and assign the returned value to a variable.

    #include &lt;iostream&gt;
    #include &lt;memory&gt;
     
    using namespace std;
     
    unique_ptr&lt;int&gt; foo()
    {
      unique_ptr&lt;int&gt; p( new int(10) );
     
      return p;                   // 1
      //return move( p );         // 2
    }
     
    int main()
    {
      unique_ptr&lt;int&gt; p = foo();
     
      cout &lt;&lt; *p &lt;&lt; endl;
      return 0;
    }

The code above compiles and works as intended. So how is it that line `1` doesn&#39;t invoke the copy constructor and result in compiler errors? If I had to use line `2` instead it&#39;d make sense (using line `2` works as well, but we&#39;re not required to do so).

I know C++0x allows this exception to `unique_ptr` since the return value is a temporary object that will be destroyed as soon as the function exits, thus guaranteeing the uniqueness of the returned pointer. I&#39;m curious about how this is implemented, is it special cased in the compiler or is there some other clause in the language specification that this exploits?

Returning unique_ptr from functions

&gt; **Possible Duplicates:**  
&gt; [pimpl: shared_ptr or unique_ptr](https://stackoverflow.com/questions/5576922/pimpl-shared-ptr-or-unique-ptr)  
&gt; [smart pointers (boost) explained](https://stackoverflow.com/questions/569775/smart-pointers-boost-explained)  

&lt;!-- End of automatically inserted text --&gt;

Could someone explain differences between shared_ptr and unique_ptr?

Differences between unique_ptr and shared_ptr

`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?

I have some code in a header that looks like this:

    #include &lt;memory&gt;
    
    class Thing;

    class MyClass
    {
        std::unique_ptr&lt; Thing &gt; my_thing;
    };

If I include this header in a cpp that does not include the `Thing` type definition, then this does not compile under VS2010-SP1:

&gt; 1&gt;C:\Program Files (x86)\Microsoft
&gt; Visual Studio
&gt; 10.0\VC\include\memory(2067): error C2027: use of undefined type &#39;Thing&#39;

Replace `std::unique_ptr` by `std::shared_ptr` and it compiles.

So, I&#39;m guessing that it&#39;s the current VS2010 `std::unique_ptr`&#39;s implementation that requires the full definition and it&#39;s totally implementation-dependant.

Or is it? Is there something in it&#39;s standard requirements that makes impossible for `std::unique_ptr`&#39;s implementation to work with a forward declaration only? It feels strange as it should only hold a pointer to `Thing`, shouldn&#39;t it?

Is std::unique_ptr&lt;T&gt; required to know the full definition of T?

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?

I&#39;m using the pimpl-idiom with `std::unique_ptr`:

    class window {
      window(const rectangle&amp; rect);
      
    private:
      class window_impl; // defined elsewhere
      std::unique_ptr&lt;window_impl&gt; impl_; // won&#39;t compile
    };

However, I get a compile error regarding the use of an incomplete type, on line 304 in `&lt;memory&gt;`:

&gt; Invalid application of &#39;`sizeof`&#39; to an incomplete type &#39;`uixx::window::window_impl`&#39;

For as far as I know, `std::unique_ptr` should be able to be used with an incomplete type. Is this a bug in libc++ or am I doing something wrong here?

std::unique_ptr with an incomplete type won&#39;t compile

Why is there no `std::make_unique` function template in the standard C++11 library? I find

    std::unique_ptr&lt;SomeUserDefinedType&gt; p(new SomeUserDefinedType(1, 2, 3));

a bit verbose. Wouldn&#39;t the following be much nicer?

    auto p = std::make_unique&lt;SomeUserDefinedType&gt;(1, 2, 3);

This hides the `new` nicely and only mentions the type once.

Anyway, here is my attempt at an implementation of `make_unique`:

    template&lt;typename T, typename... Args&gt;
    std::unique_ptr&lt;T&gt; make_unique(Args&amp;&amp;... args)
    {
    	return std::unique_ptr&lt;T&gt;(new T(std::forward&lt;Args&gt;(args)...));
    }

It took me quite a while to get the `std::forward` stuff to compile, but I&#39;m not sure if it&#39;s correct. Is it? What exactly does `std::forward&lt;Args&gt;(args)...` mean? What does the compiler make of that?

make_unique and perfect forwarding

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

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 have a class with a unique_ptr member.

    class Foo {
    private:
        std::unique_ptr&lt;Bar&gt; bar;
        ...
    };

The Bar is a third party class that has a create() function and a destroy() function.

If I wanted to use a `std::unique_ptr` with it in a stand alone function I could do:

    void foo() {
        std::unique_ptr&lt;Bar, void(*)(Bar*)&gt; bar(create(), [](Bar* b){ destroy(b); });
        ...
    }

Is there a way to do this with `std::unique_ptr` as a member of a class?


How do I use a custom deleter with a std::unique_ptr member?

What are the advantages of using `std::make_unique` over the `new` operator for initializing a `std::unique_ptr`? 

In other words, why is 

    std::unique_ptr&lt;SomeObject&gt; a = std::make_unique(SomeObject(...))

better than doing

    std::unique_ptr&lt;SomeObject&gt; a = new SomeObject(...)

I tried looking up a lot online and I do know that it is a good rule of thumb to avoid the operator `new` in modern C++, but I am not sure what the advantages are in this exact scenario. Does it prevent any kind of memory leaks that might happen? Is it faster to do a `std::make_unique` than to use `new`? 
 

Advantages of using std::make_unique over new operator

How can I pass a `std::unique_ptr` into a function? Lets say I have the following class:

    class A
    {
    public:
        A(int val)
        {
            _val = val;
        }

        int GetVal() { return _val; }
    private:
        int _val;
    };

The following does not compile:


    void MyFunc(unique_ptr&lt;A&gt; arg)
    {
        cout &lt;&lt; arg-&gt;GetVal() &lt;&lt; endl;
    }

    int main(int argc, char* argv[])
    {
        unique_ptr&lt;A&gt; ptr = unique_ptr&lt;A&gt;(new A(1234));
        MyFunc(ptr);

	    return 0;
    }

Why can I not pass a `std::unique_ptr` into a function? Surely this is the primary purpose of the construct? Or did the C++ committee intend for me to fall back to raw C-style pointers and pass it like this:
    
    MyFunc(&amp;(*ptr)); 

And most strangely of all, why is this an OK way of passing it? It seems horribly inconsistent:

    MyFunc(unique_ptr&lt;A&gt;(new A(1234)));



How can I pass std::unique_ptr into a function

How do I implement a copy constructor for a class that has a `unique_ptr` member variable? I am only considering C++11.

Copy constructor for a class with unique_ptr

I try to understand how `std::unique_ptr` works and for that I found [this][1] document. The author starts from the following example:

    #include &lt;utility&gt;  //declarations of unique_ptr
    using std::unique_ptr;
    // default construction
    unique_ptr&lt;int&gt; up; //creates an empty object
    // initialize with an argument
    unique_ptr&lt;int&gt; uptr (new int(3));
    double *pd= new double;
    unique_ptr&lt;double&gt; uptr2 (pd);
    // overloaded * and -&gt;
    *uptr2 = 23.5;
    unique_ptr&lt;std::string&gt; ups (new std::string(&quot;hello&quot;));
    int len=ups-&gt;size();

What is confusing to me is that in this line

    unique_ptr&lt;int&gt; uptr (new int(3));

We use integer as an argument (between round brackets) and here

    unique_ptr&lt;double&gt; uptr2 (pd);

we used an pointer as an argument. Does it make any difference? 

What is also not clear to me, is how pointers, declared in this way will be different from the pointers declared in a &quot;normal&quot; way.

  [1]: http://www.codeguru.com/cpp/article.php/c17775/The-Smart-Pointer-That-Makes-Your-C-Applications-Safer--stduniqueptr.htm

How to declare std::unique_ptr and what is the use of it?

Does C++11 standard library provide any utility to convert from a `std::shared_ptr` to `std::unique_ptr`, or vice versa? Is this safe operation?

Does C++11 unique_ptr and shared_ptr able to convert to each other&#39;s type?

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 trying to compile the following thread pool program posted on code review to test it.

https://codereview.stackexchange.com/questions/55100/platform-independant-thread-pool-v4

But I am getting the errors

    threadpool.hpp: In member function ‘std::future&lt;decltype (task((forward&lt;Args&gt;)(args)...))&gt; threadpool::enqueue_task(Func&amp;&amp;, Args&amp;&amp; ...)’:
    threadpool.hpp:94:28: error: ‘make_unique’ was not declared in this scope
         auto package_ptr = make_unique&lt;task_package_impl&lt;R, decltype(bound_task)&gt;&gt;  (std::move(bound_task), std::move(promise));
                            ^
    threadpool.hpp:94:81: error: expected primary-expression before ‘&gt;’ token
         auto package_ptr = make_unique&lt;task_package_impl&lt;R, decltype(bound_task)&gt;&gt;(std::move(bound_task), std::move(promise));
                                                                                 ^
    main.cpp: In function ‘int main()’:
    main.cpp:9:17: error: ‘make_unique’ is not a member of ‘std’
     auto ptr1 = std::make_unique&lt;unsigned&gt;();
                 ^
    main.cpp:9:34: error: expected primary-expression before ‘unsigned’
     auto ptr1 = std::make_unique&lt;unsigned&gt;();
                                  ^
    main.cpp:14:17: error: ‘make_unique’ is not a member of ‘std’
     auto ptr2 = std::make_unique&lt;unsigned&gt;();
                 ^
    main.cpp:14:34: error: expected primary-expression before ‘unsigned’
     auto ptr2 = std::make_unique&lt;unsigned&gt;();


error::make_unique is not a member of ‘std’

As far as I understand, C++14 introduced `std::make_unique` because, as a result of the parameter evaluation order not being specified, this was unsafe:

    f(std::unique_ptr&lt;MyClass&gt;(new MyClass(param)), g()); // Syntax A

(Explanation: if the evaluation first allocates the memory for the raw pointer, then calls `g()` and an exception is thrown before the `std::unique_ptr` construction, then the memory is leaked.)

Calling `std::make_unique` was a way to constrain the call order, thus making things safe:

    f(std::make_unique&lt;MyClass&gt;(param), g());             // Syntax B


----------

Since then, C++17 has clarified the evaluation order, making Syntax A safe too, so here&#39;s my question: **is there still a reason to use `std::make_unique` over `std::unique_ptr`&#39;s constructor in C++17? Can you give some examples?**

As of now, the only reason I can imagine is that it allows to type `MyClass` only once (assuming you don&#39;t need to rely on polymorphism with `std::unique_ptr&lt;Base&gt;(new Derived(param))`). However, that seems like a pretty weak reason, especially when `std::make_unique` doesn&#39;t allow to specify a deleter while `std::unique_ptr`&#39;s constructor does.

And just to be clear, I&#39;m not advocating in favor of removing `std::make_unique` from the Standard Library (keeping it makes sense at least for backward compatibility), but rather wondering if there are still situations in which it is strongly preferred to `std::unique_ptr`


Why use std::make_unique in C++17?

Is this code correct? 

    auto v =  make_unique&lt;int&gt;(12);
    v.release();     // is this possible?

Is it equivalent to `delete` of a raw pointer?

Does unique_ptr::release() call the destructor?

I&#39;m watching Chandler Carruth&#39;s talk in CppCon 2019:

[There are no Zero-Cost Abstractions][1]

in it, he gives the example of how he was surprised by just how much overhead you incur by using an `std::unique_ptr&lt;int&gt;` over an `int*`; that segment starts about at time point 17:25.

You can have a look at the [compilation results][2] of his example pair-of-snippets (godbolt.org) - to witness that, indeed, it seems the compiler is not willing to pass the unique_ptr value - which in fact in the bottom line is just an address - inside a register, only in straight memory.

One of the points Mr. Carruth makes at around 27:00 is that the C++ ABI requires by-value parameters (some but not all; perhaps - non-primitive types? non-trivially-constructible types?) to be passed in-memory rather than within a register.

My questions:

1. Is this actually an ABI requirement on some platforms? (which?) Or maybe it&#39;s just some pessimization in certain scenarios?
2. Why is the ABI like that? That is, if the fields of a struct/class fit within registers, or even a single register - why should we not be able to pass it within that register?
3. Has the C++ standards committee discussed this point in recent years, or ever?

------------

PS - So as not to leave this question with no code:

Plain pointer:
```
void bar(int* ptr) noexcept;
void baz(int* ptr) noexcept;

void foo(int* ptr) noexcept {
    if (*ptr &gt; 42) {
        bar(ptr); 
        *ptr = 42; 
    }
    baz(ptr);
}
```

Unique pointer:
```
using std::unique_ptr;
void bar(int* ptr) noexcept;
void baz(unique_ptr&lt;int&gt; ptr) noexcept;

void foo(unique_ptr&lt;int&gt; ptr) noexcept {
    if (*ptr &gt; 42) { 
        bar(ptr.get());
        *ptr = 42; 
    }
    baz(std::move(ptr));
}
```



  [1]: https://www.youtube.com/watch?v=rHIkrotSwcc
  [2]: https://godbolt.org/z/5yv_41

Why can a T* be passed in register, but a unique_ptr&lt;T&gt; cannot?

I am having my first attempt at using C++11 `unique_ptr`; I am replacing a polymorphic raw pointer inside a project of mine, which is owned by one class, but passed around quite frequently.

I used to have functions like:

    bool func(BaseClass* ptr, int other_arg) {
      bool val;
      // plain ordinary function that does something...
      return val;
    }

But I soon realized that I wouldn&#39;t be able to switch to:

    bool func(std::unique_ptr&lt;BaseClass&gt; ptr, int other_arg);

Because the caller would have to handle the pointer ownership to the function, what I don&#39;t want to. So, what is the best solution to my problem?

I though of passing the pointer as reference, like this:

    bool func(const std::unique_ptr&lt;BaseClass&gt;&amp; ptr, int other_arg);

But I feel very uncomfortable in doing so, firstly because it seems non instinctive to pass something already typed as `_ptr` as reference, what would be a reference of a reference. Secondly because the function signature gets even bigger. Thirdly, because in the generated code, it would be necessary two consecutive pointer indirections to reach my variable.

How to pass std::unique_ptr around?

I&#39;m trying to use a `unique_ptr` to derived class in a function that takes a `unique_ptr` to a base class. Something like:

    class Base {};
    
    class Derived : public Base {};
    
    void f(unique_ptr&lt;Base&gt; const &amp;base) {}

    …

    unique_ptr&lt;Derived&gt; derived = unique_ptr&lt;Derived&gt;(new Derived);
    f(derived);

If I understand [this answer](https://stackoverflow.com/a/8114913/41071) correctly, this code should work, but it causes the following compile errors:

&gt; error C2664: &#39;f&#39; : cannot convert parameter 1 from &#39;std::unique_ptr&lt;_Ty&gt;&#39; to &#39;const std::unique_ptr&lt;_Ty&gt; &amp;&#39;
&gt;
&gt; IntelliSense: no suitable user-defined conversion from &quot;std::unique_ptr&amp;lt;Derived, std::default_delete&amp;lt;Derived&gt;&gt;&quot; to &quot;const std::unique_ptr&amp;lt;Base, std::default_delete&amp;lt;Base&gt;&gt;&quot; exists

If I change `f` to take `unique_ptr&lt;Derived&gt; const &amp;derived`, it works fine, but that&#39;s not what I want.

Am I doing something wrong? What can I do to work around this?

I&#39;m using Visual Studio 2012.

unique_ptr to a derived class as an argument to a function that takes a unique_ptr to a base class

I have found it useful to use forward declaration of classes in combination with `std::unique_ptr` as in the code below. It compiles and works with GCC, but the whole thing seem kind of strange, and I wonder if this is standard behaviour (i.e. required by the standard)? Since B isn&#39;t a complete type when I declare the `unique_ptr`.

###A.hpp
    #include &lt;memory&gt;

    class B;

    class A {
        std::unique_ptr&lt;B&gt; myptr;
        // B::~B() can&#39;t be seen from here
    public:
        ~A();
    };

###A.cpp
    #include &quot;B.hpp&quot;
    //B.hpp has to be included, otherwise it doesn&#39;t work.

    A::~A() = default; // without this line, it won&#39;t compile 
    // however, any destructor definiton will do.

I suspect this has to do with the destructor (and therefore the need to call the destructor of `unique_ptr&lt;B&gt;`) is defined in a specific compilation unit (A.cpp).

Forward declaration with unique_ptr?

What is the proper way to create an unique_ptr that holds an array that is allocated on the free store? Visual studio 2013 supports this by default, but when I use gcc version 4.8.1 on Ubuntu I get memory leaks and undefined behaviour.

The problem can be reproduced with this code:   

    #include &lt;memory&gt;
    #include &lt;string.h&gt;
    
    using namespace std;
    
    int main()
    {
    	unique_ptr&lt;unsigned char&gt; testData(new unsigned char[16000]());
    
    	memset(testData.get(),0x12,0);
    
    	return 0;
    }

Valgrind will give this output:

    ==3894== 1 errors in context 1 of 1:
    ==3894== Mismatched free() / delete / delete []
    ==3894==    at 0x4C2BADC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==3894==    by 0x400AEF: std::default_delete&lt;unsigned char&gt;::operator()(unsigned char*) const (unique_ptr.h:67)
    ==3894==    by 0x4009D0: std::unique_ptr&lt;unsigned char, std::default_delete&lt;unsigned char&gt; &gt;::~unique_ptr() (unique_ptr.h:184)
    ==3894==    by 0x4007A9: main (test.cpp:19)
    ==3894==  Address 0x5a1a040 is 0 bytes inside a block of size 16,000 alloc&#39;d
    ==3894==    at 0x4C2AFE7: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==3894==    by 0x40075F: main (test.cpp:15)



Proper way to create unique_ptr that holds an allocated array

 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?

Is `unique_ptr` guaranteed to store `nullptr` after move?

    std::unique_ptr&lt;int&gt; p1{new int{23}};
    std::unique_ptr&lt;int&gt; p2{std::move(p1)};
    assert(!p1); // is this always true?

Is unique_ptr guaranteed to store nullptr after move?

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?

Both [`unique_ptr`][1] and [`shared_ptr`][2] accept a custom deleter to call on the object they own. But in the case of `unique_ptr`, the deleter is passed as a template parameter of the _class_, whereas the type of `shared_ptr`&#39;s custom deleter is to be specified as a template parameter of the _constructor_.

    template &lt;class T, class D = default_delete&lt;T&gt;&gt; 
    class unique_ptr
    {
        unique_ptr(T*, D&amp;); //simplified
        ...
    };

and

    template&lt;class T&gt;
    class shared_ptr
    {
        template&lt;typename D&gt;
        shared_ptr(T*, D); //simplified
        ...
    };


I can&#39;t see why such difference. What requires that?


  [1]: http://www.cplusplus.com/reference/memory/unique_ptr/
  [2]: http://www.cplusplus.com/reference/memory/shared_ptr/shared_ptr/

Why does unique_ptr take two template parameters when shared_ptr only takes one?

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?

Doesn&#39;t `std::unique_ptr::get` defeat the purpose of having a unique_ptr in the first place?
I would have expected this function to change its state so it holds no more pointer.
Is there an actual useful use of std::unique_ptr::get?

what&#39;s the point of std::unique_ptr::get

I have a C++ object of type `ObjectArray`
    
    typedef map&lt;int64_t, std::unique_ptr&lt;Class1&gt;&gt; ObjectArray;

What is the syntax to create a `unique_ptr` to a new object of type `Class1` and insert it into an object of type `ObjectArray`?

C++ inserting unique_ptr in map

I&#39;ve got the following batch of code:

    std::vector&lt;std::unique_ptr&lt;AVLTree_GeeksforGeeks&gt;&gt; AVLArray(100000);

    /* Let&#39;s add some objects in the vector */
    AVLTree_GeeksforGeeks *avl = new AVLTree_GeeksforGeeks();
    avl-&gt;Insert[2]; avl-&gt;Insert[5]; AVL-&gt;Insert[0];
    unique_ptr&lt;AVLTree_GeeksforGeeks&gt; unique_p(avl);
    AVLArray[0] = move(unique_p);
    /* we do this for a number of other trees, let&#39;s say another 9...
    ...
    ...
    Now the vector has objects up until AVLTree[9] */

    /* Let&#39;s try iterating through its valid, filled positions */
    for(auto i : AVLTree )
    {
       cout &lt;&lt; &quot;Hey there!\n&quot;;    //This loop should print 10 &quot;Hey there&quot;s.
    }

**Ruh roh.** Compilation error at the last part, in the for() loop.

    \DataStructures2013_2014\main.cpp||In function &#39;int main()&#39;:|
    \DataStructures2013_2014\main.cpp|158|error: use of deleted function &#39;std::unique_ptr&lt;_Tp, _Dp&gt;::unique_ptr(const std::unique_ptr&lt;_Tp, _Dp&gt;&amp;) [with _Tp = AVLTree_GeeksforGeeks; _Dp = std::default_delete&lt;AVLTree_GeeksforGeeks&gt;; std::unique_ptr&lt;_Tp, _Dp&gt; = std::unique_ptr&lt;AVLTree_GeeksforGeeks&gt;]&#39;|
    e:\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.7.1\include\c++\bits\unique_ptr.h|256|error: declared here|
    ||=== Build finished: 2 errors, 0 warnings (0 minutes, 0 seconds) ===|


Any ideas on what I am doing wrong?

Iterating through vector&lt;unique_ptr&lt;mytype&gt;&gt; using C++11 for() loops

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;

Here is a simplification of what I&#39;m seeing when I try to use unique_ptr for pimpl.  I chose unique_ptr because I really want the class to own the pointer - I want the lifetimes of the pimpl pointer and the class to be the same.

Anyway, here is the header:

    #ifndef HELP
    #define HELP 1
    
    #include &lt;memory&gt;
    
    class Help
    {
    
    public:
    
      Help(int ii);
      ~Help() = default;
    
    private:
    
      class Impl;
      std::unique_ptr&lt;Impl&gt; _M_impl;
    };
    
    #endif // HELP

Here is the source:

    #include &quot;Help.h&quot;
    
    class Help::Impl
    {
    public:
      Impl(int ii)
      : _M_i{ii}
      { }
    
    private:
    
      int _M_i;
    };
    
    Help::Help(int ii)
    : _M_impl{new Help::Impl{ii}}
    { }

I could compile these into a library just fine.  But when I try to use it in a test program I get

    ed@bad-horse:~/ext_distribution$ ../bin/bin/g++ -std=c++0x -o test_help test_help.cpp Help.cpp
    In file included from /home/ed/bin/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/memory:86:0,
                     from Help.h:4,
                     from test_help.cpp:3:
    /home/ed/bin/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/unique_ptr.h: In instantiation of &#39;void std::default_delete&lt;_Tp&gt;::operator()(_Tp*) const [with _Tp = Help::Impl]&#39;:
    /home/ed/bin/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/unique_ptr.h:245:4:   required from &#39;void std::unique_ptr&lt;_Tp, _Dp&gt;::reset(std::unique_ptr&lt;_Tp, _Dp&gt;::pointer) [with _Tp = Help::Impl; _Dp = std::default_delete&lt;Help::Impl&gt;; std::unique_ptr&lt;_Tp, _Dp&gt;::pointer = Help::Impl*]&#39;
    /home/ed/bin/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/unique_ptr.h:169:32:   required from &#39;std::unique_ptr&lt;_Tp, _Dp&gt;::~unique_ptr() [with _Tp = Help::Impl; _Dp = std::default_delete&lt;Help::Impl&gt;]&#39;
    Help.h:6:7:   required from here
    /home/ed/bin/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/unique_ptr.h:63:14: error: invalid application of &#39;sizeof&#39; to incomplete type &#39;Help::Impl&#39;

This is a well known [safety feature][1].  I&#39;ve tried to follow.

My problem is that if I put Help::Impl declaration in a header it would seem to obviate any advantage of pimpl.  The class layout is visible to users.  The definition is hidden but I could have done that with the Help class and private members.  Also, including the declaration of Impl brings in new headers that I would have liked to keep separate.

What am I missing?  What do folks put in an Impl declaration and where?  Am I doing the Help dtor wrong?  Argh!

  [1]: https://stackoverflow.com/questions/6012157/does-stdunique-ptrt-requires-to-know-the-full-t-definition


How do I use unique_ptr for pimpl?

Is the sole difference between `boost::scoped_ptr&lt;T&gt;` and `std::unique_ptr&lt;T&gt;` the fact that `std::unique_ptr&lt;T&gt;` has move semantics whereas `boost::scoped_ptr&lt;T&gt;` is just a get/reset smart pointer?

Difference between boost::scoped_ptr&lt;T&gt; and std::unique_ptr&lt;T&gt;

I guess it&#39;s pretty self explanatory - I can&#39;t seem to use C++11 features, even though I think I have everything set up properly - which likely means that I don&#39;t.

Here&#39;s my code:

	#include &lt;cstdlib&gt;
	#include &lt;iostream&gt;

	class Object {
		private:
			int value;
			
		public:
			Object(int val) {
				value = val;
			}
			
			int get_val() {
				return value;
			}
			
			void set_val(int val) {
				value = val;
			}
	};

	int main() {
		
		Object *obj = new Object(3);
		std::unique_ptr&lt;Object&gt; smart_obj(new Object(5));
		std::cout &lt;&lt; obj-&gt;get_val() &lt;&lt; std::endl;
		return 0;
	}

Here&#39;s my version of g++:

&lt;!-- language: none --&gt;

	ubuntu@ubuntu:~/Desktop$ g++ --version
	g++ (Ubuntu/Linaro 4.7.3-2ubuntu1~12.04) 4.7.3
	Copyright (C) 2012 Free Software Foundation, Inc.
	This is free software; see the source for copying conditions.  There is NO
	warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Here&#39;s how I&#39;m compiling the code:

&lt;!-- language: none --&gt;

	ubuntu@ubuntu:~/Desktop$ g++ main.cpp -o run --std=c++11
	main.cpp: In function ‘int main()’:
	main.cpp:25:2: error: ‘unique_ptr’ is not a member of ‘std’
	main.cpp:25:24: error: expected primary-expression before ‘&gt;’ token
	main.cpp:25:49: error: ‘smart_obj’ was not declared in this scope

Note that I&#39;ve tried both `-std=c++11` and `-std=c++0x` to no avail.

I&#39;m running Ubuntu 12.04 LTS from a flash drive on an Intel x64 machine.


error: ‘unique_ptr’ is not a member of ‘std’

I&#39;m trying to figure out how/if I can use `unique_ptr` in a `queue`.

    // create queue
    std::queue&lt;std::unique_ptr&lt;int&gt;&gt; q;
    
    // add element
    std::unique_ptr&lt;int&gt; p (new int{123});
    q.push(std::move(p));

    // try to grab the element
    auto p2 = foo_queue.front();
    q.pop(); 

I do understand why the code above doesn&#39;t work.  Since the `front` &amp; `pop` are 2 separate steps, the element cannot be moved. Is there a way to do this?

remove unique_ptr from queue

According to N3290, `std::unique_ptr` accepts a deleter argument in its constructor.

However, I can&#39;t get that to work with Visual C++ 10.0 or MinGW g++ 4.4.1 in Windows, nor with g++ 4.6.1 in Ubuntu.

I therefore fear that my understanding of it is incomplete or wrong. I can&#39;t see the point of a deleter argument that&#39;s apparently ignored, so can anyone provide a working example?

Preferably I&#39;d like to see also how that works for `unique_ptr&lt;Base&gt; p = unique_ptr&lt;Derived&gt;( new Derived )`.

Possibly with some wording from the standard to back up the example, i.e. that with whatever compiler you&#39;re using, it actually does what it&#39;s supposed to do?

How does the custom deleter of std::unique_ptr work?

In C++11, you can use a `shared_ptr&lt;&gt;` to establish an ownership relation with an object or variable and `weak_ptr&lt;&gt;` to safely reference that object in a non-owned way.

You can also use `unique_ptr&lt;&gt;` to establish an ownership relation with an object or variable. But what if other, non-owning objects want to also reference that object? `weak_ptr&lt;&gt;` isn&#39;t helpful in this case. Raw pointers are helpful but bring various downsides (e.g. they can be [automatically initialized to nullptr][1] but this is accomplished through techniques that are not consistent with the `std::*_ptr&lt;&gt;` types).

What is the equivalent of `weak_ptr&lt;&gt;` for non-owning references to objects owned via `unique_ptr&lt;&gt;`?

Here&#39;s a clarifying example that resembles something in a game I&#39;m working on.

    class World
    {
    public:
    
        Trebuchet* trebuchet() const { return m_trebuchet.get(); }
    
    private:
        std::unique_ptr&lt; Trebuchet &gt; m_trebuchet;
    };
    
    class Victim
    {
    public:
        Victim( Trebuchet* theTrebuchet ) : m_trebuchet( theTrebuchet ) {}
    
        ~Victim()
        {
            delete m_trebuchet;     // Duh. Oops. Dumb error. Nice if the compiler helped prevent this.
        }
    
    private:
    
        Trebuchet* m_trebuchet;    // Non-owning.
    };
    
    shared_ptr&lt; Victim &gt; createVictim( World&amp; world )
    {
        return make_shared&lt; Victim &gt;( world.trebuchet() );
    }

Here we use a raw pointer to maintain a non-owning relationship with an object owned via `unique_ptr&lt;&gt;` elsewhere. But is raw the best we can do?

The hope is a type of pointer that:

* Looks like the other modern pointer types. E.g. `std::raw_ptr&lt;T&gt;`.
* Replaces raw pointers so that a codebase that uses modern pointer types throughout can find *all* pointers via a search for `_ptr&lt;` (roughly).
* Auto-initializes to nullptr.

Thus:

    int* p;                  // Unknown value.
    std::raw_ptr&lt; int &gt; p;   // null.

Does this type already exist in C++ now, is it proposed for the future, or is another implementation broadly available in e.g. Boost?

  [1]: https://stackoverflow.com/questions/17534210/trivial-raw-pointer-that-self-initializes-to-nullptr-in-c


shared_ptr&lt;&gt; is to weak_ptr&lt;&gt; as unique_ptr&lt;&gt; is to... what?

Is there some equivalent class for C++1x&#39;s std::unique_ptr in the boost libraries? The behavior I&#39;m looking for is being able to have an exception-safe factory function, like so...

    std::unique_ptr&lt;Base&gt; create_base()
    {
        return std::unique_ptr&lt;Base&gt;(new Derived);
    }

    void some_other_function()
    {
        std::unique_ptr&lt;Base&gt; b = create_base();

        // Do some stuff with b that may or may not throw an exception...

        // Now b is destructed automagically.
    }

EDIT: Right now, I&#39;m using this hack, which seems like the best I can get at this point...

    Base* create_base()
    {
        return new Derived;
    }

    void some_other_function()
    {
        boost::scoped_ptr&lt;Base&gt; b = create_base();

        // Do some stuff with b that may or may not throw an exception...

        // Now b is deleted automagically.
    }

unique_ptr boost equivalent?

I&#39;ve been making some objects using the pimpl idiom, but I&#39;m not sure whether to use [`std::shared_ptr`](http://en.cppreference.com/w/cpp/memory/shared_ptr) or [`std::unique_ptr`](http://en.cppreference.com/w/cpp/memory/unique_ptr). 

I understand that `std::unique_ptr` is more efficient, but this isn&#39;t so much of an issue for me, as these objects are relatively heavyweight anyway so the cost of `std::shared_ptr` over `std::unique_ptr` is relatively minor.

I&#39;m currently going with `std::shared_ptr` just because of the extra flexibility. For example, using a `std::shared_ptr` allows me to store these objects in a hashmap for quick access while still being able to return copies of these objects to callers (as I believe any iterators or references may quickly become invalid).

However, these objects in a way really aren&#39;t being copied, as changes affect all copies, so I was wondering that perhaps using `std::shared_ptr` and allowing copies is some sort of anti-pattern or bad thing.

Is this correct?

Should I use shared_ptr or 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 have tried the following:

    std::function&lt;void ()&gt; getAction(std::unique_ptr&lt;MyClass&gt; &amp;&amp;psomething){
        //The caller given ownership of psomething
        return [psomething](){ 
            psomething-&gt;do_some_thing();
            //psomething is expected to be released after this point
        };
    }

But it does not compile. Any ideas?

UPDATE:

AS suggested, some new syntax is required to explicitly specify we need to transfer the ownership to the lambda, I am now thinking about the following syntax:

    std::function&lt;void ()&gt; getAction(std::unique_ptr&lt;MyClass&gt; psomething){
        //The caller given ownership of psomething
        return [auto psomething=move(psomething)](){ 
            psomething-&gt;do_some_thing();
            //psomething is expected to be released after this point
        };
    }

Would it be a good candidate?

UPDATE 1:

I will show my implementation of `move` and `copy` as following:

    template&lt;typename T&gt;
    T copy(const T &amp;t) {
        return t;
    }

    //process lvalue references
    template&lt;typename T&gt;
    T move(T &amp;t) {
        return std::move(t);
    }

    class A{/*...*/};

    void test(A &amp;&amp;a);

    int main(int, char **){
        A a;
        test(copy(a));    //OK, copied
        test(move(a));    //OK, moved
        test(A());        //OK, temporary object
        test(copy(A()));  //OK, copying temporary object
        //You can disable this behavior by letting copy accepts T &amp;  
        //test(move(A())); You should never move a temporary object
        //It is not good to have a rvalue version of move.
        //test(a); forbidden, you have to say weather you want to copy or move
        //from a lvalue reference.
    }

How to capture a unique_ptr into a lambda expression?

This code is what I want to do: 

    Tony&amp; Movie::addTony()
    {
        Tony *newTony = new Tony;
        std::unique_ptr&lt;Tony&gt; tony(newTony);
        attachActor(std::move(tony));
        return *newTony;
    }

I am wondering if I could do this instead:

    Tony&amp; Movie::addTony()
    {
        std::unique_ptr&lt;Tony&gt; tony(new Tony);
        attachActor(std::move(tony));
        return *tony.get();
    }

But will `*tony.get()` be the same pointer or null? I know I could verify, but what is the standard thing for it to do?

All Unique Ptr Solutions on Gang of Coders

Total of 46 Unique Ptr Solutions