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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk