What&#39;s the equivalent to the following:

    std::vector&lt;Foo*&gt; vec;
    vec.push_back(NULL);

when dealing with `boost::shared_ptr`? Is it the following code?

    std::vector&lt; boost::shared_ptr&lt;Foo&gt; &gt; vec;
    vec.push_back(boost::shared_ptr&lt;Foo&gt;());

Note: I may push back a lot of such objects. Should I declare a global static `nullPtr` object somewhere? That way only one of them would have to be constructed:

    boost::shared_ptr&lt;Foo&gt; nullPtr;

NULL pointer with boost::shared_ptr?

    shared_ptr&lt;Shape&gt; circle(new Circle(Vec2f(0, 0), 0.1, Vec3f(1, 0, 0)));

    shared_ptr&lt;Shape&gt; rect(new Rect2f(Vec2f(0, 0), 5.0f, 5.0f, 0,
                                      Vec3f(1.0f, 1.0f, 0))              );


I&#39;m trying to understand why the above won&#39;t compile. For Whatever reason, when I try to create an instance of Rect2f (which DOES inherit from the `Shape` class specified the `shared_ptr` template argument, just like `Circle`), I get the following **errors**:

    error: expected type-specifier before &#39;Rect2f&#39;
    error: expected &#39;)&#39; before &#39;Rect2f&#39;

Everything about the `Circle` `shared_ptr` is perfectly fine. There are no problems with it; it&#39;s only the `Rect2f` which is causing issues. 

Furthermore, the values passed into the constructor are valid. 

So, what could the issue be with this one? I have `Rect.h` included for this. For brevity&#39;s sake (and incase I missed something in that file which may be affecting this), I&#39;ll post the following:

**Rect.h**

    #pragma once
    
    #include &lt;QGLWidget&gt;
    #include &lt;GL/glext.h&gt;
    #include &lt;cmath&gt;
    #include &lt;QDebug&gt;
    #include &quot;Shape.h&quot;
    #include &quot;Vec3f.h&quot;
    #include &quot;rand.h&quot;
    
    const int DEFAULT_SQUARE_WIDTH = 5;
    const int DEFAULT_SQUARE_HEIGHT = 5;
    
    typedef enum {
        RC_TOPLEFT,
        RC_TOPRIGHT,
        RC_BOTTOMRIGHT,
        RC_BOTTOMLEFT
    } RectangleCorner;
    
    class Rect2f : public Shape
    {
    public:
    
        Rect2f(
            Vec2f center = Vec2f(),
            float width = 4,
            float height = 4,
            float radius = 0,
            Vec3f color = Vec3f()
        );
    
        ~Rect2f();
    
        inline const float GetWidth( void ) const {
            return mWidth;
        }
    
        inline const float GetHeight( void ) const {
            return mHeight;
        }
    
        inline const Vec2f* GetCorner( RectangleCorner rc ) const {
            switch( rc ) {
            case RC_TOPLEFT:
                return mTopLeftCrnr;
                break;
    
            case RC_TOPRIGHT:
                return mTopRightCrnr;
                break;
    
            case RC_BOTTOMLEFT:
                return mBottomLeftCrnr;
                break;
    
            case RC_BOTTOMRIGHT:
                return mBottomRightCrnr;
                break;
            }
        }
    
        void UpdateCorners();
    
        virtual void Collide( Shape &amp;s );
    
        virtual void Collide( Rect2f &amp;r );
    
        virtual void Collide ( Circle &amp;c );
    
        virtual bool Intersects( const Shape&amp; s ) const;
    
        virtual bool Intersects( const Rect2f&amp; s ) const;
    
        virtual bool IsAlive( void ) const;
    
        virtual float Mass( void ) const;
    
    protected:
    
       virtual void Draw( void ) const;
       float mWidth, mHeight;
       Vec3f mColor;
    
    private:
       Vec2f* mTopLeftCrnr;
       Vec2f* mTopRightCrnr;
       Vec2f* mBottomLeftCrnr;
       Vec2f* mBottomRightCrnr;
    
    };


**Source of Error Function and File Header (mainwindow.cpp)**

    #include &quot;ui_mainwindow.h&quot;
    #include &quot;Vec2f.h&quot;
    #include &quot;Rect2f.h&quot;
    #include &quot;SharedPtr.h&quot;
    
    MainWindow::MainWindow(QWidget *parent) :
        QMainWindow(parent),
        ui(new Ui::MainWindow)
    {
        ui-&gt;setupUi( this );
    
        BoxOfShapes* display = new  InteractiveBoxOfShapes( this, 600, 600 );
        ui-&gt;mGridLayout-&gt;addWidget( display );
        ui-&gt;mStatusBar-&gt;showMessage( &quot;status ok&quot; );
    
        QObject::connect( display, SIGNAL( numShapesChanged( int ) ), this, SLOT( setNumShapes(int) ) );
        QObject::connect( ui-&gt;mResetButton, SIGNAL( pressed() ), display, SLOT( resetWorld() ) );
        shared_ptr&lt;Shape&gt; circle(
                    new Circle(
                        Vec2f( 0, 0 ),
                        0.1,
                        Vec3f( 1, 0, 0 ) ) );
        /*std::shared_ptr&lt;Shape&gt; rect( &lt;---error
                         new Rect2f(
                            Vec2f( 0, 0 ),
                            5.0f,
                            5.0f,
                            0,
                            Vec3f( 1.0f, 1.0f, 0 )
                        )
                    );*/
        shared_ptr&lt; Shape &gt; rect( new Rect2f() ); //error - second attempt 
        display-&gt;addShape( circle );
        display-&gt;addShape( rect );
    }

**Main Function Test (main.cpp)**

    #include &lt;QtGui/QApplication&gt;
    #include &quot;mainwindow.h&quot;
    #include &quot;Rect2f.h&quot;
    
    int main(int argc, char *argv[])
    {
        Rect2f rec;
    
        QApplication a(argc, argv);
        MainWindow w;
        w.show();
    
        return a.exec();
    }


**Question**

Judging from the errors provided, what am I missing here? Also, what can be done to rectify this issue?


Error: expected type-specifier before &#39;ClassName&#39;

&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

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

