weak-ptr | 易学教程

Is there a weak_ptr equivalent to shared_from_this?

阅读更多关于 Is there a weak_ptr equivalent to shared_from_this?

问题 I have a class which I know will always be owned by a std::shared_ptr . However passing shared_ptr or even weak_ptr to functions and methods that don't need ownership or lifetime guarantees creates unnecessary overhead. To get around this I often pass raw pointers to functions. The class itself inherits from std::enable_shared_from_this so if the function needs to take ownership of the pointer it can use a method of the class to get a shared_ptr . This is all working beautifully. However

How to check if weak_ptr is empty (non-assigned)?

阅读更多关于 How to check if weak_ptr is empty (non-assigned)?

问题 Is there a way to distinguish between an assigned (possibly expired) weak_ptr and a non-assigned one. weak_ptr<int> w1; weak_ptr<int> w2 = ...; I understand the following checks for either non-assignment or expiry, but is there a (cheaper?) check for only non-assignment? if (!w.lock()) { /* either not assigned or expired */ } 回答1: You can use two calls to owner_before to check equality with a default constructed (empty) weak pointer: template <typename T> bool is_uninitialized(std::weak_ptr<T

How to check if weak_ptr is empty (non-assigned)?

阅读更多关于 How to check if weak_ptr is empty (non-assigned)?

Is there a way to distinguish between an assigned (possibly expired) weak_ptr and a non-assigned one. weak_ptr<int> w1; weak_ptr<int> w2 = ...; I understand the following checks for either non-assignment or expiry, but is there a (cheaper?) check for only non-assignment? if (!w.lock()) { /* either not assigned or expired */ } Holt You can use two calls to owner_before to check equality with a default constructed (empty) weak pointer: template <typename T> bool is_uninitialized(std::weak_ptr<T> const& weak) { using wt = std::weak_ptr<T>; return !weak.owner_before(wt{}) && !wt{}.owner_before

C++ weak_ptr creation performance

阅读更多关于 C++ weak_ptr creation performance

问题 I've read that creating or copying a std::shared_ptr involves some overhead (atomic increment of reference counter etc..). But what about creating a std::weak_ptr from it instead: Obj * obj = new Obj(); // fast Obj * o = obj; // slow std::shared_ptr<Obj> a(o); // slow std::shared_ptr<Obj> b(a); // slow ? std::weak_ptr<Obj> c(b); I was hoping in some faster performance, but i know that the shared pointer still have to increment the weak references counter.. So is this still as slow as copying

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 I think what you're referencing is this . Which seems not to have been merged to the boost release (may be wrong about that). From the boost docs : Frequently Asked Questions

why i can't cast nullptr to weak_ptr<>

阅读更多关于 why i can't cast nullptr to weak_ptr

问题 class MyClass { public: MyClass(std::weak_ptr<MyClass> parent){} } i want to do this: auto newInstance = std::make_shared<MyClass>(nullptr); or default value of weak_ptr argument is null, such as : void function(int arg,std::weak_ptr<MyClass> obj = nullptr); but, what i need is to do this instead: auto newInstance = std::make_shared<MyClass>(std::shared_ptr<MyClass>(nullptr)); why is that? 回答1: Because a weak_ptr in concept can only be constructed from another weak_ptr or shared_ptr . It just

What's the performance penalty of weak_ptr?

阅读更多关于 What's the performance penalty of weak_ptr?

问题 I'm currently designing a object structure for a game, and the most natural organization in my case became a tree. Being a great fan of smart pointers I use shared_ptr 's exclusively. However, in this case, the children in the tree will need access to it's parent (example -- beings on map need to be able to access map data -- ergo the data of their parents. The direction of owning is of course that a map owns it's beings, so holds shared pointers to them. To access the map data from within a

Smart pointers + cycles + “->”

阅读更多关于 Smart pointers + cycles + “->”

问题 Sometimes I'm really sure that I want to have circular dependence of pointers, and every object on cycle should be able to use his pointer (so it can't be weak_ptr). My question is: Does this mean that I have bad design? What if I want to implement graph? Can I use smart pointers? In graphs there are cycles, but with weak_ptr I can't use "->". What can I do? I read some articles, reference and topics on StackOverflow, but it looks like I still don't get smart pointers. Really, why doesn't

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

C++ weak_ptr creation performance

阅读更多关于 C++ weak_ptr creation performance

I've read that creating or copying a std::shared_ptr involves some overhead (atomic increment of reference counter etc..). But what about creating a std::weak_ptr from it instead: Obj * obj = new Obj(); // fast Obj * o = obj; // slow std::shared_ptr<Obj> a(o); // slow std::shared_ptr<Obj> b(a); // slow ? std::weak_ptr<Obj> c(b); I was hoping in some faster performance, but i know that the shared pointer still have to increment the weak references counter.. So is this still as slow as copying a shared_ptr into another? Howard Hinnant In addition to Alec's very interesting description of the