Standard citation: Does an out of range call to `vector::operator[]` invoke Undefined Behavior?

Question

Consider:

#include 

int main()
{
  std::vector  v;
  v.reserve (100);
  v[1] = 42;
}

I am aware that the above code i

Answer 1

It's an outgrowth of how operator[] is defined. In §23.2.3 [sequence.rqmts] Table 101, the Operational Semantics of operator[] is defined as *(a.begin() + n). So it's defined in terms of iterators. And incrementing begin past end and dereferencing it is undefined behavior according to §24.2.1/5 [iterator.requirements.general].

Answer 2

This doesn't answer your underlying question, but your vector isn't of size 0, it is of size 100 (since you created it with the size constructor)

The man page for std::vector does claim it's undefined behaviour, but I don't know if you consider that to be "good enough" (you asked for a citation from the c++ standard)

template<typename _Tp, typename _Alloc = std::allocator<_Tp>> reference std::vector< _Tp, _Alloc >::operator[] (size_type__n)
   [inline]
   Subscript access to the data contained in the vector. Parameters:
       n The index of the element for which data should be accessed.

   Returns:
       Read/write reference to data.

   This operator allows for easy, array-style, data access. Note that data access with this operator is unchecked and
   out_of_range lookups are not defined. (For checked lookups see at().)

   Definition at line 695 of file stl_vector.h.

Answer 3

a[n] (where a is a vector and n is an integer) is defined in Table 101 in 23.2.3p16 as *(a.begin() + n).

23.3.6.1p1 says that "vector... supports random access iterators." Table 111 in 24.2.7p1 defines a + n (where a is a random access iterator) in terms of a += n, which in turn is defined as being equivalent to n repeated evaluations of ++a.

Table 107 in 24.2.3p2 defines the expression ++r (where r is an input iterator) with the precondition that "r is dereferenceable".

23.2.1p6 ...end() returns an iterator which is the past-the-end value for the container. If the container is empty, then begin() == end().

Note that, in your example, v is indeed empty. This simplifies the proof; otherwise, more citations would be needed to show that applying operator++ repeatedly v.size() times to v.begin() would produce v.end().

24.2.1p5 ...The library never assumes that past-the-end values are dereferenceable...