Dave Abrahams wrote:
Nobody likes "unefined behaviour???" But please allow me to replace that comment with:
"// throws an exception???"
It's just not the most appropriate response. For those who want checking, dropping into the debugger or dumping core or logging and terminating would be better, and those who don't will be annoyed to pay for unneeded checks when their code is correct.
We (as in the authors of the example) fall in neither category of yours. We want the algorithm that does push_back to terminate when it reaches capacity. Which is exactly what it will do, without having to be rewritten.
Why should the library be locked into providing what is almost always a suboptimal response?
It's your (and others') assertion that this is almost always a suboptimal response. You haven't backed it up. Yes, it's trivial to argue that logic errors should not be exceptions, but why is push_back over capacity "almost always" a logic error? Heck... why is it a logic error at all, except in the trivial case in which you start with an empty static_vector<T, N> and do exactly N push_backs, a case which more or less calls for an array because it doesn't exploit the fact that size() can be different from capacity()? Stated differently, is the number of push_backs always a compile time constant? Does it not come, more often than not, from runtime input?