[boost] [fixed_string] Designing the contract

niedz., 15 gru 2019 o 22:33 Vinnie Falco via Boost napisał(a):

On Sun, Dec 15, 2019 at 12:53 PM Joaquin M López Muñoz via Boost wrote:

...

Candidate Boost.FixedString is ACCEPTED into Boost

...

6. Determine the exact behavior on capacity overflow.

I only just a few weeks ago saw Boost.Container's solution, committed recently, which is to make the behavior of overflow a policy. Although my personal view is that this is an overly complex solution, enough people want the other behavior that it makes sense to just copy what Ion did and do the same thing in static_string. This will make everyone happy and it will be consistent with Boost.Container, thus a fairly safe and uncontroversial move.

I wanted to indicate that this would in fact still be a controversial move. I need a library to tell me: is resizing over max_size() a bug or a correct usage? And the answer you will give me is "it is neither or both: it depends on what policy is selected". And this makes the library's contract more vague. If I am in a template: ``` template void do_something(static_string &str) { // ??? } ``` I do not know what the contract is. Hiding the decision under a macro doesn't seem an uncontroversial solution either. If I configure the macro to mean "over-resizing is a bug", and I am using a third party library that internally uses `static_string`, and I may not even know about it, and it defines the same macro as "over-resize is fine", I will get a ODR violation and the likely outcome will be that either I or the third party library will get a different behavior than requested. My recommendation would be to just make a call that over-resizing the string is fine and calls `boost::throw_exception()` and not allow the users to customize it beyond what `boost::throw_exception()` already offers. If I need a library that needs the over-resizing to be a diagnosable bug, i will use a different one (which may be a thin wrapper over `static_string`. Regards, &rzej;