# Thread: Array and the vector

1. ## Array and the vector

Hi, I recently read in a book i have that it is no good learning about arrays, and stick with and always use vectors. I know how to use both very well, and in general use vectors over arrays anyeay.

My question is this:

Why would people have to or want to learn about C-style arrays

eg:
Code:
`int num[10]={1,2,3,4 ect.. };[`
When vectors can do all the above can and is faster and has more capabilitys for sorting through a sequence like iterators?

Many books teach arrays and vectors, but I think they should stick with vectors and use arrays as an side learning subject. That is only my view mind.

2. vectors are dynamic containers. A static array is often more efficient than a vector because of this. Also, there are some things a vector cannot do, like the initialization you showed in your example (although that might be available in the next standard). Finally, an array can be sorted just as easily as a vector can.

So in the occasional situations when one needs the ultimate efficiency, an array is obviously the better choice. You might not run into these situations very often, which is why you are told to use vectors instead of arrays. But other programmers might be in different situations where using an array is the best solution.

Learning about arrays is a good idea regardless of whether you use them specifically instead of vectors or not. They are a data structure and understanding of arrays and how they work can be very beneficial to your understanding of what you are programming.

3. Thanks daved. That was just the answer I was looking for.

4. Are vectors really faster than arrays? (or does efficiency mean speed?)

5. Originally Posted by Clyde
Are vectors really faster than arrays? (or does efficiency mean speed?)
Yes. Arrays are just a simple block of memory, so finding the right spot is a lot faster than something with dynamic allocation, eg. linked lists (where you have to traverse through each node), or vectors.

6. There's no reason arrays would be necessarily faster than vectors, except in startup time of the program. The expression v[i] can be compiled down to the exact same instructions no matter whether v is a T* or a vector<T>. Arrays can use one or two pointers' less memory if you don't want to grow them or if you have their size hard-coded, of course.

7. The power that vectors provide far outweighs any performance issues they may create...if any.

With my old space game I fired off 5000 lasers, tracked them per frame, render them in brute force with no culling and did all of this on an old GeForce 3 64MB card at well over 120 FPS with no vsync.

I doubt vectors are going to cause any major problems unless you are deleting and inserting multiple times per cycle or frame.

I use vectors for nearly all of my game resource managers and they work like a charm. Currently I'm getting over 900 FPS so I have plenty of frames there to work with.

As to the question should you always use vectors over arrays my answer is it depends on the task and the need.
That's like saying should you always use a certain tool over another when working on your car. This is ludicrous. Use the right tool for the job.

Vectors are not always the right tool.
Arrays are not always the right tool.

This is why we need people called programmers. So my answer is BOTH AND.

8. When vectors can do all the above can and is faster and has more capabilitys for sorting through a sequence like iterators?
Be more careful about saying complex things are faster... because they aren't.

9. >Why would people have to or want to learn about C-style arrays
Working with legacy code, interfacing with libraries that use them, and writing code where vectors could be impractical. That last one could pop up on platforms where the overhead is just too much, or in critical applications that can't afford allocation errors.

>When vectors can do all the above can and is faster and has more capabilitys for sorting through a sequence like iterators?
It's trivial to write a container class for an array. The boost library has one, and then it can be used with the rest of the standard library in a syntactically consistent way.

10. I don't quite see what the kerfuffle is about (although as I don't currently program in C++ maybe I'm not class-centric enough).

You have an array of bytes. If you were to make a vector of it you'd split it up into a singular byte and a pointer to the next item (and these are usually 4 bytes on a 32-bit platform).

Isn't the inefficiency obvious?

You can view an array as a special contigious case of a vector whereby the next item is implicitly at the next memory address, elminating the need for a pointer.

If the future of programming is to have everything in vectors, I think I'll just calmly walk out back and commit suicide, ta.

11. >Isn't the inefficiency obvious?
Not really. You're confusing vectors and lists. A vector is required to be stored in contiguous space, so the implementation is pretty much going to be a dynamic array. How else would we be able to do &v[0] and use it as an array of T?

12. Oh right. Like I said, no experience of C++ so aside from cursory glances of things the only vector I recognise is the one with members x, y (and z).

So you're saying it uses realloc under all that shiz?

13. >So you're saying it uses realloc under all that shiz?
It uses allocators, where the default allocator relies on new, so by default a vector is logically no different memory-wise from:
Code:
`T *p = new T[N];`

14. I'm not even sure there should be a discussion around vectors performance over arrays. For one, different libraries are free to implement them however they wish (despite probably they all being roughly the same).

But most important is the fact STL containers are meant to provide us with specific data structure solutions out of the box. Not to replace standard structures and even less to try and outperform them; Vector is not a replacement for an array. It is an array wrapper (heck! probably it doesn't even need to be that).

I'm inclined to believe (read, from Scott Meyers' books) that all things equal, vectors will match dynamic arrays performance for random access, but come short in terms of insertions and deletions. Concerning static arrays, vectors will outperform arrays for insertions and deletions and match them for random access.

15. >I'm not even sure there should be a discussion around vectors performance over arrays.
I am sure. We have our performance guarantees from the standard, and anything beyond that requires profiling for specific cases. No debate is necessary.