On Fri, Nov 29, 2019 at 3:10 AM Peter Dimov via Boost
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