This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.
Section: 126.96.36.199 [syserr.errcat.derived] Status: New Submitter: Thomas Köppe Opened: 2017-09-20 Last modified: 2017-11-09
View all issues with New status.
The presentation of section [syserr.errcat.derived] is currently somewhat problematic:
It is not clear why this section exists and what it is specifying. Presumably, it is the subject of the phrase "in this subclause" of the sibling section [syserr.errcat.overview], but that's confusing (because this would require the interpretation of "this subclause" as the containing superclause). It would be an improvement to say "shall behave as specified in [syserr.errcat.derived]" in the introduction.
The current wording of [syserr.errcat.derived] requires that derived classes keep the name member function pure-virtual, making it impossible to have non-abstract derived classes. This appears to be an editorial error. Surely name should just not be required to be pure-virtual.
There seems to be no requirement concerning the message virtual member function.
We should use override rather than virtual.
I would welcome a short, introductory paragraph in [syserr.errcat.derived] that states (non-redundantly) that the following are requirements on users' derived classes.
Partial wording proposal:
In 188.8.131.52 [syserr.errcat.overview] p1, change:
-1- The class error_category serves as a base class for types used to identify the source and encoding of a particular category of error code. Classes may be derived from error_category to support categories of errors in addition to those defined in this International Standard. Such classes shall behave as specified in
this subclause. [Note: error_category objects are passed by reference, and two such objects are equal if they have the same address. This means that applications using custom error_category types should create a single object of each such type. — end note]
In 184.108.40.206 [syserr.errcat.derived], change:
virtualconst char* name() const noexcept = 0;
-1- Returns: A string naming the error category.
virtualerror_condition default_error_condition(int ev) const noexcept ;
-2- Returns: An object of type error_condition that corresponds to ev.
virtualbool equivalent(int code, const error_condition& condition) const noexcept ;
-3- Returns: true if, for the category of error represented by *this, code is considered equivalent to condition; otherwise, false.
virtualbool equivalent(const error_code& code, int condition) const noexcept ;
-4- Returns: true if, for the category of error represented by *this, code is considered equivalent to condition; otherwise, false.
[2017-11 Albuquerque Wednesday night issues processing]
Priority set to 3.
Jonathan to talk to Chris K and Walter about writing a paper describing the use of error_code, error_condition and defining your own.