On Wed, Oct 12, 2011 at 6:38 AM, Stewart, Robert <Robert.Stewart@sig.com>wrote:
Matt called for a differently named container as a means to provide the no-exception behavior. I think a policy class, defaulted to the throwing behavior, is the better approach, despite Jeff's thinking it an unnecessary complication.
To be clear, I wasn't suggesting two containers, I was suggesting a single container with something like "push_back" and "unchecked_push_back", similar to how std::vector has both operator[] and "at" member functions. I don't think we have to (or even should) make a decision one-way or the other for the entire type, just like vector doesn't make that decision about bounds-checking for a given instantiation. Let the user decide on a case-by-case basis via the member function that they call since it's a fine-grained trade-off that doesn't have to be made by the type. I'm not sure how many people share the following view, but I am personally grateful that the STL does not have two templates "vector" and "bounds_checked_vector" or a single template with a policy. It's simply not necessary since the presence of both operator[] and at() covers the issue. As for having "push_back" and "unchecked_push_back" rather than "push_back" and "checked_push_back" -- the former approach avoids introducing additional preconditions to a very common standard container member function name. One advantage of this in practice is that it makes it easy for users to do drop-in replacements of std::vector with boost::static_vector without any subtle introductions of undefined behavior. Another is that it makes it easier for readers of the code to know the preconditions of the function without having to look to see if the type uses a "checked_capacity" policy when instantiating the template or not. If a user can guarantee that a push_back or resize will not go beyond capacity, they may then go and use a separately named function and anyone reading the code will immediately see that choice at the call-site. Reusing the name push_back but with extra preconditions makes it more difficult for someone to understand what is going on from the function name since you then have two different kinds of push_back. To be clear, I do agree that in most cases a user would often prefer the unchecked version (just as how in practice, a user may often be able to use operator[] rather than at()), I only disagree on the name of that function. Perhaps unchecked_push_back is a nasty name, but that can be changed. -- -Matt Calabrese