<html>

<head>
<meta http-equiv="Content-Language" content="en-us">
<meta name="GENERATOR" content="Microsoft FrontPage 5.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>Diagnostics Small Issues</title>
</head>

<body>

<p>Doc. no.&nbsp;&nbsp; N2296=07-0156<br>
Date:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
<!--webbot bot="Timestamp" s-type="EDITED" s-format="%Y-%m-%d" startspan -->2007-06-24<!--webbot bot="Timestamp" endspan i-checksum="12404" --><br>
Project:&nbsp;&nbsp;&nbsp;&nbsp; Programming Language C++<br>
Reply to:&nbsp;&nbsp; Beman Dawes &lt;bdawes@acm.org&gt;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Benjamin Kosnik &lt;bkoz@redhat.com&gt;</p>
<h1>Diagnostics Enhancements; Resolution of Small Issues</h1>
<p><i>Note well:</i> The Proposed resolutions for many of these issues were 
drafted by Beman Dawes. The issue submitters do not necessarily agree with these 
PR's.</p>
<h2>Issue 1: Missing error_code::clear() specification</h2>
<p>&nbsp;The clear() function is shown in the synopsis but is otherwise unspecified.</p>
<p>Reported separately by Pete Becker, PJ Plauger, and Benjamin Kosnik.</p>
<h3>Proposed resolution</h3>
<p><i>To 19.4.2.3 Class error_code modifiers [syserr.errcode.modifiers], add:</i></p>
<blockquote>
  <p><u><font color="#009A9A"><code>void clear();</code></font></u></p>
  <blockquote>
    <p><u><font color="#009A9A"><i>postcondition:</i> <code>value() == 0 &amp;&amp; category() == posix_category</code></font></u></p>
  </blockquote>
