[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