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