Re: [boost] [system] The new Boost.System is now ready

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 
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.

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. :-)