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.