From: Gavin Lambert (boost_at_[hidden])
Date: 2019-12-16 22:43:56
On 16/12/2019 21:43, Andrzej Krzemienski wrote:
> template<size_t MaxSize, typename CharT, typename Policy>
> void do_something(static_string<MaxSiz, CharT, Policy> &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
This is why, as I mentioned elsewhere in a related context, macros
should only ever select between different explicitly-named-differently
implementations (such as setting a default for that template policy
parameter, but not replacing the template policy parameter).
Otherwise you get ODR violations and inconsistent ABI. At least when
explicitly part of the signature, both implementations can co-exist in
the same binary with minimal issues as long as they're kept strictly
separate -- and if someone tries to "cross the streams" then they'll get
Or, as I also said elsewhere, just pick one and stick to your guns.
Personally, I prefer throwing exceptions for that case; it's much safer
than allowing a buffer overflow.
> 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`.
+1. Although throw_exception itself is not entirely immune to the
problems above, it is at least a customisation point that only the
application author is allowed to touch, which is better than a macro.
[Although things get a bit dicier with shared objects and private
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk