# Just use an array or use vector?

This topic is 4721 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hey all, I've ran into a situation where I don't really know whether it would be better speed wise (not that it would make any real significance in my case) to use a set size array or a vector. I've been using lists and vectors so much, I'm starting to realize I might be improperly using them, by using them in situations where they are really unneeded. Basically I have some objects that are being constantly created and destroyed but at one time there will never ever be more than 20 of these objects all at once. Is it better to just declare an array Object objects[20] then to be constantly pushing and popping objects on and off of a vector? Also these objects will always be deleted and added in a sequential order, so I know using a list would be a bad choice. Also on a sort of related note, if the objects I'm storing are not polymorphic is there any point in dynamically allocating them? They also won't be passed around to other functions so there wouldn't be any overhead in that sense by coping. I think I've gotten in a habit of allocating almost all objects on the heap, which probably isn't so good. Thanks for any help, suggestions.

##### Share on other sites
If you know that you'll only ever have 20 elements, then calling reserve(20) will allocate enough for 20 elements. After that, pushes are practically free because they'll never have to allocate additional memory.

CM

##### Share on other sites
The set-size array will likely be slightly faster and should use 4 bytes less memory ( plus any extra heap storage the vector allocates ).

On the other hand, the reabability you gain from using push_back and pop_back and such is likely a much greater concern initally than the minute speed difference. Note that you can .reserve(20) the vector to avoid unnessesary reallocations.

The vector is also simpler to extend in the future should you need more than 20 at some point. It can also be easier to debug since you can use a debug version of vector that will always check array bounds and such, which isn't possible with a plain array.

Also, you're probably right that not putting them on the heap individually is a better choice. ( I say individually since vector uses heap memory [assuming you used the default allocator]. ) Especially since keeping vectors or arrays of pointers to heap objects is a nightmare to make properly exception-safe.

##### Share on other sites
There is absolutely no difference between vectors and arrays when you compile in release mode in VS7. I profiled them both a while ago, and got very similar results - plus they compile to the same asm anyway.

As long as you aren't doing anything silly like resizing the vector all the time ( use reserve like CM said instead ), it'll be fine.

##### Share on other sites
Quote:
 Original post by me22Also, you're probably right that not putting them on the heap individually is a better choice. ( I say individually since vector uses heap memory [assuming you used the default allocator]. ) Especially since keeping vectors or arrays of pointers to heap objects is a nightmare to make properly exception-safe.

If that is meant to imply std::vector doesn't store elements in memory contiguously your completely mistaken, std::vector is guaranteed to store element in memory contiguously. std::vector seperates allocation/deallocation & construction/destruction for efficiency.

This is:

#include <vector>struct foo { int i; foo(int j): i(j) {} };int main() {   std::vector<foo> v;   v.reserve(10);   v.push_back(foo(30));};

is approximately equivalent to this:

#include <new>int main() {   foo* f = static_cast<foo*>(::operator new(sizeof(foo) * 10)); // allocates uninitialized memory only   ::new(&f[0]) foo(30); // in-place constructs only   //...   f[0].~foo(); // destroys only   ::operator delete(f); // deallocates only}

##### Share on other sites
if you can guarantee that 20 is all you need then I would use: Object objects[20] and write two inline functions push and pop which do what you expect.

Personally I use a vector where I would normally use a dynamic array but for a fixed size I dont use them, I expect other people do though so its not really a problem.

If its not speed critical then a vector might be better because its more flexible and increases readability.

##### Share on other sites
I tend to always use vectors where possible, it means I've got an easy way of avoiding fence-post errors as they're dynamically resizable.

Arrays have their uses, but I use vectors to store data. I use arrays for things like checking if a number has already been chosen (an array of booleans) and stuff like that.

My 2 cents.

##### Share on other sites
Quote:
 Original post by dmatterIf its not speed critical then a vector might be better because its more flexible and increases readability.

What does speed have to do with it? As I said, as long as you don't resize the vector, the speed is exactly the same as an array. Test it out yourself.

##### Share on other sites
I could take your word for it, but theres a nagging doubt about it being as fast as an array defined at compile time (also bearing in mind possible variations in vector implementations).
Actually if the vector is a data member then because a vector requires more space it incurs a small (very small however) overhead when copying the object.

I'm not trying to say vectors are bad or anything, I very much like them, but I choose to think of them as a dynamic array (well they are) so I use them where I would otherwise use a conventional dynamic array - which is most cases anyway :)

Either way it makes little difference I just choose to do things that way

##### Share on other sites
Heh, I'd use the vector [or perhaps even std::stack or std::queue if applicable]. Assumptions always change through the process of design, and re-design. The stack or queue [since it sounds like that's what you want] will allow you more flexibility in the future.

• 38
• 15
• 9
• 23
• 10