shared-ptr

问题 Given the following class based on containers of shared pointers, class Foo; class Bar { public: // ... const std::vector<boost::shared_ptr<const Foo> >& getFoos() const { return foos_; } private: std::vector<boost::shared_ptr<Foo> > foos_; }; which will not compile because invalid initialization of reference of type ‘const std::vector<boost::shared_ptr<const Foo>, std::allocator<boost::shared_ptr<const Foo> > >&’ from expression of type ‘const std::vector<boost::shared_ptr<Foo>, std:

问题 Does there exist a collection, that is aware of shared_ptr internals, and avoids regular copying of stored shared_ptr elements in favor of just copying their internal weak pointer? This implicitly means, that no constructor/destructor calls will be done and that there will be no manipulation of shared_ptrs' reference counters. 回答1: that is aware of shared_ptr internals, That should answer your question right there. To be aware of the internals, such a collection would almost certainly have to

问题 I get exception: std::bad_weak_ptr when I do this->shared_from_this() template<typename TChar> class painter_record_t { ....... private: std::shared_ptr<i_painter_t> _owner; } Here I want to set the "problem" object in constructor: template<typename TChar> class stream_record_t : public painter_record_t<TChar> { public: stream_record_t(std::shared_ptr<i_painter_t> owner) : painter_record_t(owner) { //... } } I have the base class: class i_painter_t { public: virtual std::unique_ptr<painter

问题 I have a header file foo.h like this (unrelated stuff omitted): #pragma once #include <memory> class Bar; struct Foo { std::shared_ptr<Bar> getBar(); std::shared_ptr<const Bar> getBar() const { return const_cast<Foo*>(this)->getBar(); } }; The non-const overload of getBar() is implemented in a .cpp file, which also sees the full definition of Bar . When foo.h is included from another file (which does not see the definition of Bar ), VS 2010 is giving me a warning like this: warning C4150:

问题 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

问题 problem is simple: We have a class that has members a,b,c,d... We want to be able to quickly search(key being value of one member) and update class list with new value by providing current value for a or b or c ... I thought about having a bunch of std::map<decltype(MyClass.a/*b,c,d*/),shared_ptr<MyClass>> . 1) Is that a good idea? 2) Is boost multi index superior to this handcrafted solution in every way? PS SQL is out of the question for simplicity/perf reasons. 回答1: Boost MultiIndex may

问题 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

问题 Question for the C++ experts. We all know that calling shared_from_this() in the class constructor will result in a bad_weak_ptr exception, because no shared_ptr to the instance has been created yet. As a work-around for that, I came up with this trick: class MyClass : public std::enable_shared_from_this<MyClass> { public: MyClass() {} MyClass( const MyClass& parent ) { // Create a temporary shared pointer with a null-deleter // to prevent the instance from being destroyed when it // goes out

问题 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

问题 I have an STL container whose element type is const std::shared_ptr<MyClass> . I want to supply two iterator types to the user: MyContainer::iterator typedefed as std::vector<const std::shared_ptr<MyClass>>::iterator (which should be the same type as std::vector<const std::shared_ptr<const MyClass>>::const_iterator MyContainer::const_iterator typedefed as std::vector<const std::shared_ptr<const MyClass>>::iterator (which should be the same type as std::vector<const std::shared_ptr<const