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-14 06:18:39

on Thu Oct 13 2011, Andrew Hundt <athundt-AT-gmail.com> wrote:

> On Thu, Oct 13, 2011 at 12:32 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>>>
>
>>> 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.
>>
>
> This makes me curious. If logic errors should only be caught with an
> assert in the case of defining a specific macro definition, is there
> still a case where one should use std::logic_error and family? If not,
> does that amount to de facto deprecation?

>From my point of view, they've always been deprecated ;-)

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com