Dave Abrahams wrote:
Anyway. Do you agree that the number of push_backs is typically a run time value?
Absolutely, 100% agreed.
OK. So we sometimes have more elements than the static_vector can take, and this can't yet be a logic error because it's caused by input external to the program. What do we do? 1. We do not support this case and signal an error. An exception from push_back fits this case perfectly. 2. We discard the extra elements. An exception from push_back works. Depending on how often we exceed capacity (typically not often) and how hard it is to insert checks (typically hard unless we write new code), it may or may not be quite perfect. If a generic algorithm that is adding the elements doesn't handle this exception in a way that suits us, we can't use it, but if push_back crashes, we can't use it even if it did handle it, so we're not worse off. 3. We switch to vector as a fall-back. In this case, I argue that we need a different container, one that does this switch automatically in push_back. In not one of these three cases do we need an "undefined behavior" push_back. I agree that when static_vector<> is used as an array<> replacement for non-default constructible types, we don't need a throwing push_back. That's the trivial use case I outlined, where we insert exactly N elements, a compile-time constant value.