Re: [Boost-users] [review][fixed_string] FixedString review starts today

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2019-12-02 17:56:25

On Fri, Nov 29, 2019 at 3:10 AM Peter Dimov via Boost <boost_at_[hidden]>
wrote:

> Andrzej Krzemienski wrote:
>
> > I suspect (I am not programming in an embedded system) that rather than
> > relying on __builtin_trap() or std::abort(), what you do is start
> treating
> > a `resize()` over `capacity()` as a precondition violation (a bug). And
> > this causes a different programming model and the organization of your
> > code.
>
> That was exactly why I wrote
>
> > > There's no need to afford exceptions, you just need to be able to
> afford
> > > the potential loss in performance, basically one branch per append if
> > > not heroically optimized away.
>
> That is: in order to use the library as presented, you don't need to
> afford
> exceptions, but you will need to basically duplicate the same check op+=
> does, in user code; this may decrease performance, but will not allow a
> buffer overflow in case you either forgot the check or got it wrong.
>

This leaves out the case where you know from context outside of
fixed_string that an append is guaranteed to work.  This is an important
case, IMO, and one for which I should not be required to suffer the perf
overhead when I don't need the check.

Also, if the API defined preconditions and invoked UB when misused, the
check would only ever need to happen once.  As you say, this would have to
be done in user code -- as with all precondtioned functions, like back(),
operator[](), etc.  That is, the user's need to verify that the operation
will succeed would not be unique to the append/insert operations.

Zach