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]

Re: constexpr vs. non-literal library types round two


On Tue, Nov 9, 2010 at 3:04 PM, Benjamin Kosnik <bkoz@redhat.com> wrote:
>
> 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?

That was part of the original constexpr design that was voted on.
The rationale is in section 4.3.1 of

   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf

since then, lots of things have happened to constexpr :-)
The thinking at the time was that we wanted to preserve "copying semantics"
(for example, copy ctor was required trivial and made constexpr because
the compiler knows the value layout and can make as many copies
as it wants  in compile-time evaluation without problems.)
I still think that is a reasonable restriction.

The trouble in this specific case seems to be that shared_ptr obviously
is not a literal types, but we would like to statically initialize some
objects of that type.

>
> 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)

complex should not have one (well, it is implementation defined whether it
has one, but it should not)

> 5) once_flag (has deleted copy)
> 6) mutex (has deleted copy ctor)
> 7) pair (has copy ctor)

ditto for pair.

> 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,

I believe we do need a side-effect free copy constructor though.

>
> 2) 5.19 p 2, constant expressions: add
>
> --- expressions that use or call non-literal class types with
> user-defined (and not defaulted) destructors.

A question here is whether a destructor would have to run after
a copy is made.  In particular, I'm reluctant to make any change that
precludes uses of values of literal types as template arguments
(e.g. I would like to be able to use a value of type complex<int> as
a template argument, not just integers or the like.)

I believe the uses of literal types in static initialization is to some degree
orthogonal to the question of constant expressions, so I would like
that your concern be addressed without changing what constitutes
a constant expression.  For example, one can have the rule that for the
purpose of static initialization, `literalness' (is that a word?) of a type
is needed except that trivial destructor is not enforced -- call that
an `almost literal type' if a word is needed.


>
> 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.))

OK.

>
> 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.

I suspect people would ask that if a vote is expected.

-- Gaby


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