Jump to content
  • Advertisement
BirdGB

use of shared_ptr

Recommended Posts

Hi,

   I have been trying to use shared_ptr but after searching the net and reading example, I still don't understand how to use std::shared_ptr?

   Say, I have a class -

class foo
{
   public:
      foo();
      ~foo();
      void init();
}

   Now I want to use this in another class -

class useme
{
   public:
      useme();
      ~useme();
     void init();
   private:
      std::shared_ptr<foo> f1;
      std::list<shared_ptr<foo>> foolist;
}

   In init() method, how do I create the f1 and push_back it into foolist?

I tried like this -

foolist.push_back(std::shared_ptr<foo>(new foo()));

or

f1 = std::make_shared<foo>(new foo());

foolist.push_back(f1);

Any help will be appreciated. Thanks in advance.

Edited by Kylotan
formatted code

Share this post


Link to post
Share on other sites
Advertisement

The parameters for std::make_shared are the arguments for the template type's constructor, you should not be using new.

Edited by cmac

Share this post


Link to post
Share on other sites

Ok, to delete the container I only need to clear foolist, like - foolist.clear()  and the f1 will also be cleared automaticaly? Or I should make the f1 null, like - f1 = 0? Or I should iterate through the list and delete each element before closing the application?

Edited by BirdGB

Share this post


Link to post
Share on other sites

It's not clear why you have both f1 and foolist - if you're creating a new object and storing it, you usually only need to store it in one place.

Once you have your shared_ptr to whatever, once all the copies of that pointer are deleted, the object is deleted as well - so you never have to call `delete` on it directly.

If your list is cleared or destroyed, all the shared_ptrs in it are also destroyed, and so if those were the last ones to refer to your object, the object gets deleted properly. You don't have to clear shared_ptr or set them to null before destroying them.

Share this post


Link to post
Share on other sites

f1 is the pointer for the current object selected and the foolist is the container of the all objects available. So I was a bit confused whether to delete or set null the f1 pointer after deleting or clearing the foolist.

Share this post


Link to post
Share on other sites

shared_ptr implies ownership semantics over the pointer it contains. It makes sense, looking at your code, to maintain ownership within foolist. It doesn't make sense to also maintain ownership in f1.  The list can be said to 'own' the objects, but f1 is just an indicator, a place-marker, which probably has no controlling interest in the lifetime of an object. I would prefer to use a weak_ptr there instead.

Share this post


Link to post
Share on other sites

Ok, so I should change shared_ptr to weak_ptr? And yes, I don't want ownership in f1, that's why I decided to use shared_ptr. Because I was unsure that f1 was freed properly before closing the application. I am only clearing the foolist.

Share this post


Link to post
Share on other sites

Any allocated memory in a shared_ptr in your example, f1, is freed automatically when the class goes out of scope.

Share this post


Link to post
Share on other sites

Yes, I would make f1 a weak_ptr. Keep the ones stored in foolist as shared, then whenever an object is selected just set f1 from the shared_ptr in foolist. Before using f1, you can call expired() to see if it is valid. If the object stored in foolist was removed/deleted and all shared_ptr copies of it are gone, then expired() will return true meaning the object is gone. You can call lock() on a weak_ptr to obtain a shared_ptr from the weak_ptr. As long as the shared_ptr object created by lock() is around, then the object will not be deleted, even if it is removed from foolist. As soon as all shared_ptrs to an object are gone, including any obtained from calling lock() on the weak_ptr, then the object is automatically deleted, and any weak_ptr that point to it will return expired.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!