On Wed, Sep 19, 2018 at 11:57 AM Peter Dimov via Boost < boost@lists.boost.org> wrote:
One of the objections against
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 std::error_category):
virtual char const* message( int ev, char* buffer, size_t len ) noexcept;
This is modeled after the glibc-specific version of strerror_r (and in fact 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 `buffer`.
Comments?
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?) --charley