make-shared

Consider this code : #include <memory> #include <iostream> class SomeClass { public: SomeClass() { std::cout << "SomeClass()" << std::endl; } ~SomeClass() { std::cout << "~SomeClass()" << std::endl; } void* operator new(std::size_t size) { std::cout << "Custom new" << std::endl; return ::operator new(size); } void operator delete(void* ptr, std::size_t size) { std::cout << "Custom delete" << std::endl; ::operator delete(ptr); } }; int main() { std::shared_ptr<SomeClass> ptr1(new SomeClass); std::cout << std::endl << "Another one..." << std::endl << std::endl; std::shared_ptr<SomeClass> ptr2

In hindsight, given make_shared , would shared_ptr have a constructor that takes a raw pointer had it been introduced with C++11? Are there strong arguments or use cases in favor of this constructor? It would have avoided the well documented pitfall of exception-safety and the memory allocation/performance advantage of using make_shared . I believe another advantage of requiring shared_ptr construction via make_shared would be that it could be a single pointer under the hood, lowering its memory use and making things like atomic_compare_exchange a lot simpler (and possibly more efficient).

In cppref , the following holds until C++17: code such as f(std::shared_ptr<int>(new int(42)), g()) can cause a memory leak if g gets called after new int(42) and throws an exception, while f(std::make_shared<int>(42), g()) is safe, since two function calls are never interleaved. I'm wondering which change introduced in C++17 renders this no longer applicable. The evaluation order of function arguments are changed by P0400R0 . Before the change, evaluation of function arguments are unsequenced relative to one another. This means evaluation of g() may be inserted into the evaluation of std:

I have a class template Templ with template parameter T, and the Templ class has a data member of type T, called obj. I wrote a variadic constructor template which forwards the arguments to obj's constructor: template <class T> class Templ { public: template <class... Args> explicit Templ (Args&&... args) : obj (std::forward<Args>(args)...) { } private: T obj; }; Now I realized that type T may be a class with an init-list constructor, and I want it to be accessible via Templ. So I checked what std::list::emplace and std::make_shared do. They have a variadic function like mine, but they don't

As I understand make_shared<T>(...) may provide some memory allocation optimization (it may allocate reference counter within same memory block as instance of class T). Do enable_shared_from_this provides the same optimization? So: class T : std::enable_shared_from_this<T> {}; ... auto t = std::shared_ptr<T>(new T); Is the same as: class T {}; ... auto t = std::make_shared<T>(); If not take in account sizeof(T). Do enable_shared_from_this provides the same optimization? So: No. As you can see from the wording in the standard, enable_shared_from_this<T> has a weak_ptr<T> data member. That adds

Since C++11, because of several reasons, developers tend to use smart pointer classes for dynamic lifetime objects. And with those new smart pointer classes, standards, even suggest to not use operators like new instead they suggest to use make_shared or make_unique to avoid some error prone. If we like to use a smart pointer class, like shared_ptr , we can construct one like, shared_ptr<int> p(new int(12)); Also we would like to pass a custom deleter to smart pointer classes, shared_ptr<int> p(new int(12), deleter); On the other hand, if we like to use make_shared to allocate, for ex. int ,