shared-ptr

What is the technical problem with std::shared_ptr::unique() that is the reason for its deprecation in C++17? According to cppreference.com , std::shared_ptr::unique() is deprecated in C++17 as this function is deprecated as of C++17 because use_count is only an approximation in multi-threaded environment. I understand this to be true for use_count() > 1 : While I'm holding a reference to it, someone else might simultaneously let go of his or create a new copy. But if use_count() returns 1 (which is what I'm interested in when calling unique() ) then there is no other thread that could change

In the following code, while ( !Ref.expired() ); is joyfully optimized into an infinite loop. If the line of code is changed to while ( !Ref.lock() ); . everything works as expected. So two questions really: 1) How can the compiler optimize away expired when std::weak_ptr::expired() accesses a memory-fenced counter? 2) Is Ref.lock() actually safe, or could this too be optimized away? Sample code below. #include <iostream> #include <memory> #include <thread> #include <chrono> class A { public: A() { m_SomePtr = std::make_shared<bool>( false ); } virtual ~A() { std::weak_ptr<bool> Ref = m

I have seen that a useful way to write a clone method that returns a boost::shared_ptr is to do class A { public: shared_ptr<A> Clone() const { return(shared_ptr<A>(CloneImpl())); } protected: virtual A* CloneImpl() const { return(new A(*this)); } }; class B : public A { public: shared_ptr<B> Clone() const { return(shared_ptr<B>(CloneImpl())); } protected: virtual B* CloneImpl() const { return(new B(*this)); } }; This allows the use of covariance with the regular pointer while still wrapping it in the safety of a smart pointer. My problem is my class B needs to inherit from boost::enable

Does anybody know of a fully thread-safe shared_ptr implementation? E.g. boost implementation of shared_ptr is thread-safe for the targets (refcounting) and also safe for simultaneous shared_ptr instance reads, but not writes or for read/write. (see Boost docs , examples 3, 4 and 5). Is there a shared_ptr implementation that is fully thread-safe for shared_ptr instances? Strange that boost docs say that: shared_ptr objects offer the same level of thread safety as built-in types. But if you compare an ordinary pointer (built-in type) to smart_ptr , then simultaneous write of an ordinary pointer

I have a quick question regarding the use of typedefs for lengthy templates. The crux: I've found myself in something of a pickle—there doesn't seem to be a good place to place typedefs except local to client functions. While there are similar SO questions (see here for example), none seem to address this exactly. Please note that this question doesn't address whether typedefs are desirable in what follows—I've tried to simplify things for expository purposes. My problem has arisen while working with boost::shared_ptr<T> . Basically, I want to do the following: #include <boost/shared_ptr.hpp>

In C++11 std::shared_ptr has four constructors which can be passed deleter objects d of type D . The signatures of these constructors are the following: template<class Y, class D> shared_ptr(Y * p, D d); template<class Y, class D, class A> shared_ptr(Y * p, D d, A a); template <class D> shared_ptr(nullptr_t p, D d); template <class D, class A> shared_ptr(nullptr_t p, D d, A a); The standard requires in [util.smartptr.shared.const] type D to be CopyConstructible. Why is this needed? If shared_ptr makes copies of d then which of these deleters might get called? Wouldn't it possible for a shared

I came across this SO question and reading it over eventually led me to look at boost::detail::spinlock_pool . The purpose of boost::detail::spinlock_pool is to reduce potential contention for a global spinlock by choosing from an array of spinlock s by hashing over the shared_ptr 's address. This seems like a reasonable solution but there seems to be a problem with the current (Boost v1.49) version's implementation. spinlock_pool manages a statically allocated array of 41 spinlock instances. It appears that sizeof(spinlock)==4 for the platforms I looked at -- which means on, say x64 with 64

boost::shared_ptr has an unusual constructor template<class Y> shared_ptr(shared_ptr<Y> const & r, T * p); and I am a little puzzled as to what this would be useful for. Basically it shares ownership with r , but .get() will return p . not r.get() ! This means you can do something like this: int main() { boost::shared_ptr<int> x(new int); boost::shared_ptr<int> y(x, new int); std::cout << x.get() << std::endl; std::cout << y.get() << std::endl; std::cout << x.use_count() << std::endl; std::cout << y.use_count() << std::endl; } And you will get this: 0x8c66008 0x8c66030 2 2 Note that the

I've come to C++11 from an Objective-C background, and one thing I'm struggling to come to terms with is the different capturing semantics of C++11 lambdas vs Objective-C "blocks". (See here for a comparison). In Objective-C, like C++, the self / this pointer is implicitly captured if you refer to a member variable. But because all objects in Objective-C are effectively "shared pointers", to use the C++ terminology, you can do this: doSomethingAsynchronously(^{ someMember_ = 42; }); ... and you're guaranteed that the object whose member you're accessing will be alive when the block executes.

I have working in large application which contain c and cpp. The all files saved as cpp extension but the code is written in c- style. I mean it is define structure rather than class allocate memory through malloc and realloc and calloc.In recent They have installed boost library So I am planning to use into my existing code base So I have some following question. Can I use std::shared_ptr with malloc and free. If yes, can anyone point out me sample code base? Will it impact any functionality if I create std::shared_ptr in my application and pass this pointer to another function, which uses