gdb is not a compiler, it will not do the (not-so-)nice user-defined type conversions for you. If you wish to call a function that wants a string, you need to give it a string, not a const char*. Unfortunately, gdb cannot construct an std::string for you on the command line, again because it is not … Read more
What you’re looking for is a release function; shared_ptr doesn’t have a release function. Per the Boost manual: 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() == … Read more
boost::shared_ptr<> offers a certain level of thread safety. The reference count is manipulated in a thread safe manner (unless you configure boost to disable threading support). So you can copy a shared_ptr around and the ref_count is maintained correctly. What you cannot do safely in multiple threads is modify the actual shared_ptr object instance itself … Read more
Your program is incorrect; the shared-ownership pointer facilities are not intended to be used for synchronization. [intro.multithread]/24: The implementation may assume that any thread will eventually do one of the following: — terminate, — make a call to a library I/O function, — access or modify a volatile object, or — perform a synchronization operation … Read more
So shared ptr and weak ptr are thread safe, in that if you have an instance of the object local to a given thread, and they share a common pointed-to object, you can interact with them in one thread and another and everything works. For this to work properly, you have to use them properly. … Read more
Unfortunately, they don’t know what delete to use therefore they use delete. That’s why for each smart pointer we have a smart array counterpart. std::shared_ptr uses delete std::shared_array uses delete[] So, your line std :: unique_ptr <int> x (new int [2]); actually causes undefined behavior. Incidentally, if you write std :: unique_ptr<int[]> p(new int[2]); ^^ … Read more
template<class Y> explicit shared_ptr(Y* p); [util.smartptr.shared.const]/6 Throws: bad_alloc, or an implementation-defined exception when a resource other than memory could not be obtained. [util.smartptr.shared.const]/7 Exception safety: If an exception is thrown, delete p is called. So no, no memory leak.
Indeed you are doing it wrong. If you have simple inheritance, just inherit from enable_shared_from this in the base class, and derived class get it for free. (of course you’ll need to downcast the result) If you have multiple inheritance (like it seems), you must use the trick described here and also here : /* … Read more
The advantage of passing the shared_ptr by const& is that the reference count doesn’t have to be increased and then decreased. Because these operations have to be thread-safe, they can be expensive. You are quite right that there is a risk that you can have a chain of passes by reference that later invalidates the … Read more
enable_shared_from_this<manager<Policy>> is a “dependent base” (it’s a base class whose type depends on a template parameter, in this case Policy) so the rules of C++ say that unqualified name lookup doesn’t look in there, you need to say this->shared_from_this() or std::enable_shared_from_this<manage<Policy>>::shared_from_this() to find the member from the dependent base. See http://gcc.gnu.org/wiki/VerboseDiagnostics#dependent_base for more detail and … Read more