Some questions about Vector in STL

Question

I have some questions about vector in STL to clarify.....

1. Where are the objects in vector allocated? heap?

2. does vector have boundary check? If the index out of the boundary, what error will happen?

3. Why array is faster than vector?

4. Is there any case in which vector is not applicable but array is a must?

Answer 1

1. In a contiguous memory block on the heap. A vector<int> allocates memory the same way new int[x] would.
2. Only if you use the at method. It throws an std::out_of_range exception if the boundary check fails. The operator[] doesn't perform bounds checking.
3. Because an array gives direct access to memory, while accessing a vector element most likely involves a method call. The difference can be ridiculously small though, especially if your compiler decides to inline the calls.
4. In general, you'll use a vector if you want your container to have a dynamic size, and a simple array if a known fixed size is enough. Be sure to check out the other containers, like deque and list, to be sure you pick the most appropriate one. Otherwise, if you need to deal with non-C++ APIs, you'll obviously need to have access to a regular array. (edit) @BillyONeal says you should use &vector[0] to get the address of the underlying array, but use it with care since it can change if the vector's capacity changes.

Answer 2

Where are the objects in vector allocated? heap?

It depends on the STL implementation, but in all likelihood on the heap, yes.

does vector have boundary check? If the index out of the boundary, 
what error will happen?

Yes, a vector grows dynamically, you can check its size using the capacity() member function. If it should run out of space, it generally allocates more space using the reserve() member function.

Why array is faster than vector?

Arrays can be faster because they are plain data that does not need to be accessed through a wrapper object such as vector. You can think of a vector as neatly packaged array for your convenience.

Is there any case in which vector is not applicable but array is a must?

I think there can be times where an array is preferable over a vector. For example, when dealing with legacy C code or when speed is of utmost importance. But generally you can solve any array problem by containing the data in an STL vector.

Answer 3

Ad 4.: When dealing with legacy interfaces (e.g. POSIX) arrays may be a must.

Answer 4

1. On the heap (assuming you use the standard allocator, which is the default)

2. It is not boundary checked when using operator[], but it is if you use the member function at (e.g. my_vec.at(0)). If you use at and the index is out or bounds, it throws an std::out_of_range exception.

3. Arrays aren't generally faster. It depends whether or not the vector's operator[] calls are inlined or not. Most modern compilers should index it though, as it is just a single array index.

4. In general, normal arrays can be replaced by vectors. You shouldn't really use a std::vector on the public interface of a library, and manu library APIs require raw C-style arrays.

Answer 5

1. By default contents are allocated dynamically. (But I suppose you can provide an allocator that gets the memory from some place else.)

2. The at method does bounds checks and throws an out_of_range. Other methods may or may not check bounds, depending on implementation and settings.

3. I would assume a vector to be slower than an array when it does something different from an array. For example, dynamic allocation is costly, so vector has a cost that arrays don't have. Dynamically resizing a vector is costly, whereas an array can't be resized at all. I wouldn't expect to see any difference when accessing the elements (except for possible run-time checks done by the implementation which you should be able to turn off if desired).

4. I don't know of such a scenario. You can always get a pointer to the underlying array of a vector with &vec[0]. However, a vector can be an overkill if you don't need any of the features it provides - mostly the ability to (re)size it dynamically. In such cases an array could do just fine, but note that there are classes that make an array a first-class object too (std::tr1::array or boost::array) which make the array copyable and not decay into a pointer.