error_category
default constructorSection: 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?
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?
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.
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; }; }
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
.
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
.