Subject: Re: [boost] [system] The new Boost.System is now ready
From: Gavin Lambert (boost_at_[hidden])
Date: 2018-10-08 23:24:07
On 9/10/2018 03:22, Peter Dimov wrote:
> I admit I haven't given this much thought because the assumption was
> that having categories that do not override the new `message` would be
> just a temporary state of affairs. The desire to not allocate comes at
> least as much from people writing categories as from those using them;
> the objection was that even when your category _could_ return literals
> it had no way to do so.
>
> The default implementation comes into play in a scenario in which the
> client has "upgraded" to the new overload, but the (third party - system
> and generic are already up to date) category hasn't, and I've decided to
> preserve the message as much as possible rather than to enforce the "no
> allocation" property at the expense of losing the message. Maybe this is
> not the correct choice, I'm not sure. But again, this scenario should
> eventually never occur as third-party categories are updated.
I'm not sure either (so I hope that others chime in with their thoughts
-- especially Niall, since he's worked with many of the people who I
imagine would have strong opinions one way or the other).
A related hesitation that I have is that while the caller can ask if
there is a literal message (by passing nullptr,0) they can't otherwise
ask for a possibly-dynamic-but-non-allocating (eg. snprintf) message.
So if this fallback to the allocating-message() exists, it means that
the caller either has to ask only for literal messages (thus failing to
get snprintf messages) or they have to rely on out-of-band knowledge
that the specific category of the error happens to support
non-allocating messages, or risk hitting an undesirable allocating path.
On the other hand, people who care about that sort of thing are perhaps
more likely to use a custom STL or carefully chosen libraries known to
not generate such errors, so perhaps this is not worth worrying about.