Does c++11 have something equivalent to boost::intrusive_ptr? No. It does have std::make_shared which means std::shared_ptr is almost (see note below) as efficient as an intrusive smart pointer, because the reference counts will be stored adjacent in memory to the object itself, improving locality of reference and cache usage. It also provides std::enable_shared_from_this which allows you …
Completely rewriting this answer because I totally misunderstood. This is a tricky thing to get right! The usual implementation of std::weak_ptr and std::shared_ptr that is consistent with the standard is to have two heap objects: the managed object, and a control block. Each shared pointer that refers to the same object contains a pointer to …
As others have pointed out, you’ve got it figured out correctly regarding your original 3 questions. But the ending part of your edit 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 …
With C++17, shared_ptr can be used to manage a dynamically allocated array. The shared_ptr template argument in this case must be T[N] or T[]. So you may write shared_ptr<int[]> sp(new int[10]); From n4659, [util.smartptr.shared.const] template<class Y> explicit shared_ptr(Y* p); Requires: Y shall be a complete type. The expression delete[] p, when T is an array …
This question was perplexing enough that I emailed Peter Dimov (implementer of boost::shared_ptr and involved in standardization of std::shared_ptr) Here’s the gist of what he said (reprinted with his permission): My guess is that the Deleter had to be CopyConstructible really only as a relic of C++03 where move semantics didn’t exist. Your guess is …
Don’t. Boost’s FAQ entry: Q. Why doesn’t shared_ptr provide a release() function? A. shared_ptr cannot give away ownership unless it’s unique() because the other copy will still destroy the object. Consider: shared_ptr<int> a(new int); shared_ptr<int> b(a); // a.use_count() == b.use_count() == 2 int * p = a.release(); // Who owns p now? b will still …
Yes, if you move the shared pointer into the function, then: the original sourcePtr will become null, and the reference count does not get modified. If you know that you will no longer need the value of sourcePtr after the function call, moving it into the function is a slight optimisation, as it saves an …
shared_ptr must manage a reference counter and the carrying of a deleter functor that is deduced by the type of the object given at initialization. The shared_ptr class typically hosts two members: a T* (that is returned by operator-> and dereferenced in operator*) and a aux* where aux is a inner abstract class that contains: …
There is indeed a substantial difference between: shared_ptr<T> sp(new T()); And: shared_ptr<T> sp = make_shared<T>(); The first version performs an allocation for the T object, then performs a separate allocation to create the reference counter. The second version performs one single allocation for both the object and the reference counter, placing them in a contiguous …
MyType t; nasty_function(std::shared_ptr<MyType>(&t, [](MyType*){}));