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
> - It responds by unwinding, which can destroy valuable debugging
> - 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