</blockquote>
<h2>Issue 2: &lt;system_error&gt; should not force an implementation to expose &lt;cerrno&gt; 
macros</h2>
<p>In N2241, <code>enum posix_errno</code> did not specify values for each 
enumeration constant. Instead, a table of equivalence was provided showing the
<code>&lt;cerrno&gt;</code> E* macro the constant was to be equivalent to. During 
editing, that table was folded into the enum for brevity. That was a useful 
change, but had the unintended side effect of making it look like <code>&lt;system_error&gt;</code> 
must expose the <code>&lt;cerrno&gt; macros</code>, which was not the intent.</p>
<p>Submitted by PJ Plaguer</p>
<h3>Proposed resolution</h3>
<p><i>Change the form of <code>enum posix_errno</code> in 19.4 System error 
support [syserr] from:</i></p>
<blockquote>
  <p><code>enum posix_errno {<br>
&nbsp; address_family_not_supported = EAFNOSUPPORT,<br>
&nbsp; address_in_use = EADDRINUSE,<br>
&nbsp; ...</code></p>
</blockquote>
<p><i>To:</i></p>
<blockquote>
  <p><code>enum posix_errno {<br>
&nbsp; address_family_not_supported,&nbsp; // EAFNOSUPPORT<br>
&nbsp; address_in_use,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  // EADDRINUSE<br>
&nbsp; ...</code></p>
</blockquote>
<p><i>At the end of 19.4 System error support [syserr] add:</i></p>
<blockquote>
  <p>The value of each <code>enum posix_errno</code> constant shall be the same 
  as the equivalent <code>&lt;cerrno&gt;</code> macro shown as a comment in the above 
  synopsis.</p>
</blockquote>
<h2>Issue 3: &lt;functional&gt; hash specialization for error_code</h2>
<p>The member function <code>hash_value</code> should be replaced or supplemented by an 
explicit specialization of template class hash (in &lt;functional&gt;) so people can 
easily make an unordered container keyed on errors.</p>
<p>Submitted by PJ Plauger.</p>
<h3>Proposed resolution</h3>
<p>In 19.4.2.1 Class error_code overview [syserr.errcode.overview], removed:</p>
<blockquote>
<p><font color="#FF0000"><strike><code>size_t hash_value(const error_code&amp; ec);</code></strike></font></p>
</blockquote>
<p>In 19.4.2.6 Class error_code non-member functions [syserr.errcode.nonmembers], 
remove:</p>
<blockquote>
<p><font color="#FF0000"><strike><code>size_t hash_value(const error_code&amp; ec);</code></strike></font></p>
  <blockquote>
<p><font color="#FF0000"><strike><i>Returns: </i>A hash value representing ec.</strike></font></p>
  </blockquote>
</blockquote>
<p><i>In 20.5 Function objects [function.objects], paragraph 2, Header 
&lt;functional&gt; synopsis, add:</i></p>
<blockquote>
<p><u><font color="#009A9A"><code>template &lt;&gt; struct hash&lt;std::error_code&gt;;</code></font></u></p>
</blockquote>
<p><i>Change 20.5.15 Class template hash [unord.hash] as indicated:</i></p>
<blockquote>
  <p>The unordered associative containers defined in clause 23.4 use 
  specializations of hash as the default hash function. This class template is 
  only required to be instantiable for integer types (3.9.1), floating point 
  types (3.9.1), pointer types (8.3.1), and <code>std::string</code>, <code>
  std::u16string</code>, <code>std::u32string</code>, <strike>
  <font color="#FF0000">and</font> </strike> <code>std::wstring</code><font color="#009a9a">,</font><font color="#008080"><i> 
  </i><u>and <code>std::error_code</code></u></font>.</p>
</blockquote>

  <h2>Issue 4: Class error_code constructor should be explicit</h2>
  <p>Submitted by Alisdair Meredith.</p>
  <h3>Proposed resolution</h3>
  <p><i>Change 19.4.2.1 Class error_code overview [syserr.errcode.overview] as 
  indicated:</i></p>
<blockquote>
  <p><code><u><font color="#009A9A">explicit</font></u> error_code(posix_errno 
  val);</code></p>
</blockquote>
  <p><i>Change 19.4.2.2 Class error_code constructors [syserr.errcode.constructors] 
  paragraph 6 as indicated:</i></p>
<blockquote>
  <p><code><u><font color="#009A9A">explicit</font></u> error_code(posix_errno 
  val);</code></p>
</blockquote>
  <h2>Issue 5: Class error_code constructor(s?) should be constexpr</h2>
  <p>Objects of class <code>error_code</code> will commonly be constructed in 
  very low-level systems code where efficiency is a critical consideration. Thus 
  static initialization is quite desirable, and would remove the runtime and 
  code size cost implicit in the Library Working Group's switch to enumeration 
  style error values.</p>
  <p>A possible fix is to apply <code>constexpr</code>. Note, however, that 
  since <code>constexpr</code> is not yet a part of the working paper, and there 
  is no compiler available for testing, it isn't possible to tell if this change 
  will actually work as intended.</p>
  <p>Submitted by Chris Kohlhoff and Beman Dawes.</p>
  <h3>Proposed resolution</h3>
  <p><i>If N2235, </i>Generalized Constant ExpressionsRevision 5<i>, or 
  successor has been accepted for inclusion in the Working Paper, in 19.4.2.1 Class error_code overview [syserr.errcode.overview]&nbsp; 
  and 19.4.2.2 Class error_code constructors [syserr.errcode.constructors], add<code> </i>
  constexpr<i> </i></code><i>to the  constructors.</i></p>
  <h2><a name="Issue6">Issue 6</a>: Class error_category should be non-copyable</h2>
  <p>Class <code>error_category</code> equality is stated in terms of address 
  comparison, taking advantage of the C++ language rule that no two objects can 
  have the same address, and thus avoiding the possibility that independently 
  created user-defined error categories could inadvertently compare equal.</p>
  <p>Thus it makes no sense to allow <code>error_category</code> objects to be 
  copyable.</p>
  <p>Submitted by Pete Becker.</p>
  <h3>Proposed resolution</h3>
  <p><i>To 19.4.1.1 Class error_category overview [syserr.errcat.overview] 
  synopsis add:</i></p>
  <blockquote>
    <pre>error_category(const error_category&amp;) = delete;
error_category&amp; operator=(const error_category&amp;) = delete;</pre>
</blockquote>
<p><i>This also resolves <a href="#Issue14">issue 14</a>.</i></p>
<h2>Issue 7: error_code/posix_errno operator== semantics wrong</h2>
  <p>The semantics of the <code>error_code/posix_errno operator== </code>are 
  error prone, inherently non-portable, and do not support the most common 
  intended use case for writing portable code.</p>
  <p>For example, say the user writes:</p>
  <blockquote>
  <p><code>error_code ec = some_operation(...);<br>
  if ( ec )<br>
  {<br>
&nbsp; if ( ec == io_error )<br>
&nbsp; {<br>
&nbsp;&nbsp;&nbsp; // do something...<br>
&nbsp; }<br>
&nbsp; else<br>
&nbsp; {<br>
&nbsp;&nbsp;&nbsp; // do something else...<br>
&nbsp; }<br>
  }</code></p>
  </blockquote>
  <p>Submitted by Beman Dawes, in response to a question raised by Chris 
  Kohlhoff</p>
  <h3>Proposed resolution:</h3>
  <p><i>Editorial note: The <code>error_code/posix_errno</code> non-member 
  functions are currently described in the 19.4.2.5 Class error_code relational 
  operators [syserr.errcode.relational] section. They should be described in the 
  section that follows that, 19.4.2.6 Class error_code non-member functions [syserr.errcode.nonmembers].</i></p>
  <p><i>Change 19.4.2.5 Class error_code relational operators [syserr.errcode.relational] 
  paragraph 5 as indicated:</i></p>
  <blockquote>
    <p><code>bool operator==(const error_code&amp; ec, posix_errno en);<br>
    bool operator==(posix_errno en, const error_code&amp; ec);</code></p>
    <p><i>Returns:</i> <code><strike><font color="#FF0000">ec.value() == 
    static_cast&lt;error_code::value_type&gt;(en) &amp;&amp; ec.category() == posix_category</font></strike></code>
    <font color="#009A9A"><u><code>ec.posix() == en</code></u></font>.</p>
    <p><i>Throws:</i> Nothing.</p>
</blockquote>
  <h2>Issue 8: posix_errno enum minor issues</h2>
  <ul>
    <li><code>other</code> is too general a name to waste on a minor use, and is 
    not explicit enough.<br>
&nbsp;</li>
    <li>A value representing &quot;no error&quot; would make user code more readable, and 
    eliminate some static_casts.</li>
</ul>
  <p>Submitted by Beman Dawes</p>
  <h3>Proposed resolution</h3>
  <p><i>In 19.4 System error support [syserr] paragraph 2, 19.4.1.2, Class 
  error_category virtual members [syserr.errcat.virtuals] paragraph 3 (2 
  places), and the resolution to <a href="#Issue9">issue 9</a> (2 places), change</i>
  <code>other</code> <i>to</i> <code>no_posix_equivalent</code>.</p>
  <p><i>To 19.4 System error support [syserr], paragraph 2, change as indicated:</i></p>
  <blockquote>
    <pre>enum posix_errno {
  <font color="#008080"><u>no_error = 0,</u></font>
  address_family_not_supported = EAFNOSUPPORT,
  ...</pre>
</blockquote>
  <h2><a name="Issue9">Issue 9</a>: EOTHER hijacks POSIX macro space. </h2>
<p>The working draft specifies <code>other = EOTHER</code> in the specification 
of posix_errno in 19.4 System error support, with the specification that <code>
EOTHER</code> is not a POSIX-defined macro in 19.3 Error numbers. Earlier papers 
stated that this new macros will be added to the include file <code>cerrno</code>.
</p>
<p>The problem with this is that C++ is hijacking the POSIX macro space, which 
should be avoided as future versions of the POSIX standard may add more error 
macros, including <code>EOTHER</code>, but may have it mean something else.</p>
<p>Submitted by Benjamin Kosnik.</p>
<h3>Proposed resolution:</h3>
<p><i>Note: The resolution of Issue 8 changes </i><code>other</code><i> to </i>
<code>no_posix_equivalent</code><i>.</i></p>
<p><i>Change 19.3 Error numbers [errno], paragraph one, as indicated:</i></p>
<blockquote>
  <p>The header <code>&lt;cerrno</code>&gt; is described in (Table 29). Its contents 
  are the same as the POSIX header <code>&lt;errno.h&gt;</code>, except that <code>
  errno</code> shall be defined as a macro<font color="#FF0000"><strike>, and an 
  additional macro EOTHER shall be defined to represent errors not specified by 
  the POSIX standard</strike></font>. [ Note: The intent is to remain in close 
  alignment with the POSIX standard. end note ]</p>
</blockquote>
<p><i>From 19.3 Error numbers [errno], Header &lt;cerrno&gt; synopsis, strike </i>
<font color="#FF0000"><strike>EOTHER</strike></font><i>.</i></p>
<p><i>Change 19.4 System error support [syserr], Header &lt;system_error&gt; synopsis 
as indicated:</i></p>
<blockquote>
  <p><code>other =</code> <strike><font color="#FF0000"><code>EOTHER</code></font></strike>
  <font color="#009A9A"><u><i>unspecified-value</i></u></font><code>,</code></p>
</blockquote>
<p><i>Following 19.4 System error support [syserr], Header &lt;system_error&gt; 
synopsis, add:</i></p>
<blockquote>
<p><u><font color="#009A9A">The value of <code>posix_errno::other</code> shall 
be non-zero and not equal to any other <code>posix_errno</code> value.</font></u></p>
</blockquote>
<h2>Issue 10: header dependencies are non-trivial. </h2>
<p>In section <a href="http://19.4.2.6" target="_blank">19.4.2.6</a> Class 
error_code non-member functions, an ostream inserter for <code>error_code</code> 
is defined for the primary ostream template. This will necessitate the inclusion 
of the <code>ostream</code> include file, which has large dependencies on other 
standard library features. The practical result is that the <code>system_error</code> 
include, far from being a lightweight, stand-alone error-reporting facility, 
will instead come with significant compile time cost.</p>
<p>Submitted by Benjamin Kosnik.</p>
<blockquote>
  <p><i>Fix:</i> Move the <code>error_code</code> inserter to the <code>ostream</code> 
  include file, or relax the requirements such that only <code>char</code> and
  <code>wchar_t</code> specializations are required. </p>
</blockquote>
  <h3>Proposed resolution:</h3>
  <p><span style="font-style:italic">To be supplied.</span></p>
<h2>Issue 11: overly complex <code>error_code::value_type</code> with circular 
dependencies.</h2>
<p>Section <a href="http://19.4.2.1" target="_blank">19.4.2.1</a> specifies
<code>error_code::value_type</code> as <code>typedef int_least32_t value_type;</code>. 
However, this type is used in <code>error_category</code>, which has to be 
defined before any of the trivial members in <code>error_code</code> can be made 
inline. </p>
<p>In addition, this complexity results in unsightly casting in the <code>
error_code</code> relational operators and constructor specifications.</p>
<p><i>Possible Fix: </i>Assume <code>error_code::value_type</code> is of type
<code>int</code>, as specified by both C and POSIX.</p>
<p>Submitted by Benjamin Kosnik.</p>
<p>Beman Dawes comments: The typedef is a historical artifact. An int is 
sufficient for all operating systems I am aware of. I support the change.</p>
<h3>Proposed resolution:</h3>
<p><i>Change 19.4.2.1 Class error_code overview [syserr.errcode.overview] as 
indicated:</i></p>
<blockquote>
  <pre>namespace std {

  class error_code {
  public:
    <strike><font color="#FF0000">typedef int_least32_t value_type;</font></strike>

    // constructors:
    error_code();
    error_code(<strike><font color="#FF0000">value_type</font></strike> <font color="#009A9A"><u>int</u></font> val, const error_category&amp; cat);
    error_code(posix_errno val);

    // modifiers:
    void assign(<strike><font color="#FF0000">value_type</font></strike> <font color="#009A9A"><u>int</u></font> val, const error_category&amp; cat);
    error_code&amp; operator=(posix_errno val);
    void clear();

    // observers:
    <strike><font color="#FF0000">value_type</font></strike> <font color="#009A9A"><u>int</u></font> value() const;
    cont error_category&amp; category() const;
    posix_errno posix() const;
    string message() const;
    wstring wmessage() const;
    operator unspecified-bool-type const;

    // relational operators:
    bool operator==(const error_code&amp; rhs) const;
    bool operator!=(const error_code&amp; rhs) const;

    private:
    <strike><font color="#FF0000">value_type</font></strike> <font color="#009A9A"><u>int</u></font> val_; // exposition only
    const error_category&amp; cat_; // exposition only
  };

  template &lt;class charT, class traits&gt;
    basic_ostream&lt;charT,traits&gt;&amp;
      operator&lt;&lt;(basic_ostream&lt;charT,traits&gt;&amp; os, const error_code&amp; ec);

  size_t hash_value(const error_code&amp; ec);

} // namespace std</pre>
</blockquote>
<p><i>Change 19.4.2.2 Class error_code constructors [syserr.errcode.constructors] 
as indicated:</i></p>
<blockquote>
  <p><code>error_code(<strike><font color="#FF0000">value_type</font></strike>
  <font color="#009A9A"><u>int</u></font> val, const error_category&amp; cat);</code></p>
</blockquote>
<p><i>Change 19.4.2.3 Class error_code modifiers [syserr.errcode.modifiers] as 
indicated:</i></p>
<blockquote>
  <p><code>void assign(<strike><font color="#FF0000">value_type</font></strike>
  <font color="#009A9A"><u>int</u></font> val, const error_category&amp; cat);</code></p>
</blockquote>
<p><i>Change 19.4.2.1 Class error_code overview [syserr.errcode.overview] as 
indicated:</i></p>
<blockquote>
  <p><strike><font color="#FF0000"><code>value_type</code></font></strike><code>
  <font color="#009A9A"><u>int</u></font> value() const;</code></p>
</blockquote>
<h2>Issue 12: Missing throw specifications.</h2>
<p>In <a href="http://19.4.1.2" target="_blank">19.4.1.2</a> Class 
error_category virtual members, all member functions are defined to not throw, 
but do not have <code>throw()</code> specifications. </p>
<p>The same hold for <code>error_code</code> member functions that are modifiers 
and observers. i.e, sections <a href="http://19.4.2.3" target="_blank">19.4.2.3</a> 
and <a href="http://19.4.2.4" target="_blank">19.4.2.4</a>.</p>
<p>Submitted by Benjamin Kosnik.</p>
<blockquote>
  <p><i>Proposed Fix:</i> Add in missing <code>throw()</code> specifications.</p>
</blockquote>
<h3>Proposed resolution:</h3>
<p><i>No action necessary.</i></p>
<p><i>The Working Paper is inconsistent in its use of&nbsp; <code>throw()</code> 
specifications. Many LWG members prefer the &quot;Throws: Nothing&quot; specification as 
used in the current working paper wording for diagnostics.</i></p>
<h2>Issue 13: Missing <code>system_error</code> constructor.</h2>
<p>All existing classes derived from <code>std::exception</code> provide either 
a default constructor or a constructor taking a single <code>const std::string&amp;</code> 
parameter. The current specification for <code>system_error</code> breaks with 
this.</p>
<p>Submitted by Benjamin Kosnik.</p>
<blockquote>
  <p><i>Proposed Fix:</i> Add a constructor to <code>system_error</code> that takes a<code> const 
  std::string&amp;</code> argument.</p>
</blockquote>
<h3>Proposed resolution:</h3>
<p><i>No action necessary.</i></p>
  <p><i>The design of the constructors, including order of 
  arguments, was a considered 
  decision after discussion with Peter Dimov and others on the Boost list. A 
  primary objective of <code>system_error</code> is to report an <code>
  error_code</code>. We don't want to encourage construction of <code>
  system_error</code> objects that don't have one. Thus the constructors all 
  take <code>error_code</code> or equivalent arguments first in addition to the 
  what string argument. Not supplying a default constructor avoids the 
  nonsensical construction of system_error representing &quot;no error&quot;.</i></p>
<h2><a name="Issue14">Issue 14</a>: <code>error_category</code> equality via address comparison.</h2>
<p>Section <a href="http://19.4.1.3" target="_blank">19.4.1.3</a> Class 
error_category non-virtual members specifies address comparisons between <code>
error_category</code> base objects to determine equality and inequality. This 
can be fragile or difficult in shared memory or distributed systems, and may 
lead to incorrect results for equivalent <code>error_category</code> objects.</p>
<p>Submitted by Benjamin Kosnik.</p>
<blockquote>
  <p><i>Fix: </i>Equality compare on internal details of the message catalog 
  characteristics.</p>
</blockquote>
  <h3>Proposed resolution:</h3>
  <p><i>Resolved by <a href="#Issue6">Issue 6</a>: Class error_category should 
  be non-copyable. No further action needed.</i></p>
<h2>Issue 15: Extending <code>error_code::value_types</code> constants and 
user-defined <code>error_category</code> objects.</h2>
<p>Section 19.4 specifies <code>posix_errno</code> as an enum. As such, there is 
no way to extend it for native error values, which will presumably be in the 
form of another enum, in some user-defined space. </p>
<blockquote>
<p><i>Yes, but that seems 
unavoidable fallout from the use of an enum as mandated by the LWG. Also, it is 
possible, if tedious, for another enum to refer to the <code>posix_errno</code> 
values one-by-one.</i></p>
</blockquote>
<p>Section <a href="http://19.4.1.4" target="_blank">19.4.1.4</a> Error category 
objects vaguely specifies <code>posix_category</code> and <code>native_category</code> 
as external objects. As such, the implementation details are likely to remain 
private, making simple derivation and extension tricky or difficult.</p>
<blockquote>
<p><i>The 
specification of <code>posix_category</code> and <code>native_category</code> 
is:</i></p>
<blockquote>
  <pre>extern const error_category&amp; posix_category;
extern const error_category&amp; native_category;</pre>
</blockquote>
<p><i>That doesn't seem vague. The critical member functions of <code>
error_category</code> are public virtuals; that seems sufficient access to 
functionality without violating encapsulation.</i></p>
</blockquote>
<p>Submitted by Benjamin Kosnik.</p>
<h3>Proposed resolution:</h3>
<p><i>No action necessary. See above comments for rationale.</i></p>
<h2>Issue 16: POSIX versus native <code>error_category</code>.</h2>
<p>Should <code>posix_category</code> and <code>native_category</code> be able 
to have the same address?</p>
<blockquote>
<p><i>In theory, yes. In practice, no, because no real 
operating system exactly implements the POSIX specification. Real operating 
systems at the minimum add some of their own error codes.</i></p>
</blockquote>
<p>Should the member function <code>error_category::posix</code> exist for the 
predefined object <code>posix_category</code>? Isn't this a no-op, and best 
added to the class implementing <code>native_category</code>?</p>
<blockquote>
<p><i>The <code>
error_category</code> virtuals exist to support the equivalent <code>error_code</code> 
member functions. This mechanism unravels if <code>error_category::posix</code> 
isn't present for all error categories.</i></p>
</blockquote>
<p>Should the division be between underlying system errors needed by the C++0x 
standard library and user-defined error messages, instead of between POSIX and 
native?</p>
<blockquote>
<p><i>Early versions of the current design divided the world along 
standard library / native lines. The design evolved into a POSIX / native / 
user-defined breakdown because it met specific needs of users and third-party 
library suppliers, who must deal with a variety of real-world use cases. That 
isn't to say another design wouldn't work, but this design is known to work and 
represents successful existing practice.</i></p>
</blockquote>
<p>Submitted by Benjamin Kosnik.</p>
<h3>Proposed resolution:</h3>
<p><i>No action necessary. See above comments for rationale.</i></p>
<h2>Issue 17: Broken <code>error_category::message</code> member functions.</h2>
<p>Section <a href="http://19.4.1.2" target="_blank">19.4.1.2</a> Class 
error_category virtual members defines members <code>message</code> and <code>
wmessage</code>, and notes an intention to provide a locale-specific string. 
However, there is no indication that this is integrated into the existing 
standard library infrastructure for locale, ie <code>std::locale</code>.</p>
<p>There are two distinct issues: one, construction of <code>error_category</code> 
would have to take some kind of <code>std::locale</code> parameter, some kind of 
getter/setter would have to exist to provide locale data, or <code>message</code> 
would have to take a <code>std::locale</code> argument. This last option would 
require serious re-work of the <code>system_error::what</code> member function.</p>
<p>The second issue is code conversion so that <code>wmessage</code> could 
return a wide string from a message catalog. The use case for this is 
theoretical at the moment, as wide-character message catalogs are not known. For 
this, <code>std::codecvt</code> would be the preferred mechanism, and that 
depends on three template parameters. If this route is followed, it may make 
sense to templatize the entire class, and separate out <code>message</code> for
<code>char</code> instantiations and <code>wmessage</code> for <code>wchar_t</code> 
instantiations. </p>
<p>Note that <code>error_code</code> has these same member functions, which 
forward to the <code>error_category</code> member functions, so this could be 
considered a defect in both class specifications.</p>
<p>Submitted by Benjamin Kosnik.</p>
  <h3>Proposed resolution:</h3>
  <p><i>Change 19.4.1.1 Class error_category overview [syserr.errcat.overview] 
  paragraph 1 as indicated:</i></p>
  <blockquote>
    <pre><font color="#FF0000"><strike>virtual wstring wmessage(error_code::value_type ev) const = 0;</strike></font></pre>
</blockquote>
  <p><i>Change </i>19.4.1.2 Class error_category virtual members [syserr.errcat.virtuals] 
  paragraph 4 as indicated:</p>
  <blockquote>
    <pre><font color="#FF0000"><strike>virtual wstring wmessage(error_code::value_type ev) const = 0;</strike></font></pre>
</blockquote>
  <p><i>Change 19.4.2.1 Class error_code overview [syserr.errcode.overview] 
  paragraph 1 as indicated:</i></p>
  <blockquote>
    <pre><font color="#FF0000"><strike>wstring wmessage() const;</strike></font></pre>
</blockquote>
  <p><i>Change 19.4.2.4 Class error_code observers [syserr.errcode.observers] 
  beginning at paragraph 8 as indicated:</i></p>
  <blockquote>
    <pre><font color="#FF0000"><strike>wstring wmessage() const;</strike></font></pre>
    <blockquote>
  <p><font color="#FF0000"><strike><i>Returns</i>: <code>
  category().wmessage(value())</code>.</strike></font></p>
  <p><font color="#FF0000"><strike><i>Throws:</i> Nothing.</strike></font></p>
    </blockquote>
</blockquote>
  <p><i>For the locale issue, no action necessary. This underspecification of 
  &quot;locale-specific&quot; was deliberate; there doesn't appear to be a solution ready 
  for standardization, and in the absence of a standard solution, library 
  suppliers know best how to meet their user's needs.</i></p>
  <p><i>Rationale for removing wmessage: It is difficult or impossible to 
  implement well on some operating systems. None of the 
  current standard exception classes worry about wide messages, so a fix in one 
  particular place only probably isn't the right approach.</i></p>
<h2>Issue 18: <code>system_error::what</code> and constructors</h2>
<p>In <a href="http://19.4.3.2" target="_blank">19.4.3.2</a> Class system_error 
members, the constructor definitions and <code>what</code> specification collude 
to force exception-unsafe behavior, and multiple <code>std::string</code> data 
members.</p>
<blockquote>
<p><i>Exception safety is dealt with by the proposed resolution. The data 
members are not specified; implementations are free to use a std::string or some 
completely different mechanism. Implementations will presumably use lazy 
evaluation, so much of the cost will only occur if what() is actually called.</i> <i>No action necessary.</i></p>
</blockquote>
<p>This in effect mandates elaborate string modification as part of <code>
system_error::what</code>, which may cause unanticipated exceptions to occur, in 
addition to being inefficient.</p>
<blockquote>
<p><code>system_error::what</code><i>&nbsp; and </i><code>code</code><i> do 
specify throw() in the synopsis to deal with the exception issue, but not in the 
member descriptions. See proposed resolution. The string modification is 
extremely valuable to users, and any inefficiency is minor compared to the 
general overhead of an exception being thrown.</i> <i>No additional action necessary.</i></p>
</blockquote>
<p>These specifications are a break with the existing <code>stdexcept</code> 
requirements and the exception hierarchy design philosophy: by making <code>what</code> 
virtual, users can reasonably expect to have derived classes with different 
return strings from <code>what</code>. Indeed, that's the point.</p>
<blockquote>
<p><i>what() is virtual in the base class, so is virtual in class </i><code>
system_error</code><i> too.</i> <i>And</i> <code>system_error::what</code><i> 
does normally return a different string than </i><code>runtime_error::what</code>. <i>No action necessary.</i></p>
</blockquote>
<p>In addition, with all these additional requirements, there still exists no 
way to pass in locale-specific strings.</p>
  <blockquote>
<p><i>See issue 17.</i></p>
  </blockquote>
<h3>Proposed resolution:</h3>
<p><i>Change 19.4.3.2 Class system_error members [syserr.syserr.members], 
paragraph 4, as indicated:</i></p>
<blockquote>
<p><code>const error_code&amp; code() const <u><font color="#009A9A">throw()</font></u>;</code></p>
</blockquote>
<p><i>Change 19.4.3.2 Class system_error members [syserr.syserr.members], 
paragraph 5, as indicated:</i></p>
<blockquote>
<p><code>const char *what() const <u><font color="#009A9A">throw()</font></u>;</code></p>
</blockquote>
<p><i>No additional action necessary. See above comments for rationale.</i></p>
<h2>Issue 19: Should classes error_code and error_category be less-than 
comparable?</h2>
<p>The Boost version provides <code>operator&lt;</code>&nbsp; for both, allowing objects of class
<code>error_code</code> to 
be easily used as keys for associative containers. I can't remember any rationale for removing them from 
the proposal; perhaps it was a simple oversight. It seems to me they should be 
provided as a courtesy if nothing else. On the other hand, users can provide 
their own compare functions if needed.</p>
<p>Submitted by Beman Dawes.</p>
  <h3>Proposed resolution:</h3>
  <p><span style="font-style:italic">To be supplied.</span></p>
<hr>

</body>

</html>