I was experimenting with `shared_ptr` and `make_shared` from C++11 and programmed a little toy example to see what is actually happening when calling `make_shared`. As infrastructure I was using llvm/clang 3.0 along with the llvm std c++ library within XCode4.

    class Object
    {
    public:
        Object(const string&amp; str)
        {
            cout &lt;&lt; &quot;Constructor &quot; &lt;&lt; str &lt;&lt; endl;
        }
        
        Object()
        {
            cout &lt;&lt; &quot;Default constructor&quot; &lt;&lt; endl;
            
        }
        
        ~Object()
        {
            cout &lt;&lt; &quot;Destructor&quot; &lt;&lt; endl;
        }
        
        Object(const Object&amp; rhs)
        {
            cout &lt;&lt; &quot;Copy constructor...&quot; &lt;&lt; endl;
        }
    };

    void make_shared_example()
    {
        cout &lt;&lt; &quot;Create smart_ptr using make_shared...&quot; &lt;&lt; endl;
        auto ptr_res1 = make_shared&lt;Object&gt;(&quot;make_shared&quot;);
        cout &lt;&lt; &quot;Create smart_ptr using make_shared: done.&quot; &lt;&lt; endl;
        
        cout &lt;&lt; &quot;Create smart_ptr using new...&quot; &lt;&lt; endl;
        shared_ptr&lt;Object&gt; ptr_res2(new Object(&quot;new&quot;));
        cout &lt;&lt; &quot;Create smart_ptr using new: done.&quot; &lt;&lt; endl;
    }

Now have a look at the output, please:

&gt; Create smart_ptr using make_shared...
&gt; 
&gt; Constructor make_shared
&gt; 
&gt; Copy constructor...
&gt; 
&gt; Copy constructor...
&gt; 
&gt; Destructor
&gt; 
&gt; Destructor
&gt; 
&gt; Create smart_ptr using make_shared: done.
&gt; 
&gt; Create smart_ptr using new... 
&gt; 
&gt; Constructor new
&gt; 
&gt; Create smart_ptr using new: done.
&gt; 
&gt; Destructor
&gt; 
&gt; Destructor



It appears that `make_shared` is calling the copy constructor two times. If I allocate memory for an `Object` using a regular `new` this does not happen, only one `Object` is constructed.

What I am wondering about is the following. I heard that `make_shared` is supposed to be more efficient than using `new`&lt;sup&gt;([1], [2])&lt;/sup&gt;. One reason is because `make_shared` allocates the reference count together with the object to be managed in the same block of memory. OK, I got the point. This is of course more efficient than two separate allocation operations.

On the contrary I don&#39;t understand why this has to come with the cost of two calls to the copy constructor of `Object`. Because of this I am not convinced that `make_shared` is more efficient than allocation using `new` in *every* case. Am I wrong here? Well OK, One could implement a move constructor for `Object` but still I am not sure whether this this is more efficient than just allocating `Object` through `new`. At least not in every case. It would be true if copying `Object` is less expensive than allocating memory for a reference counter. But the `shared_ptr`-internal reference counter could be implemented using a couple of primitive data types, right?

Can you help and explain why `make_shared` is the way to go in terms of efficiency, despite the outlined copy overhead? 

  [1]: http://en.cppreference.com/w/cpp/memory/shared_ptr/make_shared

  [2]: http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/STL11-Magic-Secrets (around minute 10)


Is make_shared really more efficient than new?

shared_ptr: horrible speed

Are there any downsides with using `make_shared&lt;T&gt;()` instead of using `shared_ptr&lt;T&gt;(new T)`.

[Boost documentation][1] states 

&gt; There have been repeated requests from
&gt; users for a factory function that
&gt; creates an object of a given type and
&gt; returns a shared_ptr to it. Besides
&gt; convenience and style, such a function
&gt; is also exception safe and
&gt; considerably faster because it can use
&gt; a single allocation for both the
&gt; object and its corresponding control
&gt; block, eliminating a significant
&gt; portion of shared_ptr&#39;s construction
&gt; overhead. This eliminates one of the
&gt; major efficiency complaints about
&gt; shared_ptr.

  [1]: http://www.boost.org/doc/libs/1_41_0/libs/smart_ptr/make_shared.html

Are there any downsides with using make_shared to create a shared_ptr

&gt; **Updates**
&gt; 
&gt; [X] I discovered this happen when `TLS::credentials creds` is declared on
&gt; global scope but if I declare it outside seg fault won&#39;t happen. 
&gt; 
&gt; I need it to be global because it helps with caching certificates and
&gt; that multiple threads can use certificates created by other threads without
&gt; spending time on creating new certificates.
&gt;
&gt; [X] I further reduced code from 200 lines approx. to 100 lines

I&#39;m using Botan to create a TLS application and my application crash with a seg fault at end of the application. 

I made an attempt to debug this with Valgrind but it leading nowhere.

