I was wondering with my colleague today whether std::vector can be implemented to make use of small buffer optimization. By looking into the C++11 draft, I read at 23.3.1p8
The expression a.swap(b), for containers a and b of a standard container type other than array, shall exchange the values of a and b without invoking any move, copy, or swap operations on the individual container elements.
That at first seems to outlaw small buffer optimization, but under the as-if rule, we would be allowed to still do small buffer optimization for non-class types (since we cannot observe the copy being done). The next text appears to be harder to "fool"
Every iterator referring to an element in one container before the swap shall refer to the same element in the other container after the swap.
Is this sufficient to prevent implementing the small buffer optimization for std::vector? Are there any other road-blocks or is it eventually possible to have a std::vector with SBO?
23.2.1 / p10 / b6:
Unless otherwise specified ...
- no swap() function invalidates any references, pointers, or iterators referring to the elements of the containers being swapped. ...
Nowhere does it "specify otherwise" for vector. So this outlaws the SBO for vector.
string is not bound by this rule because it does "specify otherwise" in 21.4.1/p6:
References, pointers, and iterators referring to the elements of a basic_string sequence may be invalidated by the following uses of that basic_string object:
- as an argument to any standard library function taking a reference to non-const basic_string as an argument.^234
234) For example, as an argument to non-member functions swap() (21.4.8.8), operator>>() (21.4.8.9), and getline() (21.4.8.9), or as an argument to basic_string::swap()
In addition to the problem with iterator invalidation, there's a security argument for avoiding the small buffer optimization.
If writes overrun a std::vector, you get heap corruption, which is quite difficult to predict what gets overwritten and very difficult to leverage for arbitrary code execution.
If the buffer is instead embedded in a local variable, an overrun trashes the stack and the attacker will probably gain control over the return address, which is far more useful (return-to-libc attacks, for example).
