on Wed Oct 12 2011, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Wed, Oct 12, 2011 at 12:38 PM, Stewart, Robert <Robert.Stewart@sig.com> wrote:
I'd really like to see the interface be as close to C++11
std::vector as possible (other than vector<bool>).
Interface is one thing. That doesn't address the idea of throwing exceptions when exceeding capacity. Many wanting to use static_vector in embedded environments don't want exceptions. The rest of us find them useful. Still, BOOST_THROW_EXCEPTION provides a means to configure that, but it affects all Boost code; localizing the effect may be desirable. 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.
Is it a logic error or a runtime error? IMO exceeding the capacity here is a logic error and should be handled with an assert by default. Isn't it comparable to doing a pop_back() on an empty vector?
Indeed; I object to handling something that is almost certainly going to be a programming error with a defined behavior of throwing an exception (yes, I think std::vector::at is a mistake), for several reasons: - It limits your ability to detect bugs: once you make the behavior defined, you don't know whether a programming error has been committed anymore. - It responds by unwinding, which can destroy valuable debugging information - It does way more than absolutely necessary, which, in a program whose invariants may be broken, may prevent emergency measures from completing successfully. That said, I am not a security guy, and I understand those people who want to eliminate avoidable, open-ended, undefined behavior whenver possible. Therefore I think that it might make sense to establish a BOOST_SEMISECURE mode, and to encourage library authors are free/encouraged to say something like: If <some requirement> is not satisfied, the behavior is undefined. In BOOST_SEMISECURE mode the library will (or may) check <some requirement> using BOOST_ASSERT. The point being that a. We can unambiguously mark some usage as incorrect b. Those who don't want it don't have to pay for the check c. The behavior of check failures can be tuned. -- Dave Abrahams BoostPro Computing http://www.boostpro.com