Arrays Or Vectors?

Question

Possible Duplicate:
When would you use an array rather than a vector/string?
What is the difference between std::array and std::vector? When do you use one over other?

I always use vectors (dynamic arrays) for everything, I never use normal arrays, is there any downside to this, for example, will there ever be a time when a vector will not suit, and a normal array will suit a function?

This might help. http://stackoverflow.com/questions/594522/when-would-you-use-an-array-rather-than-a-vector-string?rq=1 — NeonGlow, Jan 23 '13 at 12:16
Depends on what you are trying to do. If you can use array, use it since it is faster than vector. Avoid vectors unless you need them. — Maroun, Jan 23 '13 at 12:17
see http://stackoverflow.com/questions/594522/when-would-you-use-an-array-rather-than-a-vector-string?rq=1 — zr., Jan 23 '13 at 12:17
@AlokSave I think the asker means the language feature arrays rather than `std::array`. — Joseph Mansfield, Jan 23 '13 at 12:17
generally not as a vector can be viewed as an array at any given point of time (leaving aside complexity issues) but if you know the size of an array as fixed use an array - vectors can lead to minor wastage of space — jemmanuel, Jan 23 '13 at 12:18

score 4 · Accepted Answer · answered Jan 23 '13 at 12:18

4

According to Bjarne Stroustrup, you should use vector over Array unless you have a really good reason to use an array.

answered Jan 23 '13 at 12:18

Caesar

9,483
8
40
66

2

Good, so there is almost no reason to use an array if you have access and know how to use a vector. thanks. – killerloader Jan 23 '13 at 12:20

Mike Seymour · Answer 2 · 2013-01-23T12:50:06.907

4

In nearly all situations, vector is preferable. Its memory is allocated from the free store (designed for large allocations) and managed automatically; and you can easily get a pointer to the array itself if you need it.

You would use an array (either built-in or std::array) if:

The array size is known at compile time and not so large that it might blow the stack; and
The array has a fixed scope; and
Dynamic allocation is causing issues such as excessive run-time cost or heap fragmentation, and you don't want to use custom allocators to address these issues.

edited Jan 23 '13 at 12:50

answered Jan 23 '13 at 12:25

Mike Seymour

249,747
28
448
644

remark also that you should use array when heap fragmentation is a concern. i.e. you need arrays of different small sizes (known at compile time) at different times, and you need to run your program for a very very long time (e.g. servers). – thang Jan 23 '13 at 12:42
@thang: a pool allocator could also solve that, different pools for each of those different small array sizes that you know at compile time. For that matter, it might also solve the excessive run-time cost ;-) – Steve Jessop Jan 23 '13 at 12:50
Good points; I've updated the answer to include them. – Mike Seymour Jan 23 '13 at 12:51
@SteveJessop, you couldn't have possibly typed that with a straight face. pool allocation strategies alleviate the problem in very specific scenarios. it certainly doesn't "solve that". pool allocation strategies also incur memory overhead (no free lunch, right?). consider randomly allocating and almost randomly de-allocating 1 million objects of sizes randomly scattered between 50k and 100k. in fact, this is not a hypothetical scenario. it happens often in large server applications. – thang Jan 23 '13 at 13:02
@thang: "randomly allocating and almost randomly de-allocating 1 million objects of sizes randomly scattered between 50k and 100k" is not at all the same thing as "you need arrays of different small sizes (known at compile time) at different times". So, while you're correct that just slinging a pool allocator at the problem is not a universal solution to fragmentation, I believe I'm also correct to say that it *could* solve it, subject to similar constraints that we'd apply before using the stack to solve it. Agreed that there's an overhead in memory usage, though. – Steve Jessop Jan 23 '13 at 13:08
Or to put it another way, I could just as well point out that randomly allocating and **almost randomly deallocating** those objects also rules out using the stack as you suggested. To use the call stack, the order of deallocation must be reverse order of allocation. So both solutions fail to deal with fragmentation in such cases. – Steve Jessop Jan 23 '13 at 13:12
@SteveJessop, if you have a few thousand functions, each needing temporary scratch buffer of known sizes between 50k-100k. Some call each other almost randomly. that would certainly fit the bill. this is actually a real scenario. – thang Jan 23 '13 at 13:12
@SteveJessop, as far as I know, the standard heap allocator merges blocks, but the problem is that these allocs can get interlaced with larger blocks that really *should* be put on the heap (e.g. video frames). if things that should be on the stack get placed on the heap (when using vector), when large object that should go on the heap also go on the heap, what happens? fragmentation! what you can certainly do is create a separate heap that specifically operates in FIFO order for the purpose of using vector with relatively small objects, but that is a stack, so why not just use the stack? – thang Jan 23 '13 at 13:18
I think the bottom line is that there's the right construct for the right time, and that depends on your application. And by the way, if it doesn't work all the time, then it doesn't "solve" the problem, it alleviates it. – thang Jan 23 '13 at 13:22
@SteveJessop, if you can fix your specific scenario with pool allocation strategies and can take the hit in memory overhead, then there is no longer a fragmentation concern, is there? – thang Jan 23 '13 at 13:26
Would you mind taking up the off-topic argument somewhere else? Custom allocators can solve some problems but not others; the solution to any particular problem depends on the specifics of the problem; and this question isn't about any specific situation. – Mike Seymour Jan 23 '13 at 13:29

score 2 · Answer 3 · answered Jan 23 '13 at 12:19

Vector is a dynamically growing array. Whereas arrays are static. You have to define a array at the beginning and cannot be reallocated. With vectors you do not have the limitation of declaring a fixed size. You can start with a empty vector and keep it growing as long as you want. Till date I have never found any situation where array is more suited. In fact I have found using vectors solves many of many problems which I face with an array. I think its a very good practice to use vectors always.

Keep doing it!!!!

Thanks, i will. I tried using arrays, but I found it hard to use when you don't know how many objects you have, and you're storing pointers to objects.(Such as when I made an online game.. which I discontinued). — killerloader, Jan 23 '13 at 23:34

score 0 · Answer 4 · answered Jan 23 '13 at 12:46

Use whatever best fits your situation, I have outlined one of my favourite benefits of a fixed size array below with a little example.

If you have an unknown size or may require an increase in storage at runtime you would be looking for a vector.

If you have a predetermined size you can use a std::array or even a raw C array (int foo[256]) which has benefits in code simplicity and speed. One of the best benefits here is if the data to be stored in the array is known then you can use a C style initialiser list removing any of the setup costs which would occur with a vector and open up space for the optimizer to make things faster while also being simpler to debug:

struct KeyPair { int key; string name; }; 
const KeyPair kFoo[] = { { 0, "0" }, { 1, "1" }, { 2, "2" } };

const string& getName( unsigned int key )
{
assert( key < (sizeof(kFoo)/sizeof(*kFoo)) ); // Check key is a valid index
assert( kFoo[key].key == key ); //< Sanity check - useful is key is an enum which could change
return kFoo[key];
}

Arrays Or Vectors?

4 Answers4