This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]