0

In which case using vectors or sets (stl containers ) is advantageous compared to normal arrays?

taxido
  • 1
  • 1
  • 3
  • 5
    The question is much easier to answer in the reverse, i.e. when are arrays better than vectors or sets, because the answer is so much smaller. – Mark Ransom Nov 28 '11 at 19:27
  • 1
    Vectors, sets, and arrays all solve different problems. What do you mean by "normal arrays" when comparing to sets? Implementing a set in a flat manner? – GManNickG Nov 28 '11 at 19:29
  • @MarkRansom yes, exactly this i want to ask, what u said.. – taxido Nov 28 '11 at 19:44
  • There are lots of " vs " questions with titles like "c++ vector vs array", "array vs vector vs list" with number of answers of 5+. Why don't you search and read them first? – ali_bahoo Nov 28 '11 at 21:41
  • possible duplicate of [Using arrays or std::vectors in C++, what's the performance gap?](http://stackoverflow.com/questions/381621/using-arrays-or-stdvectors-in-c-whats-the-performance-gap) – hammar Nov 28 '11 at 23:16

5 Answers5

4

"Normal arrays" are static objects: Their size is fixed and determined at compile time. Dynamic containers can have an arbitrary amount of elements which can change at runtime.

Necessarily, dynamic containers have to use more expensive memory allocation operations than static arrays. If you need a dynamic container, there's no way around it, but if a static array suffices, you might prefer that (but use std::array!).

Note also that static arrays with automatic storage usually cannot be too large, since programs typically only have limited memory for automatic objects.

Another point is utility: Several advanced data structures like linked lists and binary search trees are only available in the standard library as dynamic containers. If you need list or a queue or a map, even if it's just small and of bounded size, the dynamic containers are readily available, while there is no static analogue as part of the standard library. (However, thanks to allocators used by the standard containers, you can always put a dynamic container inside a static array by using a pool-type allocator. C++ decouples object lifetime from memory lifetime.)

Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
  • +1 for mentioning `std::array<>` -- this type obviates the need for **ever** using a plain C-array. – ildjarn Nov 28 '11 at 19:46
1

I suggest that there is almost never a reason to use std::vector. std::deque has all the advantages (constant time access, etc) with none of the drawbacks (terrible resize performance). The only time you would ever choose a vector over a deque is if you need the fact that it's backed by a real, old-fashioned, C-style array. And the only reason for that is if you need to pass it into some legacy function (as an array).

The advantages of vector over a traditional array are limited. It will grow if you insert past it's current size, but extremely inefficiently (see std::deque for a better option). It is just as easy to index past the end of a vector as it is an array, so no benefit there. The memory management quality is only such that it will allocate/deallocate items it contains. But these are typically pointers so that doesn't help. If they're instances (not pointer) then an array will also allocate/deallocate them properly too.

If I need an array, I would probably choose vector because it has some nice API things like size, begin, & end. But in general my suggestion is DON'T USE EITHER ONE! GO WITH std::deque INSTEAD!

pedorro
  • 3,079
  • 1
  • 24
  • 24
  • 1
    If you spend most of your time accessing the array rather than modifying it, std::vector will have the advantage over std::deque. But your point is still valid - deque exists for a reason, and it doesn't get enough consideration. – Mark Ransom Nov 29 '11 at 05:06
0

One advantage is that STL containers take care of memory management for you and are less likely to result in buffer overflows or memory leaks than are C-style arrays. They're also prebuilt, so you don't have to spend time reinventing the wheel. So any time you're concerned about such things, STL containers are a better choice.

andand
  • 17,134
  • 11
  • 53
  • 79
  • This is a nice sentiment, but I don't think using a vector over an array is any less likely to have memory leaks. If you delete a vector of pointers, just like an array, it just removes the pointers, it doesn't call delete on the objects the point to. – pedorro Nov 28 '11 at 19:49
  • Granted, but I did say "less likely to result in ... memory leaks". I didn't say they would be eliminated. Of course you can reduce the risk even further by not using C-style pointers, and instead rely on shared or unique pointers available in either the Boost library or C++11. – andand Nov 28 '11 at 21:36
0

Advantageous in what way? set, multiset, vector, list, map, deque, stack, queue, priority_queue, multimap, bitset are all implemented differently. It depends on what you're doing. Some are implemented with a balanced tree, some with a contiguous array, some as linked lists, etc. Some are faster at inserting, some are faster at accessing, some work well with deleting, etc.

No container is always advantageous to another, or else the other wouldn't exist. Part of software development is being able to make decisions such as "which container should I use" so what's your real question, and how do you need your container to be advantageous?

Obviously, arrays will always be faster than vectors because the underlying component of a vector is an array, so the vector will just have overhead. But that overhead is doing a lot of wonderful things for you that means you don't have to worry about tons of things that you do have to worry about with arrays.

Andrew Rasmussen
  • 14,912
  • 10
  • 45
  • 81
  • I just want to ask that when should i prefer using array in problem solving in spoj instead of using stl components. – taxido Nov 28 '11 at 19:41
  • @taxido: If you are using SPOJ to improve your programming skills I suggest you improve your C++ skills at the same time by using Standard Library algorithms and containers (like `vector`). I find they let me focus on problem solving instead of reinventing basic data structures. – Blastfurnace Nov 28 '11 at 20:33
0

Most of the time the standard containers will be preferred over an old-fashioned array. They just have a lot more capabilities. The only time an array would be reasonable over std::vector would be when the size is known at compile time and is reasonably small (i.e. not megabytes) and you need to save the overhead of heap allocation. Sometimes an array is slightly more convenient as you can pass arr instead of &vec[0] to a function, but that's a very small price to pay.

If you're having trouble choosing between std::vector and std::set and the other standard containers, see here: In which scenario do I use a particular STL container?

Community
  • 1
  • 1
Mark Ransom
  • 299,747
  • 42
  • 398
  • 622