Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.std.c++ > #335

Re: Defect report: constexpr and mutable members of literal types

From Daniel Krügler<daniel.kruegler@googlemail.com>
Newsgroups comp.std.c++
Subject Re: Defect report: constexpr and mutable members of literal types
Date 2011-10-25 09:59 -0700
Organization A noiseless patient Spider
Message-ID <j84b7c$kq7$1@dont-email.me> (permalink)
References <37522.10.0.7.178.1319061795.squirrel@webmail.secure.aluminati.net>

Show all headers | View raw


Am 20.10.2011 00:23, schrieb Richard Smith:
>  Hi,
>
>  The C++11 IS allows literal types to have mutable members. In particular,
>  programs like the following are legal:
>
>  struct MM {
>      mutable int n;
>  };
>
>  template<int n>    struct S { int k = n; };
>
>  int f(int k) {
>      constexpr MM m = { 0 }; // ok, MM is a literal type
>      m.n = k;                // ok, m.n is mutable
>      return S<m.n>().k;      // ok, an lvalue-to-rvalue conversion of
>                              // a subobject of a constexpr object is
>                              // a constant expression [expr.const]/2
>  }
>
>  There seem to be two natural ways to fix this. Either (a) an lvalue-to-rvalue
>  conversion on a mutable member of a constexpr object should be considered to
>  not be a constant expression, or (b) literal types should not be allowed to
>  have mutable members.
>
>  (b) seems like the better solution, since it allows constexpr objects to be
>  ROM-able, which the constexpr papers note as an explicit goal. The clang
>  compiler currently implements (b).

Forwarded to CWG.

But let me ask, why you prefer (b)? IMO approach (a) seems more
consistent to existing rules. IMO it should suffice that the expression
m.n is not a constant expression in this example. I don't think that we
have or need the guarantee that *all* literal types are "ROMable"
(depending on the precise definition). E.g. the following should already
be well-formed:

struct RefConstant {
   int&  ri;
   constexpr RefConstant(int&  ri) : ri(ri) {}
};

int x = 1;

constexpr RefConstant rc(x);

int main() {
   rc.ri = 2; // OK
}

where rc.ri can be used in reference-constant expressions. But this
still allows to modify the memory that rc.ri refers to. Arguably,
mutable data have "value semantics (at least typically), but what I'm
trying to point out is, that the compiler already has to look at what
you try to do with the members of a literal type.

Greetings from Bremen,

Daniel Krügler



-- 
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Back to comp.std.c++ | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Defect report: constexpr and mutable members of literal types "Richard Smith"<richard@metafoo.co.uk> - 2011-10-19 15:23 -0700
  Re: Defect report: constexpr and mutable members of literal types Daniel Krügler<daniel.kruegler@googlemail.com> - 2011-10-25 09:59 -0700
    Re: Defect report: constexpr and mutable members of literal types Richard Smith<richard@metafoo.co.uk> - 2011-10-26 11:19 -0700

csiph-web