shared-ptr

What's your convention for typedef'ing shared_ptr?

◇◆丶佛笑我妖孽 提交于 2019-11-27 09:57:39
问题 I'm flip-flopping between naming conventions for typedef'ing the boost::shared_ptr template. For example: typedef boost::shared_ptr<Foo> FooPtr; Before settling on a convention, I'd like to see what others use. What is your convention? EDIT: To those nesting the typedef inside Foo, doesn't it bother you that Foo is now "aware" of how it will be passed around? It seems to break encapsulation. How about this: class Foo { public: typedef std::vector<Foo> Vector }; You wouldn't do this now, would

NULL pointer with boost::shared_ptr?

霸气de小男生 提交于 2019-11-27 09:44:28
问题 What's the equivalent to the following: std::vector<Foo*> vec; vec.push_back(NULL); when dealing with boost::shared_ptr ? Is it the following code? std::vector< boost::shared_ptr<Foo> > vec; vec.push_back(boost::shared_ptr<Foo>()); Note: I may push back a lot of such objects. Should I declare a global static nullPtr object somewhere? That way only one of them would have to be constructed: boost::shared_ptr<Foo> nullPtr; 回答1: Your suggestion (calling the shared_ptr<T> constructor with no

The cost of passing by shared_ptr

北城以北 提交于 2019-11-27 09:15:28
问题 I use std::tr1::shared_ptr extensively throughout my application. This includes passing objects in as function arguments. Consider the following: class Dataset {...} void f( shared_ptr< Dataset const > pds ) {...} void g( shared_ptr< Dataset const > pds ) {...} ... While passing a dataset object around via shared_ptr guarantees its existence inside f and g, the functions may be called millions of times, which causes a lot of shared_ptr objects being created and destroyed. Here's a snippet of

Difference between `const shared_ptr<T>` and `shared_ptr<const T>`?

守給你的承諾、 提交于 2019-11-27 09:03:03
问题 I'm writing an accessor method for a shared pointer in C++ that goes something like this: class Foo { public: return_type getBar() const { return m_bar; } private: boost::shared_ptr<Bar> m_bar; } So to support the const-ness of getBar() the return type should be a boost::shared_ptr that prevents modification of the Bar it points to. My guess is that shared_ptr<const Bar> is the type I want to return to do that, whereas const shared_ptr<Bar> would prevent reassignment of the pointer itself to

How to avoid memory leak with shared_ptr?

大兔子大兔子 提交于 2019-11-27 07:17:21
Consider the following code. using boost::shared_ptr; struct B; struct A{ ~A() { std::cout << "~A" << std::endl; } shared_ptr<B> b; }; struct B { ~B() { std::cout << "~B" << std::endl; } shared_ptr<A> a; }; int main() { shared_ptr<A> a (new A); shared_ptr<B> b (new B); a->b = b; b->a = a; return 0; } There is no output . No desctructor is called. Memory leak. I have always believed that the smart pointer helps avoid memory leaks. What should I do if I need cross-references in the classes? If you have circular references like this, one object should hold a weak_ptr to the other, not a shared

Using custom deleter with std::shared_ptr

主宰稳场 提交于 2019-11-27 07:13:14
I'm trying to work out how to use std::shared_ptr with a custom deleter. Specifically, I'm using it with SDL_Surface as: std::shared_ptr<SDL_Surface>(SDL_LoadBMP(....),SDL_FreeSurface); which compiles and runs fine. However, I would like to try out my own deleter and cannot work out how to do so. The documentation for SDL_FreeSurface is found here: http://sdl.beuc.net/sdl.wiki/SDL_FreeSurface in which I find the SDL_FreeSurface is declared as: void SDL_FreeSurface(SDL_Surface* surface); As a test, and going by that information, I tried the following function: void DeleteSurface(SDL_Surface*

Is boost shared_ptr <XXX> thread safe?

十年热恋 提交于 2019-11-27 06:58:30
I have a question about boost::shared_ptr<T> . There are lots of thread. using namespace boost; class CResource { // xxxxxx } class CResourceBase { public: void SetResource(shared_ptr<CResource> res) { m_Res = res; } shared_ptr<CResource> GetResource() { return m_Res; } private: shared_ptr<CResource> m_Res; } CResourceBase base; //---------------------------------------------- // Thread_A: while (true) { //... shared_ptr<CResource> nowResource = base.GetResource(); nowResource.doSomeThing(); //... } // Thread_B: shared_ptr<CResource> nowResource; base.SetResource(nowResource); //... Q1 If

enable_shared_from_this (c++0x): what am I doing wrong?

送分小仙女□ 提交于 2019-11-27 06:46:33
问题 I'm just toying around with the smart pointers in the upcoming new c++ standard. However I fail to grasp the usage of the shared_from_this function. Here is what I have: #include <iostream> #include <memory> class CVerboseBornAndDie2 : public std::enable_shared_from_this<CVerboseBornAndDie2> { public: std::string m_Name; CVerboseBornAndDie2(std::string name) : m_Name(name) { std::cout << m_Name << " (" << this << ") is born!" << std::endl; } virtual ~CVerboseBornAndDie2() { std::cout << m

std::shared_ptr of this

馋奶兔 提交于 2019-11-27 06:31:32
I am currently trying to learn how to use smart pointers. However while doing some experiments I discovered the following situation for which I could not find a satifying solution: Imagine you have an object of class A being parent of an object of class B (the child), but both should know each other: class A; class B; class A { public: void addChild(std::shared_ptr<B> child) { children->push_back(child); // How to do pass the pointer correctly? // child->setParent(this); // wrong // ^^^^ } private: std::list<std::shared_ptr<B>> children; }; class B { public: setParent(std::shared_ptr<A> parent

Passing shared_ptr<Derived> as shared_ptr<Base>

怎甘沉沦 提交于 2019-11-27 06:11:09
What is the best method to go about passing a shared_ptr of a derived type to a function that takes a shared_ptr of a base type? I generally pass shared_ptr s by reference to avoid a needless copy: int foo(const shared_ptr<bar>& ptr); but this doesn't work if I try to do something like int foo(const shared_ptr<Base>& ptr); ... shared_ptr<Derived> bar = make_shared<Derived>(); foo(bar); I could use foo(dynamic_pointer_cast<Base, Derived>(bar)); but this seems sub-optimal for two reasons: A dynamic_cast seems a bit excessive for a simple derived-to-base cast. As I understand it, dynamic_pointer