Subject: Re: [boost] [system] A non-allocating message() overload
From: charleyb123 (charleyb123_at_[hidden])
Date: 2018-09-19 18:24:09
On Wed, Sep 19, 2018 at 11:57 AM Peter Dimov via Boost <
> One of the objections against <system_error> is that message() needs to
> allocate memory, because it returns an std::string. This is true even for
> user-defined categories that can implement it without allocating, with a
> static message table.
> To address this, I'm thinking of adding the following overload to
> boost::system::error_category (with the intent of proposing it for
> virtual char const* message( int ev, char* buffer, size_t len )
> This is modeled after the glibc-specific version of strerror_r (and in
> has the exact same signature and behavior). If the implementation has a
> static character literal corresponding to `ev`, it returns it directly. If
> not, it composes an error message into the provided buffer, then returns
I *really* like this interface (pass in buffer-to-be-populated, or return
internal static buffer).
Am I correct in assuming the user could then:
ec = ...;
char* my_buf = ...;
size_t my_buf_size = ...;
char const* msg = ec.message(SOME_ERR_ENUM, my_buf, my_buf_size);
if(msg != my_buf)
// ...delete "my_buf", it is not needed
// TRUST that "msg" is still valid (must reference static-internal-buffer,
or is "my_buf"
Question: Is there a *guarantee* that 'message()' never return 'nullptr'?
(Is that ever desired?)