vector pointer vs vector object

[Kasya]

Hello,
Whats the difference between std::vector<Obj ect> obj; and std::vector<Obj ect *> obj;. And which is recommended, preferred?

Thanks,
Kasya

[weaknessforcats]

Whats the difference between std::vector<Obj ect> obj; and std::vector<Obj ect *> obj;. And which is recommended, preferred?

std::vector<Obj ect> obj creates obj on the stack and it will contain Object variables. Where is actual vector is located is up to your implementation of vector but it is almost certainly on the heap.

std::vector<Obj ect *> obj creates obj on the stack and it will contain pointers to Object variables. The disdadvantage here is that you must insure that all the pointers in the vector are valid for the lifeof the vector. Another disadvantage is that vector will move things around as the array expands an contracts and this may result in a delete of one of those pointers which will also delete the Object. You should use a vector of handles to Object (see the Bridge design pattern) rather than naked pointers.

You must also ask yourself if the Objects or the Object* are unique. If not, then to change an Object in a vector<Object> you will have to iterate the entire vector to find it. If ouy had a vector<Object*> you jusy change the Object and not worry about the vector.

I could go on but this should give you the idea.

You might get a copy of Effective STL by Scott Meyers.

[newb16]

Another disadvantage is that vector will move things around as the array expands an contracts and this may result in a delete of one of those pointers which will also delete the Object.

I find it doubtful. If vector<T> uses some pointer T* t in its internal representation and calls t=new T; and delete t; for T=Object, it allocates and deletes object. If T=Object* t itself is Object**, and these operations create/delete pointer but not Object itself.

[weaknessforcats]

I find it doubtful. If vector<T> uses some pointer T* t in its internal representation and calls t=new T; and delete t; for T=Object, it allocates and deletes object. If T=Object* t itself is Object**, and these operations create/delete pointer but not Object itself.

No need to wonder. Just look in your vector template and see how it is implemented.

[newb16]

No need to wonder. Just look in your vector template and see how it is implemented.

It is implemented in a bunch of header files with no comments whatsoever, so it is no good.
Is such behavior ( vector<T*> is free to delete T whenever it finds it feasible) documented in the standard? Or maybe some another stl reference states it?

[Banfa]

Another disadvantage is that vector will move things around as the array expands an contracts and this may result in a delete of one of those pointers which will also delete the Object.

My understanding of the dangers of vectors is opposite to this, if you have a vector of pointers, vector<TYPE *> as you resize (reduce in size) the vector the pointers are destroyed but the object they point to is not. You have to handle the memory pointed to yourself (hence your suggestion to use a handle template).

A disadvantage of vector<TYPE> that you have not mentioned is that because of the vectors need to hold its memory contiguously as it would be held if it were an actual array if you insert data anywhere but at the end of the vector or if inserting at the end of an vector causes the array to need a larger capacity, or any other operation that causes the vector to need a larger capacity the contents of the array need to be copied around the array. If TYPE is large this can have an effect on performance. If TYPE has pointers to allocated memory in it and no copy constructor/assignment operator this can be disastrous.

And as an aside you quite often see it said that you can use a vector of vectors as a 2 dimensional array. However where as vectors holds its memory in the same layout as a 1 dimensional array a vector of vectors does not hold its memory in the same layout as a 2 dimensional array. This point would only be relevant if you where interfacing with some legacy code that still used arrays rather than vectors and I am not saying you couldn't program you way round it.

My point is that it is good to be aware of how the various containers hold their memory and what you can rely on and what you shouldn't rely on.

[pootle]

My understanding of the dangers of vectors is opposite to this, if you have a vector of pointers, vector<TYPE *> as you resize (reduce in size) the vector the pointers are destroyed but the object they point to is not. You have to handle the memory pointed to yourself (hence your suggestion to use a handle template).

Exactly. You are responsible for all de-allocation when the template is a pointer.

BTW, there is also another reason to use pointers in a container - to utilise polymorphic types.

My point is that it is good to be aware of how the various containers hold their memory and what you can rely on and what you shouldn't rely on.

This is somehow true, but you cannot make some assumption about how memory is held, except in the most general way (such as vector being contiguous) - it is implementation dependant - you can only rely on what is specified by standards. You can also control allocation because every standard library container takes a custom allocator as a template arugment, and this permits you control / tune the allocation / deallocation of the container.

[Banfa]

This is somehow true, but you cannot make some assumption about how memory is held, except in the most general way (such as vector being contiguous) - it is implementation dependant - you can only rely on what is specified by standards.

Exactly you should only rely on the behaviour that the standard says a conforming implementation exhibits and not on anything else.

I have noticed a tendency in programmers (new and old in some cases) to assume that all platforms perform in the same way the one they are working on performs rather than knowing the standards and programming to that.