Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at