Here is the stack trace from Valgrind,

    ==3841967== Invalid write of size 8
    ==3841967==    at 0x4842964: memset (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==3841967==    by 0x566A82F: Botan::deallocate_memory(void*, unsigned long, unsigned long) (in /usr/lib/x86_64-linux-gnu/libbotan-2.so.12.12.1)
    ==3841967==    by 0x55E1A4D: ??? (in /usr/lib/x86_64-linux-gnu/libbotan-2.so.12.12.1)
    ==3841967==    by 0x40EC7B: std::_Sp_counted_base&lt;(__gnu_cxx::_Lock_policy)2&gt;::_M_release() (shared_ptr_base.h:155)
    ==3841967==    by 0x40EC29: std::__shared_count&lt;(__gnu_cxx::_Lock_policy)2&gt;::~__shared_count() (shared_ptr_base.h:730)
    ==3841967==    by 0x41112D: std::__shared_ptr&lt;Botan::RSA_Public_Data const, (__gnu_cxx::_Lock_policy)2&gt;::~__shared_ptr() (shared_ptr_base.h:1169)
    ==3841967==    by 0x411107: std::shared_ptr&lt;Botan::RSA_Public_Data const&gt;::~shared_ptr() (shared_ptr.h:103)
    ==3841967==    by 0x41109D: Botan::RSA_PublicKey::~RSA_PublicKey() (rsa.h:25)
    ==3841967==    by 0x410FC1: Botan::RSA_PrivateKey::~RSA_PrivateKey() (rsa.h:92)
    ==3841967==    by 0x410DC5: Botan::RSA_PrivateKey::~RSA_PrivateKey() (rsa.h:92)
    ==3841967==    by 0x410E8A: std::_Sp_counted_ptr&lt;Botan::RSA_PrivateKey*, (__gnu_cxx::_Lock_policy)2&gt;::_M_dispose() (shared_ptr_base.h:377)
    ==3841967==    by 0x40EC7B: std::_Sp_counted_base&lt;(__gnu_cxx::_Lock_policy)2&gt;::_M_release() (shared_ptr_base.h:155)
    ==3841967==  Address 0x9419080 is not stack&#39;d, malloc&#39;d or (recently) free&#39;d
    ==3841967== 
    ==3841967== 
    ==3841967== Process terminating with default action of signal 11 (SIGSEGV)
    ==3841967==  Access not within mapped region at address 0x9419080
    ==3841967==    at 0x4842964: memset (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
    ==3841967==    by 0x566A82F: Botan::deallocate_memory(void*, unsigned long, unsigned long) (in /usr/lib/x86_64-linux-gnu/libbotan-2.so.12.12.1)
    ==3841967==    by 0x55E1A4D: ??? (in /usr/lib/x86_64-linux-gnu/libbotan-2.so.12.12.1)
    ==3841967==    by 0x40EC7B: std::_Sp_counted_base&lt;(__gnu_cxx::_Lock_policy)2&gt;::_M_release() (shared_ptr_base.h:155)
    ==3841967==    by 0x40EC29: std::__shared_count&lt;(__gnu_cxx::_Lock_policy)2&gt;::~__shared_count() (shared_ptr_base.h:730)
    ==3841967==    by 0x41112D: std::__shared_ptr&lt;Botan::RSA_Public_Data const, (__gnu_cxx::_Lock_policy)2&gt;::~__shared_ptr() (shared_ptr_base.h:1169)
    ==3841967==    by 0x411107: std::shared_ptr&lt;Botan::RSA_Public_Data const&gt;::~shared_ptr() (shared_ptr.h:103)
    ==3841967==    by 0x41109D: Botan::RSA_PublicKey::~RSA_PublicKey() (rsa.h:25)
    ==3841967==    by 0x410FC1: Botan::RSA_PrivateKey::~RSA_PrivateKey() (rsa.h:92)
    ==3841967==    by 0x410DC5: Botan::RSA_PrivateKey::~RSA_PrivateKey() (rsa.h:92)
    ==3841967==    by 0x410E8A: std::_Sp_counted_ptr&lt;Botan::RSA_PrivateKey*, (__gnu_cxx::_Lock_policy)2&gt;::_M_dispose() (shared_ptr_base.h:377)
    ==3841967==    by 0x40EC7B: std::_Sp_counted_base&lt;(__gnu_cxx::_Lock_policy)2&gt;::_M_release() (shared_ptr_base.h:155)
    ==3841967==  If you believe this happened as a result of a stack
    ==3841967==  overflow in your program&#39;s main thread (unlikely but
    ==3841967==  possible), you can try to increase the size of the
    ==3841967==  main thread stack using the --main-stacksize= flag.
    ==3841967==  The main thread stack size used in this run was 8388608.
    ==3841967== 
    ==3841967== HEAP SUMMARY:
    ==3841967==     in use at exit: 149,626 bytes in 1,143 blocks
    ==3841967==   total heap usage: 211,782 allocs, 210,639 frees, 90,582,963 bytes allocated
    ==3841967== 
    ==3841967== LEAK SUMMARY:
    ==3841967==    definitely lost: 0 bytes in 0 blocks
    ==3841967==    indirectly lost: 0 bytes in 0 blocks
    ==3841967==      possibly lost: 1,352 bytes in 18 blocks
    ==3841967==    still reachable: 148,274 bytes in 1,125 blocks
    ==3841967==                       of which reachable via heuristic:
    ==3841967==                         newarray           : 1,536 bytes in 16 blocks
    ==3841967==         suppressed: 0 bytes in 0 blocks
    ==3841967== Rerun with --leak-check=full to see details of leaked memory
    ==3841967== 
    ==3841967== For lists of detected and suppressed errors, rerun with: -s
    ==3841967== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
    Segmentation fault (core dumped)

You can clone the Botan into your machine by issuing, 

    git clone https://github.com/randombit/botan.git

Then follow instructions from their [official website][1] to build &amp; install it.

You will need to create a Root Certificate Authority to use with the application and for that you must install OpenSSL on your machine.

Create a folder called `testApplication` and `cd` into it.

Then using Bash, issue the following series of commands to create a Root CA,

```sh
# Generate private key
openssl genrsa -des3 -out myCA.key 2048
# Generate root certificate
openssl req -x509 -new -nodes -key myCA.key -sha256 -days 825 -out myCA.pem
# Convert to Botan Format
openssl pkcs8 -topk8 -in myCA.key &gt; myCAKey.pkcs8.pem
```

Please use `thisispassword` as password.

Install clang compiler on your machine and then you can compile the source file as follows,

    clang++ example.cpp -o example  -Wthread-safety -Wall -Wextra -g -std=c++17 -pthread -lssl -lcrypto -lbotan-2 --I/usr/include/botan-2


example.cpp

    #include &lt;iostream&gt;
    #include &lt;string&gt;
    #include &lt;vector&gt;
    #include &lt;fstream&gt;
    #include &lt;sstream&gt;
    #include &lt;botan/tls_server.h&gt;
    #include &lt;botan/tls_callbacks.h&gt;
    #include &lt;botan/tls_session_manager.h&gt;
    #include &lt;botan/tls_policy.h&gt;
    #include &lt;botan/auto_rng.h&gt;
    #include &lt;botan/certstor.h&gt;
    #include &lt;botan/pk_keys.h&gt;
    #include &lt;botan/pkcs10.h&gt;
    #include &lt;botan/pkcs8.h&gt;
    #include &lt;botan/x509self.h&gt;
    #include &lt;botan/x509path.h&gt;
    #include &lt;botan/x509_ca.h&gt;
    #include &lt;botan/x509_ext.h&gt;
    #include &lt;botan/pk_algs.h&gt;
    #include &lt;botan/ber_dec.h&gt;
    #include &lt;botan/der_enc.h&gt;
    #include &lt;botan/oids.h&gt;
    #include &lt;botan/rsa.h&gt;
    
    namespace TLS
    {
        typedef std::chrono::duration&lt;int, std::ratio&lt;31556926&gt;&gt; years;
    
        class credentials : public Botan::Credentials_Manager
        {
        private:
            struct certificate
            {
                std::vector&lt;Botan::X509_Certificate&gt; certs;
                std::shared_ptr&lt;Botan::Private_Key&gt; key;
            };
    
            std::vector&lt;certificate&gt; creds;
            std::vector&lt;std::shared_ptr&lt;Botan::Certificate_Store&gt;&gt; store;
    
        public:
            void createCert(std::string hostname)
            {
                /**
                 * Initialize Root CA
                **/
    
                Botan::AutoSeeded_RNG rng;
    
                const Botan::X509_Certificate rootCert(&quot;myCA.pem&quot;);
    
                std::ifstream rootCertPrivateKeyFile(&quot;myCAKey.pkcs8.pem&quot;);
    
                Botan::DataSource_Stream rootCertPrivateKeyStream(rootCertPrivateKeyFile);
    
                std::unique_ptr&lt;Botan::Private_Key&gt; rootCertPrivateKey = Botan::PKCS8::load_key(rootCertPrivateKeyStream, &quot;thisispassword&quot;);
    
                Botan::X509_CA rootCA(rootCert, *rootCertPrivateKey, &quot;SHA-256&quot;, rng);
    
                /**
                * Generate a Cert &amp; Sign with Root CA
                **/
    
                Botan::X509_Cert_Options opts;
                std::shared_ptr&lt;Botan::Private_Key&gt; serverPrivateKeyShared(new Botan::RSA_PrivateKey(rng, 4096));
                Botan::RSA_PrivateKey* serverPrivateKey = (Botan::RSA_PrivateKey*)serverPrivateKeyShared.get();
    
                opts.common_name = hostname;
                opts.country = &quot;US&quot;;
    
                auto now = std::chrono::system_clock::now();
    
                Botan::X509_Time todayDate(now);
                Botan::X509_Time expireDate(now + years(1));
    
                Botan::PKCS10_Request req = Botan::X509::create_cert_req(opts, *serverPrivateKey, &quot;SHA-256&quot;, rng);
    
                auto serverCert = rootCA.sign_request(req, rng, todayDate, expireDate);
    
                /**
                 * Load Cert to In-Memory Database
                **/
    
                certificate cert;
    
                cert.certs.push_back(serverCert);
                cert.key = serverPrivateKeyShared;
    
                creds.push_back(cert);
            }
        };
    }; // namespace TLS
    
    TLS::credentials globalCreds;
    
    int main() {
        globalCreds.createCert(&quot;www.google.com&quot;);
    
        std::cout &lt;&lt; &quot;End&quot; &lt;&lt; &quot;\n&quot;;
    
        return 0;
    }

Here is the function from the Botan Lib that Valgrind refers to,

    void deallocate_memory(void* p, size_t elems, size_t elem_size)
       {
       if(p == nullptr)
          return;
    
       secure_scrub_memory(p, elems * elem_size);
    
    #if defined(BOTAN_HAS_LOCKING_ALLOCATOR)
       if(mlock_allocator::instance().deallocate(p, elems, elem_size))
          return;
    #endif
    
       std::free(p);
       }
    

  [1]: https://botan.randombit.net/handbook/building.html

Segmentation fault when using a shared_ptr for private_key

I have this code that doesn&#39;t work, but I think the intent is clear:

_testmakeshared.cpp_

    #include &lt;memory&gt;

    class A {
     public:
       static ::std::shared_ptr&lt;A&gt; create() {
          return ::std::make_shared&lt;A&gt;();
       }

     protected:
       A() {}
       A(const A &amp;) = delete;
       const A &amp;operator =(const A &amp;) = delete;
    };

    ::std::shared_ptr&lt;A&gt; foo()
    {
       return A::create();
    }

But I get this error when I compile it:

    g++ -std=c++0x -march=native -mtune=native -O3 -Wall testmakeshared.cpp
    In file included from /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../include/c++/4.6.1/bits/shared_ptr.h:52:0,
                     from /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../include/c++/4.6.1/memory:86,
                     from testmakeshared.cpp:1:
    testmakeshared.cpp: In constructor ‘std::_Sp_counted_ptr_inplace&lt;_Tp, _Alloc, _Lp&gt;::_Sp_counted_ptr_inplace(_Alloc) [with _Tp = A, _Alloc = std::allocator&lt;A&gt;, __gnu_cxx::_Lock_policy _Lp = (__gnu_cxx::_Lock_policy)2u]’:
    /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../include/c++/4.6.1/bits/shared_ptr_base.h:518:8:   instantiated from ‘std::__shared_count&lt;_Lp&gt;::__shared_count(std::_Sp_make_shared_tag, _Tp*, const _Alloc&amp;, _Args&amp;&amp; ...) [with _Tp = A, _Alloc = std::allocator&lt;A&gt;, _Args = {}, __gnu_cxx::_Lock_policy _Lp = (__gnu_cxx::_Lock_policy)2u]’
    /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../include/c++/4.6.1/bits/shared_ptr_base.h:986:35:   instantiated from ‘std::__shared_ptr&lt;_Tp, _Lp&gt;::__shared_ptr(std::_Sp_make_shared_tag, const _Alloc&amp;, _Args&amp;&amp; ...) [with _Alloc = std::allocator&lt;A&gt;, _Args = {}, _Tp = A, __gnu_cxx::_Lock_policy _Lp = (__gnu_cxx::_Lock_policy)2u]’
    /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../include/c++/4.6.1/bits/shared_ptr.h:313:64:   instantiated from ‘std::shared_ptr&lt;_Tp&gt;::shared_ptr(std::_Sp_make_shared_tag, const _Alloc&amp;, _Args&amp;&amp; ...) [with _Alloc = std::allocator&lt;A&gt;, _Args = {}, _Tp = A]’
    /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../include/c++/4.6.1/bits/shared_ptr.h:531:39:   instantiated from ‘std::shared_ptr&lt;_Tp&gt; std::allocate_shared(const _Alloc&amp;, _Args&amp;&amp; ...) [with _Tp = A, _Alloc = std::allocator&lt;A&gt;, _Args = {}]’
    /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../include/c++/4.6.1/bits/shared_ptr.h:547:42:   instantiated from ‘std::shared_ptr&lt;_Tp1&gt; std::make_shared(_Args&amp;&amp; ...) [with _Tp = A, _Args = {}]’
    testmakeshared.cpp:6:40:   instantiated from here
    testmakeshared.cpp:10:8: error: ‘A::A()’ is protected
    /usr/lib/gcc/x86_64-redhat-linux/4.6.1/../../../../include/c++/4.6.1/bits/shared_ptr_base.h:400:2: error: within this context
    
    Compilation exited abnormally with code 1 at Tue Nov 15 07:32:58

This message is basically saying that some random method way down in the template instantiation stack from `::std::make_shared` can&#39;t access the constructor because it&#39;s protected.

But I really want to use both `::std::make_shared` and prevent anybody from making an object of this class that isn&#39;t pointed at by a `::std::shared_ptr`. Is there any way to accomplish this?

How do I call ::std::make_shared on a class with only protected or private constructors?

Just a small query regarding [`shared_ptr`][1].

Is it a good practice to use `shared_ptr` pointing to an array?  For example,

    shared_ptr&lt;int&gt; sp(new int[10]);

If not, then why not? One reason I am already aware of is one can not increment/decrement the `shared_ptr`. Hence it can not be used like a normal pointer to an array.

  [1]: http://en.cppreference.com/w/cpp/memory/shared_ptr

shared_ptr to an array : should it be used?

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

I&#39;m writing an accessor method for a shared pointer in C++ that goes something like this:

    class Foo {
    public:
        return_type getBar() const {
            return m_bar;
        }

    private:
        boost::shared_ptr&lt;Bar&gt; m_bar;
    }

So to support the const-ness of `getBar()` the return type should be a `boost::shared_ptr` that prevents modification of the `Bar` it points to. My _guess_ is that `shared_ptr&lt;const Bar&gt;` is the type I want to return to do that, whereas `const shared_ptr&lt;Bar&gt;` would prevent reassignment of the pointer itself to point to a different `Bar` but allow modification of the `Bar` that it points to...  However, I&#39;m not sure. I&#39;d appreciate it if someone who knows for sure could either confirm this, or correct me if I got it wrong. Thanks!

Difference between `const shared_ptr&lt;T&gt;` and `shared_ptr&lt;const T&gt;`?

I found some code using std::shared_ptr&lt;void&gt; to perform arbitrary cleanup at shutdown. At first I thought this code could not possibly work, but then I tried the following:

    #include &lt;memory&gt;
    #include &lt;iostream&gt;
    #include &lt;vector&gt;
    
    class test {
    public:
      test() {
        std::cout &lt;&lt; &quot;Test created&quot; &lt;&lt; std::endl;
      }
      ~test() {
        std::cout &lt;&lt; &quot;Test destroyed&quot; &lt;&lt; std::endl;
      }
    };
    
    int main() {
      std::cout &lt;&lt; &quot;At begin of main.\ncreating std::vector&lt;std::shared_ptr&lt;void&gt;&gt;&quot; 
                &lt;&lt; std::endl;
      std::vector&lt;std::shared_ptr&lt;void&gt;&gt; v;
      {
        std::cout &lt;&lt; &quot;Creating test&quot; &lt;&lt; std::endl;
        v.push_back( std::shared_ptr&lt;test&gt;( new test() ) );
        std::cout &lt;&lt; &quot;Leaving scope&quot; &lt;&lt; std::endl;
      }
      std::cout &lt;&lt; &quot;Leaving main&quot; &lt;&lt; std::endl;
      return 0;
    }

This program gives the output:

    At begin of main.
    creating std::vector&lt;std::shared_ptr&lt;void&gt;&gt;
    Creating test
    Test created
    Leaving scope
    Leaving main
    Test destroyed

I have some ideas on why this might work, that have to do with the internals of std::shared_ptrs as implemented for G++. Since these objects wrap the internal pointer together with the counter the cast from `std::shared_ptr&lt;test&gt;` to `std::shared_ptr&lt;void&gt;` is probably not hindering the call of the destructor. Is this assumption correct?

And of course the much more important question: Is this guaranteed to work by the standard, or might further changes to the internals of std::shared_ptr, other implementations actually break this code?

Why do std::shared_ptr&lt;void&gt; work

What are the best practices for passing a shared_ptr?

Currently I pass shared_ptr function arguments like so:

    void function1( shared_ptr&lt;TYPE&gt;&amp; value );

Should I pass a shared_ptr by reference?

I am currently trying to learn how to use smart pointers. However while doing some experiments I discovered the following situation for which I could not find a satifying solution:

Imagine you have an object of class A being parent of an object of class B (the child), but both should know each other:    

    class A;
    class B;

    class A
    {
    public:
        void addChild(std::shared_ptr&lt;B&gt; child)
        {
            children-&gt;push_back(child);
 
            // How to do pass the pointer correctly?
            // child-&gt;setParent(this);  // wrong
            //                  ^^^^
        }

    private:        
        std::list&lt;std::shared_ptr&lt;B&gt;&gt; children;
    };

    class B
    {
    public:
        setParent(std::shared_ptr&lt;A&gt; parent)
        {
            this-&gt;parent = parent;
        };

    private:
        std::shared_ptr&lt;A&gt; parent;
    };

The question is how can an object of class A pass a `std::shared_ptr` of itself (`this`) to its child?

There are solutions for Boost shared pointers ([Getting a `boost::shared_ptr` for `this`](https://stackoverflow.com/questions/142391/getting-a-boostshared-ptr-for-this)), but how to handle this using the `std::` smart pointers?

std::shared_ptr of this

I&#39;m reading [http://gcc.gnu.org/onlinedocs/libstdc++/manual/shared_ptr.html](https://web.archive.org/web/20140318233637/http://gcc.gnu.org/onlinedocs/libstdc++/manual/shared_ptr.html) and some thread safety issues are still not clear for me:

 1. Standard guarantees that reference counting is handled thread safe and it&#39;s platform independent, right?
 2. Similar issue - standard guarantees that only one thread (holding last reference) will call delete on shared object, right?
 3. shared_ptr does not guarantee any thread safety for object stored in it?

EDIT:

Pseudo code:

    // Thread I
    shared_ptr&lt;A&gt; a (new A (1));
    
    // Thread II
    shared_ptr&lt;A&gt; b (a);
    
    // Thread III
    shared_ptr&lt;A&gt; c (a);
    
    // Thread IV
    shared_ptr&lt;A&gt; d (a);
    
    d.reset (new A (10));

Calling reset() in thread IV will delete previous instance of A class created in first thread and replace it with new instance? Moreover after calling reset() in IV thread other threads will see only newly created object?

std::shared_ptr thread safety explained

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;

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?

If I have a function that needs to work with a `shared_ptr`, wouldn&#39;t it be more efficient to pass it a reference to it (so to avoid copying the `shared_ptr` object)?
What are the possible bad side effects?
I envision two possible cases:

1) inside the function a copy is made of the argument, like in

    ClassA::take_copy_of_sp(boost::shared_ptr&lt;foo&gt; &amp;sp)  
    {  
         ...  
         m_sp_member=sp; //This will copy the object, incrementing refcount  
         ...  
    }  

2) inside the function the argument is only used, like in  
    
    Class::only_work_with_sp(boost::shared_ptr&lt;foo&gt; &amp;sp) //Again, no copy here  
    {    
        ...  
        sp-&gt;do_something();  
        ...  
    }  

I can&#39;t see in both cases a good reason to pass the `boost::shared_ptr&lt;foo&gt;` by value instead of by reference. Passing by value would only &quot;temporarily&quot; increment the reference count due to the copying, and then decrement it when exiting the function scope.
Am I overlooking something?

Just to clarify, after reading several answers: I perfectly agree on the premature-optimization concerns, and I always try to first-profile-then-work-on-the-hotspots. My question was more from a purely technical code-point-of-view, if you know what I mean.

C++ - passing references to std::shared_ptr or boost::shared_ptr

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?

If I declare an object wrapped in a shared pointer:

    std::shared_ptr&lt;myClass&gt; myClassObject(new myClass());
 
then I wanted to pass it as an argument to a method:

    DoSomething(myClassObject);
    
    //the called method
    void DoSomething(std::shared_ptr&lt;myClass&gt; arg1)
    {
       arg1-&gt;someField = 4;
    }

Does the above simply increment the shared_pt&#39;s reference count and everything is cool? Or does it leave a dangling pointer?

Are you still supposed to do this?:

    DoSomething(myClassObject.Get());
    
    void DoSomething(std::shared_ptr&lt;myClass&gt;* arg1)
    {
       (*arg1)-&gt;someField = 4;
    }

I think that the 2nd way may be more efficient because it only has to copy 1 address (as opposed to the whole smart pointer), but the 1st way seems more readable and I do not anticipate pushing performance limits. I just want to make sure there&#39;s not something dangerous about it.

Thank you.

Passing shared pointers as arguments

The &lt;a href=&quot;http://www.cplusplus.com/reference/memory/shared_ptr/&quot;&gt;cplusplus.com `shared_ptr` page&lt;/a&gt; calls out a distinction between an _empty_ `std::shared_ptr` and a _null_ `shared_ptr`. The &lt;a href=&quot;http://en.cppreference.com/w/cpp/memory/shared_ptr&quot;&gt;cppreference.com page&lt;/a&gt; doesn&#39;t explicitly call out the distinction, but uses both &quot;empty&quot; and comparison to `nullptr` in its description of `std::shared_ptr` behavior.

Is there a difference between an empty and a null `shared_ptr`? Is there any use case for such mixed-behavior pointers? Does a non-empty null `shared_ptr` even make sense? Would there ever be a case in normal usage (i.e. if you didn&#39;t explicitly construct one) where you could end up with an empty-but-non-null `shared_ptr`?

And do any of these answers change if you&#39;re using the Boost version instead of the C++11 version?

What is the difference between an empty and a null std::shared_ptr in C++?

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 am reading Scott Meyers &quot;Effective C++&quot; book. It was mentioned that there are `tr1::shared_ptr` and `tr1::weak_ptr` act like built-in pointers, but they keep track of how many `tr1::shared_ptrs` point to an object.  

This is known as reference counting. This works well in preventing resource leaks in acyclic data structures, but if two or more objects contain `tr1::shared_ptrs` such that a cycle is formed, the cycle may keep each other&#39;s reference count above zero, even when all external pointers to the cycle have been destroyed.  

That&#39;s where `tr1::weak_ptrs` come in.

My question is how cyclic data structures make the reference count above zero. I kindly request an example C++ program. How is the problem solved by `weak_ptrs`? (again, with example please).

shared_ptr and weak_ptr differences

I have a question about C++11 best practices.  When clearing a shared_ptr, should I use the `reset()` function with no parameter, or should I set the `shared_ptr` to `nullptr`?  For example:

    std::shared_ptr&lt;std::string&gt; foo(new std::string(&quot;foo&quot;));
    foo.reset();
    foo = nullptr;

**Is there any real difference, or are there advantages/disadvantages to either approach?**

C++11 When clearing shared_ptr, should I use reset or set to nullptr?

Consider:


    struct SomethingThatsABase
    {
        virtual bool IsChildOne() const { return false; }
        virtual bool IsChildTwo() const { return false; }
    };

    struct ChildOne : public SomethingThatsABase
    {
        virtual bool IsChildOne() const { return true; }
    };

    struct ChildTwo : public SomethingThatsABase
    {
        virtual bool IsChildTwo() const { return true; }
    };

    void SomeClientExpectingAChildOne(std::shared_ptr&lt;ChildOne&gt; const&amp; ptrOne)
    {
        //Does stuff
    }

    void SomeClient(std::shared_ptr&lt;SomethingThatsABase&gt; const&amp; ptr)
    {
        if (ptr-&gt;IsChildOne())
        {
            SomeClientExpectingAChildOne(ptr); //Oops.
            //Hmm.. can&#39;t static_cast here, because we need a `shared_ptr` out of it.
        }
    }

(Note that I can&#39;t simply do a `std::shared_ptr&lt;ChildOne&gt;(static_cast&lt;ChildOne*&gt;(ptr.get()))`, because then the reference counts don&#39;t get shared between the two `shared_ptr`s)

How does one downcast a std::shared_ptr?

I have a solid understanding of most `OOP` theory but the one thing that confuses me a lot is virtual destructors.

I thought that the destructor always gets called no matter what and for every object in the chain.


When are you meant to make them virtual and why?

When to use virtual destructors?

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?

What is the equivalent of a `static_cast` with `boost::shared_ptr`?

In other words, how do I have to rewrite the following 

    Base* b = new Derived();
    Derived* d = static_cast&lt;Derived*&gt;(b);

when using `shared_ptr`?

    boost::shared_ptr&lt;Base&gt; b(new Derived());
    boost::shared_ptr&lt;Derived&gt; d = ???




static_cast with boost::shared_ptr?

I would like to enable support for C++0x in GCC with `-std=c++0x`. I don&#39;t absolutely necessarily need any of the [currently supported C++11 features](http://gcc.gnu.org/projects/cxx0x.html) in GCC 4.5 (and soon 4.6), but I would like to start getting used to them. For example, in a few places where I use iterators, an `auto` type would be useful.

But again, I don&#39;t **need** any of the currently supported features. The goal here is to encourage me to incorporate the features of the new standard into my programming &quot;vocabulary&quot;. 

From what you know of the C++11 support, is it a good idea to enable it in GCC, and then embrace it by, for example, switching from using `boost::shared_ptr` to `std::shared_ptr` exclusively as the two don&#39;t mix?

PS: I&#39;m aware of [this good question](https://stackoverflow.com/questions/1086798/differences-between-different-flavours-of-shared-ptr) which compares the different flavors of `shared_ptr` but I&#39;m asking a higher level advice on which to use before the standard is finalized. Another way of putting that is, when a compiler like GCC says it supports an &quot;experimental feature&quot;, does that mean I am likely to encounter weird errors during compilation that will be major time sinks and a source of cryptic questions on StackOverflow?

**Edit**: I decided to switch back from `std::shared_ptr` because I just don&#39;t trust its support in GCC 4.5 as [shown by example in this question](https://stackoverflow.com/q/6322364/627517).

Should I switch from using boost::shared_ptr to std::shared_ptr?

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?

The standard provides a template specialization of `std::unique_ptr` which correctly calls the `delete[]` from its destructor:

    void func()
    {
       std::unique_ptr&lt; int[] &gt; arr(new int[10]);
    
       .......
    }

With `std::shared_ptr` this specialisation is not available, so it is necessary to
to provide a deleter which correctly calls `delete[]`:

    void func()
    {
        // Usage
        shared_ptr array (new double [256], [](double* arr) { delete [] arr; } ); 

        ..............
    }

Is this simply an oversight? (in the same way that there is an `std::copy_if`) or is there a reason?

Why isn&#39;t there a std::shared_ptr&lt;T[]&gt; specialisation?

    std::shared_ptr&lt;Object&gt; p1 = std::make_shared&lt;Object&gt;(&quot;foo&quot;);
    std::shared_ptr&lt;Object&gt; p2(new Object(&quot;foo&quot;));
Many google and stackoverflow posts are there on this, but I am not able to understand why `make_shared` is more efficient than directly using `shared_ptr`. 

Can someone explain me step by step sequence of objects created and operations done by both so that I will be able to understand how `make_shared` is efficient. I have given one example above for reference.

Difference in make_shared and normal shared_ptr in C++

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 am trying to keep a list of connected clients in asio. I have adapted the chat server example from the docs (http://www.boost.org/doc/libs/1_57_0/doc/html/boost_asio/example/cpp03/chat/chat_server.cpp) and here&#39;s the important part of what I ended up with:

    #include &lt;iostream&gt;
    #include &lt;boost/bind.hpp&gt;
    #include &lt;boost/shared_ptr.hpp&gt;
    #include &lt;boost/enable_shared_from_this.hpp&gt;
    #include &lt;boost/asio.hpp&gt;
    #include &lt;set&gt;
    
    using boost::asio::ip::tcp;
    
    class tcp_connection;
    
    std::set&lt;boost::shared_ptr&lt;tcp_connection&gt;&gt; clients;
    
    void add_client(boost::shared_ptr&lt;tcp_connection&gt; client)
    {
        clients.insert(client);
    }
    
    class tcp_connection : public boost::enable_shared_from_this&lt;tcp_connection&gt;
    {
    public:
        tcp_connection(boost::asio::io_service&amp; io_service) : socket_(io_service)
        {
        }
    
        tcp::socket socket_;
    
        void start()
        {
            add_client(shared_from_this());
        }
    
        tcp::socket&amp; socket()
        {
            return socket_;
        }
    };
    
    class tcp_server
    {
    public:
        tcp_server(boost::asio::io_service&amp; io_service)
            : io_service_(io_service),
            acceptor_(io_service, tcp::endpoint(tcp::v4(), 6767))
        {
            tcp_connection* new_connection = new tcp_connection(io_service_);
            acceptor_.async_accept(new_connection-&gt;socket(),
                                 boost::bind(&amp;tcp_server::start_accept, this, new_connection,
                                             boost::asio::placeholders::error));
        }
    
    private:
        void start_accept(tcp_connection* new_connection,
                          const boost::system::error_code&amp; error)
        {
            if (!error)
            {
                new_connection-&gt;start();
                new_connection = new tcp_connection(io_service_);
                acceptor_.async_accept(new_connection-&gt;socket(),
                                       boost::bind(&amp;tcp_server::start_accept, this, new_connection,
                                                   boost::asio::placeholders::error));
            }
        }
    
        boost::asio::io_service&amp; io_service_;
        tcp::acceptor acceptor_;
    };
    
    int main()
    {
        try
        {
            boost::asio::io_service io_service;
            tcp_server server(io_service);
            io_service.run();
        }
        catch (std::exception&amp; e)
        {
            std::cerr &lt;&lt; &quot;Exception: &quot; &lt;&lt; e.what() &lt;&lt; &quot;\n&quot;;
        }
    
        return 0;
    }

At the call to `shared_from_this()`, my server crashes with the message:

&gt; Exception: tr1::bad_weak_ptr

I have done some searching and it appears `shared_from_this()` is pretty particular, but I can&#39;t seem to find exactly what I need to change.

shared_from_this causing bad_weak_ptr

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?

I use std::tr1::shared_ptr extensively throughout my application. This includes passing objects in as function arguments. Consider the following:

    class Dataset {...}

    void f( shared_ptr&lt; Dataset const &gt; pds ) {...}
    void g( shared_ptr&lt; Dataset const &gt; pds ) {...}
    ...

While passing a dataset object around via shared_ptr guarantees its existence inside f and g, the functions may be called millions of times, which causes a lot of shared_ptr objects being created and destroyed. Here&#39;s a snippet of the flat gprof profile from a recent run:

&lt;pre&gt;
Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls   s/call   s/call  name
  9.74    295.39    35.12 2451177304     0.00     0.00  std::tr1::__shared_count&lt;(__gnu_cxx::_Lock_policy)2&gt;::__shared_count(std::tr1::__shared_count&lt;(__gnu_cxx::_Lock_policy)2&gt; const&amp;)
  8.03    324.34    28.95 2451252116     0.00     0.00  std::tr1::__shared_count&lt;(__gnu_cxx::_Lock_policy)2&gt;::~__shared_count()
&lt;/pre&gt;

So, ~17% of the runtime was spent on reference counting with shared_ptr objects. Is this normal?

A large portion of my application is single-threaded and I was thinking about re-writing some of the functions as
    
    void f( const Dataset&amp; ds ) {...}

and replacing the calls

    shared_ptr&lt; Dataset &gt; pds( new Dataset(...) );
    f( pds );

with

    f( *pds );

in places where I know for sure the object will not get destroyed while the flow of the program is inside f(). But before I run off to change a bunch of function signatures / calls, I wanted to know what the typical performance hit of passing by shared_ptr was. Seems like shared_ptr should not be used for functions that get called very often.

Any input would be appreciated. Thanks for reading.

-Artem

**Update:** After changing a handful of functions to accept `const Dataset&amp;`, the new profile looks like this:
&lt;pre&gt;
Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls   s/call   s/call  name
  0.15    241.62     0.37 24981902     0.00     0.00  std::tr1::__shared_count&lt;(__gnu_cxx::_Lock_policy)2&gt;::~__shared_count()
  0.12    241.91     0.30 28342376     0.00     0.00  std::tr1::__shared_count&lt;(__gnu_cxx::_Lock_policy)2&gt;::__shared_count(std::tr1::__shared_count&lt;(__gnu_cxx::_Lock_p\
olicy)2&gt; const&amp;)
&lt;/pre&gt;

I&#39;m a little puzzled by the number of destructor calls being smaller than the number of copy constructor calls, but overall I&#39;m very pleased with the decrease in the associated run-time. Thanks to all for their advice.


The cost of passing by shared_ptr

When a function takes a `shared_ptr` (from boost or C++11 STL), are you passing it:

  - by const reference: `void foo(const shared_ptr&lt;T&gt;&amp; p)`

  - or by value: `void foo(shared_ptr&lt;T&gt; p)` ?

I would prefer the first method because I suspect it would be faster. But is this really worth it or are there any additional issues?

Could you please give the reasons for your choice or if the case, why you think it does not matter.


Should we pass a shared_ptr by reference or by value?

I started studying smart pointers of C++11 and I don&#39;t see any useful use of `std::weak_ptr`. Can someone tell me when `std::weak_ptr` is useful/necessary?

When is std::weak_ptr useful?

I&#39;ve read that 

&gt; &quot;Multiple threads can simultaneously read and write different
&gt; shared_ptr objects, even when the objects are copies that share
&gt; ownership.&quot; ([MSDN: Thread Safety in the Standard C++ Library][1])

Does that mean that changing shared_ptr object is safe ?  
For an instance, is the next code considered safe:

    shared_ptr&lt;myClass&gt; global = make_shared&lt;myClass&gt;();
    ...
    
    //In thread 1
    shared_ptr&lt;myClass&gt; private = global;
    ...
    
    //In thread 2
    global = make_shared&lt;myClass&gt;();
    ...

Can I be sure in that case that thread 1 `private` will have the original value of `global` or the new value which thread 2 assigned but either way it will have a valid shared_ptr to myClass?


==EDIT==  
Just to explain my motivation. I want to have a shared pointer to hold my configuration and I have a thread pool to handle requests.  
so `global` is the global configuration.  
`thread 1` is taking the current configuration as it start to handle a request.  
`thread 2` is updating the configuration. (only apply to future requests)  

If it&#39;s work, I can update the configuration that way without breaking it in the middle of a request handling.

  [1]: http://msdn.microsoft.com/en-us/library/c9ceah3b%28v=vs.100%29.aspx

std::shared_ptr thread safety

This is a basic question, but I did not find a previous post about it. The title of the following question sounds like it might be the same question as mine, but the question itself does not match the title: https://stackoverflow.com/questions/14836691/is-it-better-to-use-shared-ptr-reset-or-operator

I am confused about the purpose of the `reset()` member function of `std::shared_ptr`: what does it contribute in addition to the assignment operator?

To be concrete, given the definition:

    auto p = std::make_shared&lt;int&gt;(1);

1. Are the following two lines equivalent:

        p = std::make_shared&lt;int&gt;(5);
        p.reset(new int(5));
2. What about these:

        p = nullptr;
        p.reset();

If the two lines are equivalent in both cases, then what is the purpose of `reset()`? 


----------


EDIT: Let me re-phrase the question to better emphasize its point. The question is: is there a case where `reset()` lets us achieve something that is not as easily achievable without it?

All Shared Ptr Solutions on Gang of Coders

Total of 43 Shared Ptr Solutions