This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
constexpr vs. non-literal library types round two
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: jason at redhat dot com, libstdc++ at gcc dot gnu dot org, Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Date: Tue, 9 Nov 2010 15:04:08 -0600
- Subject: constexpr vs. non-literal library types round two
Hey! I think I am arriving at an understanding of this issue.
I believe that non-literal types cannot be used to create constexpr
variables if they have a non-trivial destructor. (As pointed out by
Jason in private email.) This is not currently specified in the standard
that I can see. If I'm wrong, can somebody help me out?
This seems obvious: a non-trivial destructor means that the object has
to be registered for destruction. No compiler magic allowed! Ipso
Facto, no constexpr construction is allowed.
Right now we allow constexpr construction of the following non-literal
types:
1) duration (has defaulted dtor, user-defined copy ctor)
2) time_point (has user-defined copy)
3) atomic (has defaulted dtor, defaulted default ctor, deleted copy
ctor)
4) complex (has user-defined copy)
5) once_flag (has deleted copy)
6) mutex (has deleted copy ctor)
7) pair (has copy ctor)
8) tuple (has defaulted copy, move ctor)
So, the language changes that I would expect to see would be:
1) 3.9 p 10, literal type: remove the first point, ie:
â a trivial copy constructor,
2) 5.19 p 2, constant expressions: add
--- expressions that use or call non-literal class types with
user-defined (and not defaulted) destructors.
With these changes, I believe the current g++/libstdc++ implementation
would conform with a future version of ISO C++0x.
(ie N3126, modulo the library changes proposed in D3186, and also
removing the unique_ptr and weak_ptr constexpr constructors (which I
will add to D3186 on confirmation of the contents of this email.))
Is it worth getting a document number so that these small changes can
get nailed down on the language side in a post-Batavia paper? Then we
will have our implementation fully-described in standard-ese. Which is
my goal here.
-benjamin