Path: csiph.com!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail
From: =?ISO-8859-2?Q?Andrzej_Krzemie=F1ski?= <akrzemi1@gmail.com>
Newsgroups: comp.std.c++
Subject: Re: Why this behaviour for literal types?
Date: Sat, 17 Mar 2012 00:53:23 -0700 (PDT)
Organization: http://groups.google.com
Lines: 103
Sender: std-cpp-request@vandevoorde.com
Approved: james.dennett@gmail.com
Message-ID: <10974227.651.1331889037040.JavaMail.geo-discussion-forums@vbbed8>
References: <1615055.1458.1331755052471.JavaMail.geo-discussion-forums@vbgx21> <jjr2a2$bdt$1@dont-email.me>
NNTP-Posting-Host: vokKqcTcTpj1fYF401O8bXAQI/mp9LSfuiUXss5HVX0=
Content-Type: text/plain; charset=ISO-8859-2
X-Trace: news.albasani.net PYLsq65ySDt6K3YPmPcrwdpNf4/42eShxs1/GFh2Fnc/3v8cWHwAR+VC480pIf2ZfXRIEhM9mQU0U9TWNYxB9g==
X-Complaints-To: abuse@albasani.net
NNTP-Posting-Date: Sat, 17 Mar 2012 07:53:27 +0000 (UTC)
X-Mailer: Perl5 Mail::Internet v2.05
X-Submission-Address: std-cpp-submit@vandevoorde.com
Cancel-Lock: sha1:sdVRHg73bemwzPytWpSMXCjWPS8=
X-Original-Date: Fri, 16 Mar 2012 02:10:36 -0700 (PDT)
Xref: csiph.com comp.std.c++:446

W dniu czwartek, 15 marca 2012, 19:33:34 UTC+1 użytkownik Daniel
Krügler napisał:
> Am 14.03.2012 21:33, schrieb Andrzej Krzemieński:
> >  Hi,
> >  This is my literal type:
> >
> >      struct C
> >      {
> >        double m;
> >        constexpr C( double m ) : m{m} {};
> >        constexpr double get() const { return m; };
> >      };
> >
> >  Therefore the following code works:
> >
> >      constexpr C c = C{5.};
> >      constexpr double k = c.get();
>
> Correct.
>
> >  But the following does not:
> >
> >      const C cc = C{5.};  // but not constexpr
> >      constexpr double kk = cc.get();
> >
> >  Why is this so? Object cc is subject to const initialization anyway. It is possible to make it work only by a seemingly irrelevant change in declaration (add constexpr). What was the reason for disallowing this "implicit generation of compile-time constants"?
>
> This was a deliberate decision. Variables declared with const share
> different responsibilities, while constexpr is much clearer. const means
> (a) "cannot modify", it can also mean (b) constant initialization, *and*
> it can mean (c) that the variable can be used within constant expressions.
>
> const int n1 = 12;
>
> satisfies all three requirements, while
>
> int f();
>
> const int n2 = f();
>
> only the first. One other interesting corner case is
>
> #include<mutex>
>
> std::mutex m;
>
> satisfies only the second (I'm ignoring here address-constant expression
> within this discussion, which is a very special family of constant
> expressions).
>
> C++11 kept the very restricted use-case of const variables useable in
> constant expressions which is the special bullet in 5.19 (emphasize mine):
>
> "a non-volatile glvalue of integral or enumeration type that refers to a
> non-volatile const object with a preceding initialization, **initialized
> with a constant expression**"
>
> but didn't invest the efforts to extend this for other literal types,
> because the existing rules were surprising and not easy to understand.
> The much simpler and more general bullet
>
> "a non-volatile glvalue of literal type that refers to a non-volatile
> object defined with constexpr, or that refers to a sub-object of such an
> object"
>
> rules basically all the rest.
>
> HTH&  Greetings from Bremen,
>
> Daniel Krügler

I am now trying to understand the conditions in 5.19 P 2 and it
appears to me that the following initialization should work fine:

 struct C // C is same as above
 {
   double m;
   constexpr C( double m ) : m{m} {};
   constexpr double get() const { return m; };
 };

 C && rr = C{5.};  // no const!
 constexpr double kk = rr.get();

Reference rr is not even a reference to const. In the last line the
initializing expression involves an lvalue-to-rvalue conversion (or
not?) but I am protected by the third "unless" sub-bullet because
reference rr is a glvalue of literal type that refers to a
non-volatile temporary object whose lifetime has not ended,
initialized with a constant expression.

Am I missing something obvious here, or should the above example just
compile fine?

Regards,
&rzej


--
[ 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                      ]