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

Subject: Re: [boost] [system] The new Boost.System is now ready
From: Gavin Lambert (boost_at_[hidden])
Date: 2018-10-08 02:52:20

On 8/10/2018 12:37, Peter Dimov wrote:
> The first specification ([syserr.errcat.virtuals]) describes the default 
> implementation in error_category. This exists for backward 
> compatibility. Since user-defined categories that only override the 
> current `message` already exist, if the make the new overload pure, 
> we'll break them. So we supply a default that calls the string overload 
> and copies the string into the buffer.

While I can understand the desire to provide a useful message in that 
case, doesn't it defeat the purpose of providing a no-allocation overload?

Granted that if it doesn't do this, then the caller would presumably get 
back an empty string ("oops, we couldn't get an error message without 
allocating") and then have to decide whether to call the allocating 
overload themselves or just live without the message.

Which is perhaps more effort and less transparent, but I assume it 
probably would be the preferred choice for the people who wanted 
zero-allocation in the first place.

There doesn't otherwise appear to be any way to "opt-out" of allocation.

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.