Boost logo

Boost :

Subject: Re: [boost] [system] The new Boost.System is now ready
From: Peter Dimov (lists_at_[hidden])
Date: 2018-10-08 14:22:58

Gavin Lambert wrote:

> Another option might be to output a generic snprintf message along the
> lines of "error %s:%d" (category name and code, similar to
> operator<<(error_code) but avoiding that specific implementation). This
> might be slightly more user-useful, if there isn't a fallback to the
> allocating overload; with the caveat that it would make it harder for the
> caller to detect when they needed to decide whether to do that. So this
> choice is probably better left to the caller anyway.

This is a legitimate option.

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

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.

One argument in favor of "error %s:%d" is that it makes it obvious that the
category needs to be updated, or stated differently, one argument in favor
is that it would force people to update their categories.

On the other hand, one argument against is that it would force people to
update their categories, and people don't want to be forced to needlessly
change working code. :-)

Boost list run by bdawes at, gregod at, cpdaniel at, john at