c++ - vector in destructor

No, I think that the vector will not delete those pointers for you, as that could cause problems.

Test it - put a line in the destructor of one of the objects so that it prints to a file when deleted, and run it - then you can find out if they are being deleted!

I would use an iterator to iterate through the vector deleting the pointers - google stl iterators.

or maybe just

for ( size_t n = 0; n < myvector->size(); ++n){    delete (*myvector)[n];}// if you know that they will all have been created// elsefor ( size_t n = 0; n < myvector->size(); ++n){    if ( (*myvector)[n] != 0 )         delete (*myvector)[n];}

Hope that helps
Mathmo

Since you are allocating the ControlObjects dynamically, you will have to deallocate them manually as well. An easy way to do this it to loop over your vector, deleting each element, before deleting the vector itself.

Easier, though, and often safer, would be to use some kind of smart pointer, like boost::shared_ptr, instead of plain pointers. You can have both your private vector and its elements as smart pointers. Then you will not have to do any deallocation yourself, since the destructors for the smart pointers will automatically take care of that.

Ok, thanks for your help! Much appreciated!

That static in there is a disaster. Why is the vector static?

If you need a global, declare the class as global.

The vector is static because i'll only need it once. It's not necessary that i put it there as i will only make one COList anyway. But i thought better safe than sorry?
Why is it a disaster?

Quote:

Original post by pundit The vector is static because i'll only need it once. It's not necessary that i put it there as i will only make one COList anyway. But i thought better safe than sorry? Why is it a disaster?

The obvious problem is that once sooner or later you're going to create two anyway. You risk introducing some annoying bugs.

And what exactly is the benefit?
Performance? Not at all. If anything, you'll get an extra cache miss on accessing the static version, because it won't be conveniently located on the stack along with all the other local variables. And at best, it won't make a difference.

How is this "better safe than sorry"?
Writing error-prone code with no benefits is not "better safe than sorry".

Okay, good to know that. Thanks!

Quote:

Original post by pundit The vector is static because i'll only need it once. It's not necessary that i put it there as i will only make one COList anyway. But i thought better safe than sorry? Why is it a disaster?

Since you aren't too sure about allocations and destructors, it's safe to say you've missed out on other C++ features as well.

Are you sure there will only be one? What happens if you by mistake pass the instance by value? Do you prevent the copying? Under which situations will C++ compiler automatically copy-construct or assign a new instance?

This remains a problem even if the array isn't static. This is why I added noncopyable.

Implementing rule-of-three with raw pointers this way is tricky at best. Once you have two instances, who cleans up? Each destructor will clean its own array, but delete shared objects.

If you do use static storage, then make accessors static as well. You're not gaining anything by mixing both. Then again, you also gain *nothing* by declaring everything static.

If there will only ever be one instance, then:

static COList myList;

does exactly that, without all the pitfalls of mixing concepts.

Once again, that was very interesting ^^ It's true, it doesn't have to be static as there isn't much use there. You've all been a great help!

By the way, you can call delete on a null (0) pointer, you don't need to check the pointers.