[v3] system_error, round one

Peter Dimov pdimov@mmltd.net
Tue May 15 17:41:00 GMT 2007


Benjamin Kosnik wrote:
>>> +  const char*
>>> +  system_error::what() const throw()
>>> +  {
>>> +    // XXX logic seems wrong as written in draft, need to
>>> +    // concatenate message?
>>> +    string __s = runtime_error::what();
>>> +    try
>>> +      {
>>> + if (this->code())
>>> +   {
>>> +     if (!__s.empty())
>>> +       __s += " : ";
>>> +     __s += this->code().message();
>>> +   }
>>> +      }
>>> +    catch (...) {  }
>>> +    return __s.c_str();
>>> +  }
>>
>> Besides the dangling .c_str, you have an additional problem here: the
>> construction of __s can throw. What's wrong with the suggested
>> implementation in N2241
>
> currently, there is an embedded string object (which is not mandated
> in the standard), but it is private. We will have to make it
> protected and mutable in order to be used in what, which is marked
> const.

You mean the private string member in std::runtime_error?

I think that the idea of the suggested implementation in N2241 is to be 
non-intrusive; that is, to introduce a separate string member 'msg' that 
caches the result of system_error::what.

You can't reuse the string that runtime_error::what uses since the 
postcondition of system_error's constructors will no longer hold after 
system_error::what. This could be considered legal if one squints hard 
enough, though.

It's possible to do the concatenation in the constructors in order to avoid 
marking 'msg' as mutable, but this will preclude the option of providing a 
what() overload that takes a locale.

There's also the issue that a plain string member implies a potentially 
throwing copy constructor... not a problem if the string is known to be 
reference counted.



More information about the Libstdc++ mailing list