2145. error_category default constructor

Section: 22.5.2 [syserr.errcat] Status: C++14 Submitter: Howard Hinnant Opened: 2012-03-21 Last modified: 2016-02-10

Priority: Not Prioritized

View all other issues in [syserr.errcat].

View all issues with C++14 status.


Should error_category have a default constructor?

If you look at the synopsis in [syserr.errcat.overview], it appears the answer is no. There is no default constructor declared and there is another constructor declared (which should inhibit a default constructor).

However in paragraph 1 of the same section, descriptive text says:

Classes may be derived from error_category to support categories of errors in addition to those defined in this International Standard.

How shall classes derived from error_category construct their base?

Jonathan Wakely: In N2066 error_category was default-constructible. That is still the case in N2241, because no other constructor is declared. Then later N2422 (issue 6) declares the copy constructor as deleted, but doesn't add a default constructor, causing it to be no longer default-constructible. That looks like an oversight to me, and I think there should be a public default constructor.

Daniel: A default-constructor indeed should be provided to allow user-derived classes as described by the standard. I suggest this one to be both noexcept and constexpr. The latter allows user-derived non-abstract classes to take advantage of the special constant initialization rule of [basic.start.init] p2 b2 for objects with static (or thread) storage duration in namespace scope. Note that a constexpr constructor is feasible here, even though there exists a non-trivial destructor and even though error_category is not a literal type (see std::mutex for a similar design choice).

In addition to that the proposed resolution fixes another minor glitch: According to [functions.within.classes] virtual destructors require a semantics description.

Alberto Ganesh Barbati: I would suggest to remove =default from the constructor instead. Please consider that defaulting a constructor or destructor may actually define them as deleted under certain conditions (see 15.1 [class.ctor]/5 and 15.4 [class.dtor]/5). Removing =default is easier than providing wording to ensures that such conditions do not occur.

[2012-10 Portland: move to Ready]

The issue is real and the resolution looks good.

Are there similar issues elsewhere in this clause?

Potential to add constexpr to more constructors, but clearly a separable issue.

[2013-04-20 Bristol]

Proposed resolution:

This wording is relative to N3376.

  1. Modify the class error_category synopsis, [syserr.errcat.overview] as indicated: [Drafting note: According to the general noexcept library guidelines destructors should not have any explicit exception specification. This destructor was overlooked during the paper analysis — end note]

    namespace std {
      class error_category {
        constexpr error_category() noexcept;
        virtual ~error_category() noexcept;
        error_category(const error_category&) = delete;
        error_category& operator=(const error_category&) = delete;
        virtual const char* name() const noexcept = 0;
        virtual error_condition default_error_condition(int ev) const noexcept;
        virtual bool equivalent(int code, const error_condition& condition) const noexcept;
        virtual bool equivalent(const error_code& code, int condition) const noexcept;
        virtual string message(int ev) const = 0;
        bool operator==(const error_category& rhs) const noexcept;
        bool operator!=(const error_category& rhs) const noexcept;
        bool operator<(const error_category& rhs) const noexcept;
  2. Before [syserr.errcat.virtuals] p1 insert a new prototype description as indicated:

    virtual ~error_category();

    -?- Effects: Destroys an object of class error_category.

  3. Before [syserr.errcat.nonvirtuals] p1 insert a new prototype description as indicated:

    constexpr error_category() noexcept;

    -?- Effects: Constructs an object of class error_category.