是使用std :: vector <T*> 不如std :: vector安全 <shared_ptr<T> &gt;？

Question

Say I have a simple data class:

struct Foo
{
   int iData;
   double dData;
};

I can create a container class that could be implemented as:

Version 1

struct Bar
{
   std::vector<std::shared_ptr<Foo>> fooData;
};

or as:

Version 2

struct Bar
{
   Bar(){}

   Bar(Bar const& copy)
   {
      for(auto fooPtr: copy.fooData)
      {
         fooData.push_back(new Foo(*fooPtr));
      }
   }

   ~Bar()
   {
      for(auto fooPtr: fooData)
      {
         delete fooPtr;
      }
   }

   Bar& operator=(Bar const& rhs)
   {
      if ( this == &rhs )
      {
         return *this;
      }

      for(auto fooPtr: fooData)
      {
         delete fooPtr;
      }
      fooPtr.clear();  // Had missed this in the original code.

      for(auto fooPtr: rhs.fooData)
      {
         fooData.push_back(new Foo(*fooPtr));
      }

      return *this;
   }

   std::vector<Foo*> fooData;
};

Granted that Version 1 is a lot simpler and easier to maintain than Version 2 . However, I have couple of questions that are orthogonal to that aspect of the code.

1. Is Version 1 safer than Version 2 from the point of view of dealing with exceptions?
2. If so, how?

Answer 1

Yes, the first option is more exception safe. Namely, your copy constructor has two memory leak sources, the copy assignment operator has a memory leak and is simply plain wrong. Additionally, the first option has move assignment and a move constructor by default, giving improved performance. (Even more performance if you used std::unique_ptr instead)

Bar(Bar const& copy)
{
   for(auto fooPtr: copy.fooData)
   {
      fooData.push_back(new Foo(*fooPtr));
      //what happens if `new Foo` throws a bad_alloc?
      //or if `Foo(const Foo&)` changes and now throws something?
      //or if `fooData.push_back` throws a bad_alloc?
      //anything you 'new'd is leaked.
   }
}

Bar& operator=(Bar const& rhs)
{
   if ( this == &rhs )
      return *this;

   for(auto fooPtr: fooData)
      delete fooPtr;
   //You forgot this line:
   //fooData.clear();

   for(auto fooPtr: rhs.fooData) //sharth notes you wrote copy.fooData but that's obvious
      fooData.push_back(new Foo(*fooPtr));
      //what happens if `fooData.push_back` throws a bad_alloc?
      //the `Foo` you just created is leaked.

   return *this;
}

Answer 2

Version 1 and version 2 have different semantics. If you copy a Bar object, version one gives shared access to the data, while version 2 does not. Version 2 also has a subtle memory leak; if new succeeds while push_back fails, the object leaks.

Why not use the even simpler std::vector<Foo> ? I'm not seeing any rationale for using pointers (either shared or raw) in this case. Value semantics are much, much easier to reason about than pointer semantics.