weak-ptr | 易学教程

C++: Replace raw pointers with shared and weak ptr

阅读更多关于 C++: Replace raw pointers with shared and weak ptr

问题 I'm facing a design issue in my program. I have to manage Nodes object which are part of a root ChainDescriptor. Basically it looks like the following: class ChainDescriptor { public: ~ChainDescriptor() { //delete the nodes in nodes... } void addNode(Node *); Node * getNode(); const std::list<Node *>& getNodes() const; std::list<Node *> m_nodes; }; class Node { public: Node(Node *parent); void addChild(Node *node); Node * getChild(const std::string& nodeName); private: Node * m_parent; std:

C++: Replace raw pointers with shared and weak ptr

阅读更多关于 C++: Replace raw pointers with shared and weak ptr

How does a weak_ptr know that the shared resources has expired?

阅读更多关于 How does a weak_ptr know that the shared resources has expired?

问题 Considering the following code: #include <memory> #include <iostream> using namespace std; struct MySharedStruct { int i; }; void print_value_of_i(weak_ptr<MySharedStruct> weakPtr) { if (shared_ptr<MySharedStruct> sp = weakPtr.lock()) { cout << "Value of i = " << sp->i << endl; } else { cout << "Resource has expired"; } } int main() { shared_ptr<MySharedStruct> sharedPtr(new MySharedStruct() ); sharedPtr->i = 5; weak_ptr<MySharedStruct> weakPtr; weakPtr = sharedPtr; print_value_of_i(weakPtr);

Is it guaranteed that weak_ptr will expire when shared_ptr is reset to the same address that contains?

阅读更多关于 Is it guaranteed that weak_ptr will expire when shared_ptr is reset to the same address that contains?

问题 Is it guaranteed that weak_ptr will expire when shared_ptr is reset to the same address that contains? #include <cassert> #include <memory> int main() { int* i = new int(0); std::shared_ptr<int> si( i ); std::weak_ptr<int> wi = si; si.reset( i ); assert( wi.expired() ); // wi.expired() == true (GCC 4.7) } Or is this the case when the value of wi.expired() is not defined? EDIT: I now modify the question little bit: Is it guaranteed that weak_ptr will expire when shared_ptr is reset to the same

How to reduce the implementation code of lots of wrapper classes?

阅读更多关于 How to reduce the implementation code of lots of wrapper classes?

问题 I am developing a library with some classes, let's call them C1, C2 and ... Cn . Each of these classes realize some interfaces, i.e. I1, I2, ... Im. (n > m). The relationship between objects in the library is complex and I have to provide some API for my library users to access these objects using smart pointers. After some discussions, I found that returning shared pointers to the library users is not a good idea, because in that case I cannot make sure that the object can be removed

Is there such thing as a weak_ptr that can't be locked (promoted to shared_ptr)? If not, why?

阅读更多关于 Is there such thing as a weak_ptr that can't be locked (promoted to shared_ptr)? If not, why?

问题 Maybe this question has been asked before, but I've never found a satisfactory answer. Also, for the purposes of simplicity assume I'm talking about a single-threaded application. So, what I've heard a number of times is that if you have an object that is non-owned and whose lifetime is guaranteed , you should reference it with a raw pointer. The object's owner would use a unique_ptr, and hand out raw pointers as necessary. But what if the object is non-owned , and the lifetime is not

Weak pointer to this in constructor

阅读更多关于 Weak pointer to this in constructor

问题 I understand it is not possible to obtain a shared_ptr by calling shared_from_this() from the constructor of a class, as the object is not yet constructed. Is it possible however to obtain a weak_ptr to the object from the constructor? Some boost forum posts discussing a "weak_from_raw()" method suggests that it may be possible. Edit: Boost form discussing weak_from_raw http://lists.boost.org/boost-users/2010/08/61541.php 回答1: I think what you're referencing is this. Which seems not to have

`weak_ptr::expired` behavior in the dtor of the object

阅读更多关于 `weak_ptr::expired` behavior in the dtor of the object

问题 Consider the following code: #include <iostream> #include <memory> using namespace std; class T; std::weak_ptr<T> wptr; class T { public: T() { } ~T() { std::cout << "in dtor" << std::endl; std::cout << (wptr.expired() ? "expired" : "not expired") << std::endl; } }; int main() { { auto ptr = std::make_shared<T>(); wptr = ptr; std::cout << (wptr.expired() ? "expired" : "not expired") << std::endl; } return 0; } In this code, I was trying to find out if weak_ptr s are expired in the objects

What is the cyclic dependency issue with shared_ptr?

阅读更多关于 What is the cyclic dependency issue with shared_ptr?

问题 I read about shared pointers and understood how to use. But I never understood the cyclic dependency problem with shared pointers and how weak pointers are going to fix those issues. Can any one please explain this problem clearly? 回答1: The problem isn't that complex. Let --> represent a shared pointer: The rest of the program --> object A --> object B ^ | \ | \ v object C So we've got ourselves a circular dependency with shared pointers. What's the reference count of each object? A: 2 B: 1 C

Is there such thing as a weak_ptr that can't be locked (promoted to shared_ptr)? If not, why?

阅读更多关于 Is there such thing as a weak_ptr that can't be locked (promoted to shared_ptr)? If not, why?

Maybe this question has been asked before, but I've never found a satisfactory answer. Also, for the purposes of simplicity assume I'm talking about a single-threaded application. So, what I've heard a number of times is that if you have an object that is non-owned and whose lifetime is guaranteed , you should reference it with a raw pointer. The object's owner would use a unique_ptr, and hand out raw pointers as necessary. But what if the object is non-owned , and the lifetime is not guaranteed ? Then you can use a weak_ptr, yes. But then anyone who is handed a weak_ptr could be naughty and