On 12 October 2011 12:30, Nathan Ridge <zeratul976@hotmail.com> wrote:
I'm presently against any throwing behavior related to resizing of a StaticVector/static_vector, since one can usually easily check the relevant preconditions themselves. Just assert. For those who want defined behavior
It's not always you know that you're dealing with a static_vector, but just some code that expects push_back() to work or throw.
Consider a generic algorithm that takes a "push_back-able" type and inserts elements into it using push_back(), and expects the push_back() to work to throw.
When you invoke this algorithm, you either know in advance how many elements it will add, or you don't.
If you do, then when calling this algorithm *with a static_vector*, you need to check beforehand whether there is enough space in the static_vector. I think that's a reasonable requirement, given that you know, at the call site, that you're dealing with a static_vector.
If you don't, then calling the algorithm with a static_vector is a conceptual error in the first place, because you are passing a container with a fixed capacity to an algorithm that expects to be able to add a variable number of elements to it.
I realize the validity of your point, and I don't disagree in general. But I often look through the eyes of code maintenance for very large projects, and if I encounter a line like: m_Somethings.push_back(...); I don't consider that a possible source of undefined behaviour. It's too easy for a maintenance programmer to add another line exactly the same, without realizing he's broken the preconditions. If that code would read m_Somethings.unchecked_push_back(...) it's at least less likely that someone would add another such line without further investigation. Either way, some people want an unchecked version and others want a checked version, both are useful, admittedly.. Question is if we should have 1) push_back() & unchecked_push_back() or 2) push_back() & checked_push_back(). - christian