shared-ptr | 易学教程

question on assignment with boost::shared_ptr (vs. the reset() function)

阅读更多关于 question on assignment with boost::shared_ptr (vs. the reset() function)

问题 Sorry if this is explicitly answered somewhere, but I'm a little confused by the boost documentation and articles I've read online. I see that I can use the reset() function to release the memory within a shared_ptr (assuming the reference count goes to zero), e.g., shared_ptr<int> x(new int(0)); x.reset(new int(1)); This, I believe would result in the creation of two integer objects, and by the end of these two lines the integer equaling zero would be deleted from memory. But, what if I use

Forward declarations and shared_ptr

阅读更多关于 Forward declarations and shared_ptr

I'm trying to refactor my code so that I use forward declarations instead of including lots of headers. I'm new to this and have a question regarding boost::shared_ptr. Say I have the following interface: #ifndef I_STARTER_H_ #define I_STARTER_H_ #include <boost/shared_ptr.hpp> class IStarter { public: virtual ~IStarter() {}; virtual operator()() = 0; }; typedef boost::shared_ptr<IStarter> IStarterPtr; #endif I then have a function in another class which takes an IStarterPtr object as argument, say: virtual void addStarter(IStarterPtr starter) { _starter = starter; } ... IStarterPtr _starter;

shared, weak and lazy pointers in C++

阅读更多关于 shared, weak and lazy pointers in C++

问题 Is anyone aware of an implementation of shared_ptr and weak_ptr together with a lazy initialization partner? The requirements of the classes were: A lazy_ptr class that allows a client to construct the object later (if at all), without needing the constructor implementation A weak_lazy_ptr class that has three possible states: not yet constructed (won't lock to a shared_ptr ), constructed (will lock to a shared_ptr ) and destroyed (won't lock to a shared_ptr ) I created some classes that didn

Is an empty aliasing shared_ptr a good alternative to a no-op deleting shared_ptr?

阅读更多关于 Is an empty aliasing shared_ptr a good alternative to a no-op deleting shared_ptr?

Sometimes I need shared_ptr instances that have a no-op deleter, because an API expects a shared_ptr instance that it wants to store for a limited time but I am given a raw pointer that I am not allowed to own for a time larger than what I am running for. For this case, I have been using a no-op deleter, such as [](const void *){} , but today I found that there's another alternative to that, using (or abusing?) the aliasing constructor of shared_ptr : void f(ExpectedClass *ec) { std::shared_ptr<ExpectedClass> p(std::shared_ptr<void>(), ec); assert(p.use_count() == 0 && p.get() != nullptr);

Downcasting shared pointer to derived class with additional functionality - is this safe?

阅读更多关于 Downcasting shared pointer to derived class with additional functionality - is this safe?

问题 Consider the following outline: class Base { /* ... */ }; class Derived : public Base { public: void AdditionalFunctionality(int i){ /* ... */ } }; typedef std::shared_ptr<Base> pBase; typedef std::shared_ptr<Derived> pDerived; int main(void) { std::vector<pBase> v; v.push_back(pBase(new Derived())); pDerived p1( std::dynamic_pointer_cast<Derived>(v[0]) ); /* Copy */ pDerived p2 = std::dynamic_pointer_cast<Derived>(v[0]); /* Assignment */ p1->AdditionalFunctionality(1); p2-

boost shared_ptr: difference between operator= and reset?

阅读更多关于 boost shared_ptr: difference between operator= and reset?

Are there any differences between the two pieces of code below? Is any of them preferable to the other? operator= boost::shared_ptr<Blah> foo; // foo.ptr should be NULL foo = boost::shared_ptr<Blah>(new Blah()); // Involves creation and copy of a shared_ptr? reset boost::shared_ptr<Blah> foo; // foo.ptr should be NULL foo.reset(new Blah()); // foo.ptr should point now to a new Blah object Note: I need to define the shared_ptr and then set it in a different line because I'm using it in a piece of code like: boost::shared_ptr<Blah> foo; try { foo.reset... } foo... operator= assigns a shared_ptr

How std::enable_shared_from_this::shared_from_this works

阅读更多关于 How std::enable_shared_from_this::shared_from_this works

问题 I just cannot understand how std::enable_shared_from_this::shared_from_this returns a shared pinter that shared ownership with existing pointer. In other words you do this: std::shared_ptr<Foo> getFoo() { return shared_from_this(); } So when you call getFoo how does exactly it get what is the other shared_ptr to share the ownership with and not to create a separate shared_ptr that owns the same this . I need to understand this to be able to understand how to create shared_ptr from some object

how boost::~shared_ptr works?

阅读更多关于 how boost::~shared_ptr works?

when reading "Beyond the C++ Standard Library: An Introduction to Boost " ,I got a very interesting example: class A { public: virtual void sing()=0; protected: virtual ~A() {}; }; class B : public A { public: virtual void sing( ) { std::cout << "Do re mi fa so la"<<std::endl;; } }; and I do some testing: int main() { //1 std::auto_ptr<A> a(new B); //will not compile ,error: ‘virtual A::~A()’ is protected //2 A *pa = new B; delete pa; //will not compile ,error: ‘virtual A::~A()’ is protected delete (dynamic_cast<B*>(pa)); //ok //3 boost::shared_ptr<A> a(new B);//ok } what I am very curious

How do I implement polymorphism with std::shared_ptr?

阅读更多关于 How do I implement polymorphism with std::shared_ptr?

I have seen some of the other questions on this topic, but have still not found the answer - I guess I'm missing something: I defined two simple test classes: class TestBase { public: TestBase ( ) { }; ~ TestBase ( ) { }; protected: inline virtual int getInt ( ) { return 0; } }; class TestDerived : public TestBase { protected: inline int getInt ( ) override { return 1; } }; I declared typedefs to simplify their usage with std::shared_ptr: typedef std::shared_ptr<TestBase> spBase; typedef std::shared_ptr<TestDerived> spDerived; Problem: I cannot compile code to use these shared_ptr declarations

Why are two raw pointers to the managed object needed in std::shared_ptr implementation?

阅读更多关于 Why are two raw pointers to the managed object needed in std::shared_ptr implementation?

Here's a quote from cppreference's implementation note section of std::shared_ptr , which mentions that there are two different pointers(as shown in bold) : the one that can be returned by get() , and the one holding the actual data within the control block. In a typical implementation, std::shared_ptr holds only two pointers: the stored pointer (one returned by get() ) a pointer to control block The control block is a dynamically-allocated object that holds: either a pointer to the managed object or the managed object itself the deleter (type-erased) the allocator (type-erased) the number of