Re: [boost] Interest in StaticVector - fixed capacity vector

Subject: Re: [boost] Interest in StaticVector - fixed capacity vector
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-10-13 12:32:36

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_at_[hidden]> 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