Deleting vector of pointers

Question

I need to create pointers of instances of a class, and the program do not know at compilation time how many pointers I will create. For deletion, I was considering storing the pointers in a vector, and then deleting them one by one. Would the use of smart pointers a cleaner way to go ? And if one does not want to use smart pointers, would this use of vector be considered clean ?

Minimum code:

#include <vector>
using namespace std;

class Foo {
public:
    Foo();
};
Foo::Foo(){}
void createFooVector(int nb, std::vector<Foo*> &v){
    for(int i=0;i<nb;i++){
        Foo* f = new Foo();
        v.push_back(f);
    }
}
int main(int argc, char *argv[]){
    std::vector<Foo*> v;
    createFooVector(5,v); 
    while (!v.empty()){
        Foo* f = v.back();
        v.pop_back();
        delete f;
    }
}

Solution 1

I would suggest either using a boost::pointer_vector, an std::vector<std::unique_ptr<Foo>>, or roll out your own Foo manager class which holds a vector<Foo*> and takes care of deletions in the constructor (you should see this as the "expert" solution, and only attempt it if you fully understand exception safety). You don't want to be doing the deletion manually, that can easily lead to errors.

Solution 2

Your code is fine. However, using smart pointers should be the preferred choice (less code to write and much fewer opportunities for memory bugs).

Solution 3

Would the use of smart pointers a cleaner way to go ?

Yes.

And if one does not want to use smart pointers, would this use of vector be considered clean ?

I have no ideas, why someone doesn't want use smart pointers in C++, if it's not homework... But, I think, it's better to use something like boost::pointer_containers in this case.

Solution 4

If you're not using classes derived from Foo, and Foo is relatively inexpensive to copy construct, just use vector<Foo>.

If your compiler supports move semantics there shouldn't be an issue.

View more solutions

Comments

[Matthieu M.]

I would not recommend the manager solution though; chances are the OP won't make it safe enough with regard to exceptions...

[Matthieu M.]

Whether it's expensive to construct matters little, I think you were thinking about being expensive to copy. With move semantics though, it might not be much of an issue... and if worst come to worst, one can use the new emplace_back member.

[Peter Wood]

@Matthieu Yes, move semantics change everything. To clarify what I meant, to push a value into a vector, you have to construct it then the vector copy constructs another. I meant to indicate the need to take into consideration the construction of values in general. I will update to say copy construct.

[juanchopanza]

@MatthieuM. Very true. I added a warning about that.