Boost logo

Boost :

Subject: Re: [boost] Interest in StaticVector - fixed capacity vector
From: Andrew Hundt (athundt_at_[hidden])
Date: 2011-10-13 14:20:35


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?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk