Title
Presentation of "program defined classes derived from error_category" [syserr.errcat.derived] unclear and contains mistakes
Status
new
Section
[syserr.errcat.derived]
Submitter
Thomas Köppe

Created on 2017-09-20.00:00:00 last changed 85 months ago

Messages

Date: 2017-11-09.15:13:04

[ 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.

Date: 2017-09-20.00:00:00

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:

  1. In [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[syserr.errcat.derived]. [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]

  2. In [syserr.errcat.derived], change:

    virtual const char* name() const noexcept override  = 0;
    

    -1- Returns: A string naming the error category.

    virtual error_condition default_error_condition(int ev) const noexcept override;
    

    -2- Returns: An object of type error_condition that corresponds to ev.

    virtual bool equivalent(int code, const error_condition& condition) const noexcept override;
    

    -3- Returns: true if, for the category of error represented by *this, code is considered equivalent to condition; otherwise, false.

    virtual bool equivalent(const error_code& code, int condition) const noexcept override;
    

    -4- Returns: true if, for the category of error represented by *this, code is considered equivalent to condition; otherwise, false.

History
Date User Action Args
2017-11-09 15:13:04adminsetmessages: + msg9520
2017-09-20 00:00:00admincreate