   Question about resizing a std::vector
  I know that when a std::vector resizes it has to destroy the old array data and create a new array, and to do so it calls the destructor and then copy-constructor of each element. But i'm not clear on what happens with pointers. If you have a vector of objects std::vector<Object> vec it would call each Object's destructor but what about std::vector<Object*> vec? Because this is how i store most of my objects and in a few places i destroy all elements by calling aVector.erase() or even doing nothing and letting the std::vector's destructor clean up when the vector is destroyed (most likely when the object it is a member of is deleted). So is this good practice, or even correct?One reason why i am asking this is because i am thinking about how to manage objects in my physics system. I posted here about it but unfortunately got no response.I guess i could look it up but as always you guys here are always so much more helpful [smile]thanks   
  If you have a vector of pointers it will just move the pointers around in memory. It won't do anything to the things that are pointed to. If you need the things that are pointed to to be destroyed, you need to call delete yourself.   ;  Ah, ok. So if i want to delete all elements i need to do:for (...) {    delete each;}Then how does the vector know what are pointers and what are actual objects? I'm just curious.thanks for the quick response   ;  It doesn't. It always copies and destroys the type stored inside the vector. However, the destructor for a pointer is a no-op; when a pointer is destroyed nothing happens to the object that the pointer refers to. This is the case for all non-smart pointers.   ;  The std::vector<Object *> destructor destroy it's elements, which are pointers. That effectively does nothing. You have to delete them manually or use boost::ptr_vector<Object>.It works like std::vector<OBject> with the exception that elements are stored internally as pointers and you have to create them manually.boost::ptr_vector<Object> v;v.push_back(new Object());;  A container of pointers with a manual delete in a loop is not exception-safe.Use one of the many solutions with smart pointers or dedicated containers.   ;Quote:Original post by loufoqueA container of pointers with a manual delete in a loop is not exception-safe.Why? Destructors aren't supposed to throw exceptions, so there shouldn't be any problem.   ;  I think he's referring to this situation:void Foo(){   vector<bar*> vec;   // populate vec here   ThisFunctionThrowsAnException();   for (vector<bar*>::iterator iter = vec.begin(); iter != vec.end(); ++iter) delete *iter;   vec.clear();}This is indeed not exception-safe; when the function throws, the vector is cleared in its own destructor, but the deletes are never executed.A simple solution would be something like this:template<typename T> struct AutoDeleteVector{   vector<T*> v;   ~AutoDeleteVector()   { for (vector<T*>::iterator iter = vec.begin(); iter != vec.end(); ++iter)    delete *iter;   }}AutoDeleteVector<foo> vec;vec.v.front()->DoSomething();;Quote:Original post by DevFredQuote:Original post by loufoqueA container of pointers with a manual delete in a loop is not exception-safe.Why? Destructors aren't supposed to throw exceptions, so there shouldn't be any problem.Well, not where you clear the vector in the destructor, no. But there are sure to be other parts of the code where objects in the vector might be removed, and each of these is going to need to be carefully written to avoid errors and be made exception safe.class Example{   ~Example(); // exception safe   void modifyVectorMaybeRemoveSomeObjects(); // is this though?private:   std::vector<Object *> objects;};Not to mention other errors unrelated to exceptions, e.g. the class above does not obey the rule of three. Having smart pointers or a smart vector can improve the situation a bit.   ;  rip-off raises a very important point here - one that underscores why containers like boost's pointer vector exist, and why smart pointers are your friends.Incidentally, the code fragment I posted earlier does nothing to solve these issues - it is only going to solve the sudden-unexpected-destruction problem. So personally, I wouldn't use it [grin]   