Boost logo

Boost :

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-12-05 07:29:01


śr., 4 gru 2019 o 23:13 Emil Dotchevski via Boost <boost_at_[hidden]>
napisał(a):

> On Wed, Dec 4, 2019 at 6:14 AM Andrzej Krzemienski via Boost <
> boost_at_[hidden]> wrote:
>
> > These goal 3 is in clear conflict with either 1 or 2. This becomes clear
> > when we consider what should be the response to doing a resize() over
> > capacity(): a precondition violation or a normal course of action
> signaled
> > by an exception.
> >
>
> The severity of buffer overrun bugs should be considered in this case, as
> well as the overhead of checking and calling boost::throw_exception. Under
> -fno-exceptions, this is literally a single cmp instruction. I can't
> imagine a C++ program where this would matter, but if one exists, I can't
> imagine it would be using a universal fixed_string type. The correct design
> is to check and call boost::throw_exception, rather than assert.
>

I tend to agree; especially that the library originated from Beast where it
may be even facing the outside world directly. What I would expect of
documentation to state it clearly in the design goals section:
1. Overrunning capacity() is not a bug but a normal usage of the library.
In this case we guarantee that an exception is thrown, much like
std::string does.
2. This design decision is opposite of what `static_vector` chose, so do
not be misled by an apparent similarity.

Note that the motivation -- in the alternate design (which neither of us
wants for fixed_string) -- for having a precondition violation rather than
guaranteed throw is safety: not performance.

Regards,
&rzej;

> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


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