I'm curious if this sort of thing is legal:
std::vector<some_class_type> vec;
vec.reserve(10);
some_class_type* ptr = vec.data() + 3; // that object doesn't exist yet
Note that I'm not attempting to access the value pointed to.
This is what the standard says about data(), but I'm not sure if it's relevant:
Returns: A pointer such that
[data(),data() + size())is a valid range. For a non-empty vector,data() == &front().
data must return a pointer to a valid range ([vector.data]). Pointers that point into that range, including the one that points one past the last element of the range, must be stable until next reallocation. When size() is zero, data() points past the end of an empty range, which is a perfectly valid pointer to keep (but not to dereference of course).data must remain stable for the next 10 insertions, we can assume that a storage region suitably sized and aligned for placing an array of 10 elements in it was obtained, and data points to the beginning of that region. That is, the implementation must call an allocation function and set the internal data pointer to its return value. (There is no direct indication in the standard that this must be true, but I cannot imagine a situation where it might be false. I assume that reallocation mandated ([vector.capacity]) by the standard actually calls one of the allocation functions such as ::operator new or std::malloc, otherwise calling this operation "reallocation" would be rather dubious. At any rate, there seems to be no way to avoid such allocation on any current architecture).
In most implementations of the STL, a reserve of an empty vector will trigger a reallocation and ensure that the data your are pointed it is owned/managed.
The location of the data (the value of the pointer as returned by data()) might change when a vector is resized. Holding a pointer per se is of course legal, dereferencing it for a read while un-initialized is of course undefined, and derefering it after initialized is only legal if you can guarantee that your vector did not resize and as such the range you allocated is still in the same place.
Incrementing a pointer to data that has been malloc'd is fine. In this example, you perform pointer arithmetic to hold a pointer to data that you know has been allocated by the std::vector. Regardless of whether the element pointed to by the pointer is ever initialized, a resize operation is problematic as it might deallocate the memory you are pointing to.
We cannot assume that this pointer is valid. Moreover, the pointer arithmetic vec.data() + 3 might be UB. And since nothing guarantees that it is not UB, if this code works it's implementation dependent.
Note: this answer was reworded to make a better distinction between UB and at risk of being UB.
In you code snippet, you use reserve() and data() on an empty vector vec that has a size() of 0. We know two things from your own quote of the standard :
data() returns a pointer such that [data(), data() + size()) is a valid range. In your case, we therefore can assume that [data(), data()+0) is a valid range. But there is no such guarantee for [data(), data()+capacity()). Your standard library could provide such an implementation dependent guarantee, but you cannot be certain in general. If not, the expression would definitively be UB (explanation further down the road).data() returns the address of the first element. This is an assumption you make (otherwise you wouldn't add a fixed index). But since your vector is empty, you cannot be sure. An implementation is for example perfectly allowed to return a nullptr for an empty vector, regardless of its capacity.A fundamental rule is often ignored: a pointer arithmetic operation is UB if it isn't within the range of a valid array object. The standard expresses this more formally:
[expr.add]/4: When an expression J that has integral type is added to or subtracted from an expression P of pointer type, the result has the type of P.
- If P evaluates to a null pointer value and J evaluates to 0, the result is a null pointer value.
- Otherwise, if P points to an array element i of an array object x with n elements, the expressions P + J and J + P (where J has the value j) point to the (possibly-hypothetical) array element i + j of x if 0 ≤ i + j ≤ n and the expression P - J points to the (possibly-hypothetical) array element i − j of x if 0 ≤ i − j ≤ n.
- Otherwise, the behavior is undefined.
This means that if you add an integer to a pointer, and the result would be out of the valid range, the expression itself would be UB, before a pointer result is even computed. This means also that adding anything else than 0 to nullptr would be UB as well.
So if the vector implementation of your library strictly complies to the standard, without any additional guarantee, your code would be UB because of this pointer arithmetic rule (out of range). But since we do not know what your implementation does, we cannot be sure of UB. The only thing we are sure is that UB cannot be excluded and the code is not portable.
It may be tempting to believe that reserve() guarantees memory for the vector being allocated and hence the validity of the range [data(), data() +capacity()) ensured. But this is not at all the case: the pointer arithmetic rule is not about allocated memory but about array element of an array object with n elements.
An implementation could well allocate memory and create the array object of the exact right size using placement new, to preserve the addresses of the existing elements. It would not be a super efficient implementation, but it'd be a legal one.
Moreover, the standard gives for reserve() and capacity() guarantees about the absence of reallocation:
[vector.capacity]/4: A directive that informs a vector of a planned change in size, so that it can manage the storage allocation accordingly. After reserve(), capacity() is greater or equal to the argument of reserve if reallocation happens; and equal to the previous value of capacity() otherwise. Reallocation happens at this point if and only if the current capacity is less than the argument of reserve().
[vector.capacity]/1: Returns: The total number of elements that the vector can hold without requiring reallocation.
But as long as the vector stays empty, no element might ever be reallocated. So a standard compliant implementation has not to worry on any reallocation and could delay the first allocation just in time before the first element is inserted in the vector. I would personally not implement it like that, but it would be legal and cannot be excluded. The fact that data() is not obliged to return a pointer to a first element when the vector is empty, seems tailor made to allow this kind of implementation.
Your code will work with mainstream implementations, since it is quite common for practical reasons for reserve() to trigger allocation/reallocation. But if you want portable code, that works perfectly also on exotic microcontroller architectures in mission critical systems with lives at risks, then you'd better avoid such shortcuts.
In the remarks to vector::reserve(), the C++17 standard states: "No reallocation shall take place during insertions that happen after a call to reserve() until the time when an insertion would make the size of the vector greater than the value of capacity()."
In the remarks to vector::shrink_to_fit(), the same standard states: "Reallocation invalidates all the references, pointers, and iterators referring to the elements in the sequence as well as the past-the-end iterator. If no reallocation happens, they remain valid."
Combing these two leads to this statement: After a call to reserve(), no pointers must be invalidated by any insertions, as long, as the initially reserved capacity is respected. As the value returned by data() is clearly a pointer, the rule applies to it. So, if an application calls reserve() with a positive number, the implementation must immediately set its data() pointer. It may only change it, when a reallocation may take place.
Some people might say, that the standard talks about "pointers to individual elements", that don't get invalidated, but data() doesn't point to any element, if the vector has reserved space, but is still empty. But well, the standards says: "pointers ... referring to the elements in the sequence". And data() is clearly referring to all the elements in the sequence. As mathematically, an empty set is still a set and an empty sequence is still a sequence, a data() pointer pointing to the empty sequence must nonetheless not be invalidated, when that sequence is later enlarged (unless, of course, if its capacity() is exhausted).
But what about pointer arithmetics into empty space, e.g. vec.data() + 3? Well, in C, this is clearly be a valid operation, as we know, that vec.data() points to space for 10 elements, so advancing three elements into it is fine. In C++, this C like pointer arithmetic is still legal, as long, as we never dare to dereference those pointers before they become valid.
Of course, it's legal.
The quote you mentioned is irrelevant, since size is not equal to "reserved space" which reserve provides.
You can also initialize vec.data()+3 before vec[0], although the vector's "size" variable will not be updated.
So, while this use of vector is extremely undesirable, vector is not much more than a thin wrapper for a dynamically allocated array, and an abuse of vector this way is not illegal.
As a rule of thumb: Once you use the vector::data() function, you are doing something genuinely wrong.
