Gavin Lambert wrote:
Also, in P1197R0, perhaps I'm missing some context (not having a copy of the standard handy) but it seems peculiar that the Effects of the two new message() overloads are ordered differently with respect to possibly returning a literal message pointer, ignoring buffer and len. Why is it that the second can do this but not the first?
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. Since we have no idea what the returned string is, we can't return a literal under any circumstances. (Except on exception.) The second specification ([syserr.errcat.derived]) describes what classes derived from error_category need to do.