Why isn't a vector of a vector guaranteed to be contiguous? (or is it?)

Question

I know std::vector elements are guaranteed contiguous in memory.

So then why can't you expect a vector containing other vectors to have the total collection contiguous?

The vector is supposed to guarantee contiguous memory layout for its enclosed items, and if those enclosures are also vectors, then I'd expect the full contents of the top-most vector to be in contiguous memory.

But there seems to be some contention on this issue as to whether or not this is true. Can one safely rely on it or not? Some folks seem to go out of their way to achieve this, while I'd think it is guaranteed.

Vectors have a pointer to their data. I suppose it might be possible to make an allocator that can do this. — chris, Apr 05 '13 at 00:46
`sizeof(vector)` != `vector.size()`. Only the pointers the vector holds will be contiguous. — Pubby, Apr 05 '13 at 00:47
If it's any use to you, I provided [this contiguous solution](http://stackoverflow.com/a/15799557/1553090) for someone yesterday who was considering vector-of-vector for a 2D matrix. — paddy, Apr 05 '13 at 02:00

score 5 · Accepted Answer · answered Apr 05 '13 at 00:46

5

Each of your vector inside the vector of vectors is an individual object, and as such is responsible for it's storage. So, no, it is by no means guaranteed to be contiguous, in fact I can 't really see a situation where it could happen that the data stored in the outer vector and it's inner vectors is one contiguous block of memory ever.

answered Apr 05 '13 at 00:46

Mats Petersson

126,704
14
140
227

2

A custom allocator could manage this if it really wanted to. As for whether and why it'd want to do that... – cHao Apr 05 '13 at 00:47
Yes, I suppose so, but you would still risk that there are alignment issues or overallocation. – Mats Petersson Apr 05 '13 at 00:49
ah ok, I get it now, thanks. I would imagine however that something like `vector` or `vector>` could guarantee contiguous memory instead, right? – johnbakers Apr 05 '13 at 01:17
Also consider the effect of `std::swap(v[0], v[1])` on a vector-of-vectors. That swap can't change `v`. – MSalters Apr 05 '13 at 17:59

score 3 · Answer 2 · answered Apr 05 '13 at 00:49

A vector is an object containing a pointer to the actual array.

A vector of vectors would be an object with a pointer to an array of objects, each of which points to its own array elsewhere on the heap. So no, they would never be contiguous in the way that you're asking.

score 3 · Answer 3 · answered Apr 05 '13 at 01:43

I think the most correct formal way of answering this (as opposed to describing existing implementations) is based on §23.3.6.1/1:

[...] The elements of a vector are stored contiguously, meaning that if v is a vector<T, Allocator> where T is some type other than bool, then it obeys the identity
&v[n] == &v[0] + n
for all 0 <= n < v.size().

Note that this talks about the addresses &v[i] of individual elements of the vector and implies, in particular, that each element of the vector has constant size sizeof(T) (because that's how pointer arithmetic works).

This means it is impossible for the elements of a vector to change size at run-time. If a vector<vector<T>> was implemented as one contiguous block of memory, the members of the outer vector, being themselves vectors, would be allowed to change size.

Therefore, there must be an extra level of indirection, i.e., the individual vectors must contain some sort of pointer to a variable-size data structure stored at a different place.

thanks you. i've realized that I can instead get what I'm after by doing something like `vector` or `vector>` -- either of these should guarantee continuity of memory for all items in the parent vector, thus retaining that "multidimensional"-like structure while enjoying full memory contiguity — johnbakers, Apr 05 '13 at 01:46
@SebbyJohanns Sure. The point of my post is to show that the answer to your question ("No") follows directly from the Standard, rather than from how vectors are usually implemented. — jogojapan, Apr 05 '13 at 01:48

Vite Falcon · Answer 4 · 2013-04-05T01:13:43.307

Let's look at the (logical) memory layout of vector:

[size:4/8 bytes]
[capacity:4/8 bytes]
[other datamembers:n bytes]
*[elements:size*sizeof(element) bytes] << one contiguous memory (pointer to heap)

With a vector of vectors it looks like this:

[size:4/8 bytes]
[capacity:4/8 bytes]
[other datamembers:n bytes]
* [
    [Vector:0]
        [size:4/8 bytes]
        [capacity:4/8 bytes]
        [other datamembers:n bytes]
        *[elements:size*sizeof(element) bytes] << pointer to contiguous memory for elements
    [Vector:1]
        [size:4/8 bytes]
        [capacity:4/8 bytes]
        [other datamembers:n bytes]
        *[elements:size*sizeof(element) bytes]
    [Vector:2]
        [size:4/8 bytes]
        [capacity:4/8 bytes]
        [other datamembers:n bytes]
        *[elements:size*sizeof(element) bytes]
    ...
    ...
] << contiguous memory of vectors

This means that a vector has a pointer to contiguous memory storing vectors, each of which stores their elements pointing to another heap with contiguous memory storing the elements.

But if you managed to create an allocator to be used by the vector, such that it would allocate blocks of memory that are contiguous, you'd still face issues where if one of the nested vectors gets removed, the memory is no longer contiguous. Not to mention the situation of having the nested vector having different sizes.

Depending on your use-case you can either use the customer contiguous block memory allocator for a vector of vector, or just do it the old way of manually allocating and deallocating one contiguous block of memory.

A vector actually contains a *pointer* to a block of memory outside of it. That's how it can resize itself, and how you could even *have* an array of vectors -- the structure itself is a constant size. One could conceivably have a contiguous block of memory containing all the elements, though it'd be a pain to do without intimate knowledge of how/when stuff gets allocated, and resizing any of the vectors could blow it all to hell. — cHao, Apr 05 '13 at 01:12
@cHao: I was actually updating my answer when you commented :) — Vite Falcon, Apr 05 '13 at 01:16

didierc · Answer 5 · 2013-04-05T01:10:10.197

The problem is that the vector template doesn't contain the data it handle "inline", or directly. Another way of saying it that the vector class boxes the data array it holds: the vector class holds a pointer to the memory area containing the array of elements. It is structurally equivalent to:

template <typename T>
struct vector_eq {
    T *ptr;
};

and not

template <typename T>
struct vector_neq {
    T arr[SIZE];
};

which would require SIZE to be known at compile time (ie. a constexpr), for arr elements to be included in the struct.

I imagine thar it should be possible to specialise vector<vector<T>> to contain a pointer to a single block of memory, and have its methods return ad hoc instances of vector<T> sharing slices of that memory block, although the logic behind it would probably be a bit hairy.

score 0 · Answer 6 · answered Apr 05 '13 at 01:20

To put it simply - std::vector guarantees the elements are stored contiguously. But that only includes the element's member data, in the case of vector that would be its size, capacity and stuff like that, plus the pointer to the actual vector data.

So, a vector of vectors will give you a contiguous vector of vectors, but those vectors will have their data dynamically allocated on arbitrary memory addresses.

Since an object size needs to be known at compile time, you cannot have objects with varying size, the only way to do this is to use dynamic memory allocation. If you had a custom vector of fixed size that uses no dynamic memory allocation internally, then a std::vector<customVector> would store the customVectors contiguously, but you will still have the additional auxiliary members which will "interrupt" the actual contiguity of the customVector element data.

Why isn't a vector of a vector guaranteed to be contiguous? (or is it?)

6 Answers6

Linked