Some questions about Vector in STL

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

  • Where are the objects in the vector selected? a bunch?

  • Does the border have a border? If the index goes abroad, what error will occur?

  • Why is an array faster than a vector?

  • Is there a case where the vector is not applicable, but the array is required?

+4
source share
5 answers
  • In an adjacent memory block on the heap. A vector<int> allocates memory in the same way as new int[x] .
  • Only if you use the at method. It throws an exception std::out_of_range if border checking fails. operator[] does not perform bounds checking.
  • Since the array gives direct access to the memory, access to the vector element most likely involves a method call. The difference can be ridiculously small, though, especially if your compiler decides to embed calls.
  • In general, you will use vector if you want your container to have a dynamic size and a simple array if a fixed size is known enough. Be sure to check other containers, such as deque and list , to make sure you choose the most suitable one. Otherwise, if you need to deal with non-C ++ APIs, you obviously need access to a regular array. (edit) @BillyONeal says you should use &vector[0] to get the address of the base array, but use it with caution, as it can change if the vector capacity changes.
+6
source

Where are the objects in the vector highlighted? a bunch?

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, the vector is growing dynamically, you can check its size using the member function capacity() . If it should end, it usually allocates more space using the reserve() member function.

Why is an array faster than a vector?

Arrays can be faster because this is simple data that does not need to be accessed through a wrapper, such as vector. . For convenience, you can use vector as a neatly packed array.

Is there a case where a vector is not applicable, but an array is required?

I think there may be times when an array is preferable over a vector . For example, when you are dealing with legacy C code, or when speed is paramount. But usually you can solve any problem with the array by specifying the data in STL vector .

0
source

Announcement 4: When working with legacy interfaces (such as POSIX), arrays may be required.

0
source
  • On the heap (if you are using a standard allocator, which is the default)

  • When using operator[] it is not checked by the border, but if you use the member function at (for example, my_vec.at(0) ). If you use at and the index is missing or limited, it throws an exception std::out_of_range .

  • Arrays are usually not faster. It depends on whether or not vector operator[] calls are enabled. Most modern compilers should index it, since this is just one index of the array.

  • In general, normal arrays can be replaced by vectors. You should not use std::vector in the public library interface, but raw C-style arrays are required for the manu APIs.

0
source
  • By default, content is distributed dynamically. (But I suppose you can provide a allocator that receives memory from some other place.)

  • The at method restricts validation and out_of_range . Other methods may or may not check boundaries, depending on implementation and settings.

  • I would suggest that a vector will be slower than an array when it does something other than an array. For example, dynamic allocation is expensive, so a vector has a cost that is not in arrays. Dynamically resizing a vector is expensive, while an array cannot be resized at all. I would not expect to see any difference when accessing elements (with the exception of possible runtime checks made during implementation, which you might be able to disable if necessary).

  • I do not know such a scenario. You can always get a pointer to the base array of a vector with &vec[0] . However, a vector may be redundant if you do not need any of the functions it provides - basically the ability (re) to change it dynamically. In such cases, the array could be done perfectly, but note that there are classes that also make the array a first-class object ( std::tr1::array or boost::array ) that make the array copied and does not break into a pointer.

0
source

Source: https://habr.com/ru/post/1304714/


All Articles