This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++14 status.

### 2145. `error_category` default constructor

Section: 19.5.3 [syserr.errcat] Status: C++14 Submitter: Howard Hinnant Opened: 2012-03-21 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [syserr.errcat].

View all issues with C++14 status.

Discussion:

Should `error_category` have a default constructor?

If you look at the synopsis in 19.5.3.1 [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 16.3.3.4 [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 11.4.5 [class.ctor]/5 and 11.4.7 [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, 19.5.3.1 [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 {
   >       public:
   >         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 19.5.3.2 [syserr.errcat.virtuals] p1 insert a new prototype description as indicated:

   >     virtual ~error_category();

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

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

   >     constexpr error_category() noexcept;

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