The most common mistake to do in a constructor as well as in a destructor, is to use polymorphism. Polymorphism often does not work in constructors ! e.g.: class A { public: A(){ doA();} virtual void doA(){}; } class B : public A { public: virtual void doA(){ doB();}; void doB(){}; } void testB() { … Read more
You could do it like this: template<typename T> boost::shared_ptr<T> make_shared_ptr(std::shared_ptr<T>& ptr) { return boost::shared_ptr<T>(ptr.get(), [ptr](T*) mutable {ptr.reset();}); } template<typename T> std::shared_ptr<T> make_shared_ptr(boost::shared_ptr<T>& ptr) { return std::shared_ptr<T>(ptr.get(), [ptr](T*) mutable {ptr.reset();}); } EDIT: Note that this does not work with weak references to the source ptr. So be careful with those!
Basically, shared_ptr has two pointers: a pointer to the shared object and a pointer to a struct containing two reference counts: one for “strong references,” or references that have ownership, and one for “weak references,” or references that don’t have ownership. When you copy a shared_ptr, the copy constructor increments the strong reference count. When … Read more
shared_ptr<T> and shared_ptr<const T> are not interchangable. It goes one way – shared_ptr<T> is convertable to shared_ptr<const T> but not the reverse. Observe: // f.cpp #include <memory> int main() { using namespace std; shared_ptr<int> pint(new int(4)); // normal shared_ptr shared_ptr<const int> pcint = pint; // shared_ptr<const T> from shared_ptr<T> shared_ptr<int> pint2 = pcint; // error! … Read more
If you just want to call a function from B you can use one of these: std::shared_ptr<A> ap = …; dynamic_cast<B&>(*ap).b_function(); if (B* bp = dynamic_cast<B*>(ap.get()) { … } In case you actually want to get a std::shared_ptr<B> from the std::shared_ptr<A>, you can use use std::shared_ptr<B> bp = std::dynamic_pointer_cast<B>(ap);
As other have said, make_shared cannot be used with a custom deleter. But I want to explain why. Custom deleters exist because you allocated the pointer in some special way, and therefore you need to be able to deallocate it in a correspondingly special way. Well, make_shared allocates the pointer with new. Objects allocated with … Read more
Cyclic references: a shared_ptr<> to something that has a shared_ptr<> to the original object. You can use weak_ptr<> to break this cycle, of course. I add the following as an example of what I am talking about in the comments. class node : public enable_shared_from_this<node> { public : void set_parent(shared_ptr<node> parent) { parent_ = parent; … Read more
The reason is simple: in object X, enable_shared_from_this works by initialising a hidden weak_ptr with a copy of the first shared_ptr which points to object X. However, for a shared_ptr to be able to point to X, X must already exist (it must be already constructed). Therefore, while the constructor of X is running, there … Read more
Author of Botan replied to me that The problem is the globally defined object. The problem is that the mlock pool is a singleton created on first use then destroyed sometime after main returns. First your object is created. It allocates memory. This results in the pool being created. Destruction happens LIFO. So first the … Read more
In addition to the points presented by @deft_code, an even weaker one: If you use weak_ptrs that live after all the shared_ptrs to a given object have died, then this object’s memory will live in memory along with the control block until the last weak_ptr dies. In other words the object is destroyed but not … Read more