Topic: Follow up to "N3583 Exploring constexpr at Runtime
Author: s.scott.schurr@gmail.com
Date: Sun, 10 Nov 2013 16:57:11 -0800 (PST)
Raw View
------=_Part_1646_27254014.1384131431910
Content-Type: text/plain; charset=ISO-8859-1
Hi folks,
I have a follow-up paper to "N3583 Exploring constexpr at Runtime". The
follow-up is named "Inhibiting constexpr at Runtime." It describes a
technique, available in C++11, that can be used to prevent selected
constexpr functions from being used at runtime. Such "poisoned" constexpr
functions fail to link if used at runtime.
The paper concludes that, given the availability of this technique, none of
the possible changes described in N3583 are necessary.
In case you'd like to take a look, here is a link to the new paper.
https://drive.google.com/file/d/0B0-xyi_NILkZZEZQT2VPY21BVTQ/edit?usp=sharing
The new paper is only 8 pages long :-). I look forward to your comments.
Thanks.
Scott Schurr
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1646_27254014.1384131431910
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi folks,<div><br></div><div>I have a follow-up paper to "=
N3583 Exploring constexpr at Runtime". The follow-up is named "Inhibi=
ting constexpr at Runtime." It describes a technique, available in C+=
+11, that can be used to prevent selected constexpr functions from being us=
ed at runtime. Such "poisoned" constexpr functions fail to link if us=
ed at runtime.</div><div><br></div><div>The paper concludes that, given the=
availability of this technique, none of the possible changes described in =
N3583 are necessary.</div><div><br></div><div>In case you'd like to take a =
look, here is a link to the new paper.</div><div><br></div><div>https://dri=
ve.google.com/file/d/0B0-xyi_NILkZZEZQT2VPY21BVTQ/edit?usp=3Dsharing<br></d=
iv><div><br></div><div>The new paper is only 8 pages long :-). I look=
forward to your comments.</div><div><br></div><div>Thanks.</div><div><br><=
/div><div>Scott Schurr</div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1646_27254014.1384131431910--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sun, 10 Nov 2013 18:43:29 -0800 (PST)
Raw View
------=_Part_4_8428953.1384137809548
Content-Type: text/plain; charset=ISO-8859-1
I have flicked through both your papers. I think some of your analysis is
based on faulty assumptions, but I agree that it would be nice to be able
to restrict a given constexpr function to only be callable during
translation.
To enforce this at the moment the following wrapper is used (as
demonstrated by the type traits standard library):
template<T param>
struct F
{
static constexpr R value = f(param);
};
and the function `f` is not exposed to clients. Thus to access the
expression `f(3)`, one uses the expression `F<3>::value` instead. The
function can only be called during template instantiation, and so can only
be called duration translation.
One could also imagine the new C++14 template variables being used instead
in a similar pattern:
template<T param>
constexpr R F = f(param);
This also enforces only compile-time evaluation of f.
This is not an ideal solution though, because not all literal types can be
non-type template parameters.
I've been thinking about why not all literal types can be non-type template
parameters. It isn't clear to me yet. Proposing it to be so may also
raise conflicts with the new Concepts syntax, but I think this is secondary
and avoidab;e.
Anyway, if all literal types could be non-type template parameters then it
would solve the problem.
-Andrew.
On Monday, November 11, 2013 1:57:11 AM UTC+1, s.scott...@gmail.com wrote:
>
> Hi folks,
>
> I have a follow-up paper to "N3583 Exploring constexpr at Runtime". The
> follow-up is named "Inhibiting constexpr at Runtime." It describes a
> technique, available in C++11, that can be used to prevent selected
> constexpr functions from being used at runtime. Such "poisoned" constexpr
> functions fail to link if used at runtime.
>
> The paper concludes that, given the availability of this technique, none
> of the possible changes described in N3583 are necessary.
>
> In case you'd like to take a look, here is a link to the new paper.
>
>
> https://drive.google.com/file/d/0B0-xyi_NILkZZEZQT2VPY21BVTQ/edit?usp=sharing
>
> The new paper is only 8 pages long :-). I look forward to your comments.
>
> Thanks.
>
> Scott Schurr
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_4_8428953.1384137809548
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-family: arial; font-size: small;">I ha=
ve flicked through both your papers. I think some of your analysis is=
based on faulty assumptions, but I agree that it would be nice to be able =
to restrict a given constexpr function to only be callable during translati=
on.</span><div><font face=3D"arial" size=3D"2"><br></font></div><div><font =
face=3D"arial" size=3D"2">To enforce this at the moment the following wrapp=
er is used (as demonstrated by the type traits standard library):</font></d=
iv><div><font face=3D"arial" size=3D"2"><br></font></div><div><font face=3D=
"arial" size=3D"2"> template<T param></font></div><div><=
font face=3D"arial" size=3D"2"> struct F</font></div><div><fon=
t face=3D"arial" size=3D"2"> {</font></div><div><font face=3D"=
arial" size=3D"2"> static constexpr R value =3D =
f(param);</font></div><div><span style=3D"font-family: arial; font-size: sm=
all;"> };</span><br></div><div><font face=3D"arial" size=3D"2"=
><br></font></div><div><font face=3D"arial" size=3D"2">and the function `f`=
is not exposed to clients. Thus to access the expression `f(3)`, one=
uses the expression `F<3>::value` instead. The function can on=
ly be called during template instantiation, and so can only be called =
duration translation.</font></div><div><font face=3D"arial" size=3D"2"><br>=
</font></div><div><font face=3D"arial" size=3D"2">One could also imagine th=
e new C++14 template variables being used instead in a similar pattern:</fo=
nt></div><div><br></div><div> template<T param></div><di=
v> constexpr R F =3D f(param);</div><div><font face=3D"arial" =
size=3D"2"><br></font></div><div><font face=3D"arial" size=3D"2">This also =
enforces only compile-time evaluation of f.</font></div><div><font face=3D"=
arial" size=3D"2"><br></font></div><div><span style=3D"font-family: arial; =
font-size: small;">This is not an ideal solution though, because not all li=
teral types can be non-type template parameters.</span></div><div><br></div=
><div>I've been thinking about why not all literal types can be non-type te=
mplate parameters. It isn't clear to me yet. Proposing it to be=
so may also raise conflicts with the new Concepts syntax, but I think this=
is secondary and avoidab;e.</div><div><br></div><div>Anyway, if all litera=
l types could be non-type template parameters then it would solve the probl=
em.</div><div> -Andrew.<br></div><div><br></div><div><div><br>O=
n Monday, November 11, 2013 1:57:11 AM UTC+1, s.scott...@gmail.com wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hi folks,<div><=
br></div><div>I have a follow-up paper to "N3583 Exploring constexpr at Run=
time". The follow-up is named "Inhibiting constexpr at Runtime." &nbs=
p;It describes a technique, available in C++11, that can be used to prevent=
selected constexpr functions from being used at runtime. Such "poiso=
ned" constexpr functions fail to link if used at runtime.</div><div><br></d=
iv><div>The paper concludes that, given the availability of this technique,=
none of the possible changes described in N3583 are necessary.</div><div><=
br></div><div>In case you'd like to take a look, here is a link to the new =
paper.</div><div><br></div><div><a href=3D"https://drive.google.com/file/d/=
0B0-xyi_NILkZZEZQT2VPY21BVTQ/edit?usp=3Dsharing" target=3D"_blank">https://=
drive.google.com/file/<wbr>d/0B0-xyi_<wbr>NILkZZEZQT2VPY21BVTQ/edit?usp=3D<=
wbr>sharing</a><br></div><div><br></div><div>The new paper is only 8 pages =
long :-). I look forward to your comments.</div><div><br></div><div>T=
hanks.</div><div><br></div><div>Scott Schurr</div><div><br></div></div></bl=
ockquote></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_4_8428953.1384137809548--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Sun, 10 Nov 2013 18:48:51 -0800
Raw View
--047d7b344290a931e004eaddc5f9
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Nov 10, 2013 at 4:57 PM, <s.scott.schurr@gmail.com> wrote:
> Hi folks,
>
> I have a follow-up paper to "N3583 Exploring constexpr at Runtime". The
> follow-up is named "Inhibiting constexpr at Runtime." It describes a
> technique, available in C++11, that can be used to prevent selected
> constexpr functions from being used at runtime. Such "poisoned" constexpr
> functions fail to link if used at runtime.
>
> The paper concludes that, given the availability of this technique, none
> of the possible changes described in N3583 are necessary.
>
> In case you'd like to take a look, here is a link to the new paper.
>
>
> https://drive.google.com/file/d/0B0-xyi_NILkZZEZQT2VPY21BVTQ/edit?usp=sharing
>
> The new paper is only 8 pages long :-). I look forward to your comments.
>
Your technique is not correct: a function that is called in a
potentially-evaluated constant expression is still odr-used, so the
compiler is permitted to emit it. Thus you have an odr-violation whether or
not the expression is evaluated during translation, and the compiler is
permitted to reject the code either way.
Andrew Tomazos' approach of funneling the evaluation through a template
works fine, though.
Thanks.
>
> Scott Schurr
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b344290a931e004eaddc5f9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sun, Nov 10, 2013 at 4:57 PM, <span dir=3D"ltr"><<a=
href=3D"mailto:s.scott.schurr@gmail.com" target=3D"_blank">s.scott.schurr@=
gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D=
"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi folks,<div><br></div><di=
v>I have a follow-up paper to "N3583 Exploring constexpr at Runtime&qu=
ot;. =A0The follow-up is named "Inhibiting constexpr at Runtime."=
=A0It describes a technique, available in C++11, that can be used to preve=
nt selected constexpr functions from being used at runtime. =A0Such "p=
oisoned" constexpr functions fail to link if used at runtime.</div>
<div><br></div><div>The paper concludes that, given the availability of thi=
s technique, none of the possible changes described in N3583 are necessary.=
</div><div><br></div><div>In case you'd like to take a look, here is a =
link to the new paper.</div>
<div><br></div><div><a href=3D"https://drive.google.com/file/d/0B0-xyi_NILk=
ZZEZQT2VPY21BVTQ/edit?usp=3Dsharing" target=3D"_blank">https://drive.google=
..com/file/d/0B0-xyi_NILkZZEZQT2VPY21BVTQ/edit?usp=3Dsharing</a><br></div><d=
iv>
<br>
</div><div>The new paper is only 8 pages long :-). =A0I look forward to you=
r comments.</div></div></blockquote><div><br></div><div>Your technique is n=
ot correct: a function that is called in a potentially-evaluated constant e=
xpression is still odr-used, so the compiler is permitted to emit it. Thus =
you have an odr-violation whether or not the expression is evaluated during=
translation, and the compiler is permitted to reject the code either way.<=
/div>
<div>=A0</div><div>Andrew Tomazos' approach of funneling the evaluation=
through a template works fine, though.</div><div><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
<div dir=3D"ltr"><div>Thanks.</div><span><font color=3D"#888888"><div><br><=
/div><div>Scott Schurr</div>
<div><br></div></font></span></div><span><font color=3D"#888888">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b344290a931e004eaddc5f9--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sun, 10 Nov 2013 18:49:40 -0800 (PST)
Raw View
------=_Part_1920_2687938.1384138180639
Content-Type: text/plain; charset=ISO-8859-1
On Monday, November 11, 2013 3:43:29 AM UTC+1, Andrew Tomazos wrote:
>
> Anyway, if all literal types could be non-type template parameters then it
> would solve the problem.
>
That is, you would have:
compile-time run-time
normal function call NO YES
constexpr function call YES YES
template instantiation YES NO
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1920_2687938.1384138180639
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, November 11, 2013 3:43:29 AM UTC+1, Andrew Toma=
zos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v>Anyway, if all literal types could be non-type template parameters then i=
t would solve the problem.</div></div></blockquote><div><br></div><div>That=
is, you would have:</div><div><font face=3D"courier new, monospace"><br></=
font></div><div><font face=3D"courier new, monospace"> =
 =
; compile-time run-time</font></div><div><font face=3D"courier=
new, monospace"> normal function call NO =
YES</font></div><div><font face=3D"cour=
ier new, monospace"> constexpr function call YES =
YES</font></div><div><font face=3D"courie=
r new, monospace"> template instantiation YES &n=
bsp; NO</font></div><div><font face=3D"courier n=
ew, monospace"><br></font></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1920_2687938.1384138180639--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Sun, 10 Nov 2013 19:29:51 -0800
Raw View
--bcaec51d25524b2dd804eade5834
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Nov 10, 2013 at 6:43 PM, Andrew Tomazos <andrewtomazos@gmail.com>wrote:
> I have flicked through both your papers. I think some of your analysis is
> based on faulty assumptions, but I agree that it would be nice to be able
> to restrict a given constexpr function to only be callable during
> translation.
>
> To enforce this at the moment the following wrapper is used (as
> demonstrated by the type traits standard library):
>
> template<T param>
> struct F
> {
> static constexpr R value = f(param);
> };
>
> and the function `f` is not exposed to clients. Thus to access the
> expression `f(3)`, one uses the expression `F<3>::value` instead. The
> function can only be called during template instantiation, and so can only
> be called duration translation.
>
> One could also imagine the new C++14 template variables being used instead
> in a similar pattern:
>
> template<T param>
> constexpr R F = f(param);
>
> This also enforces only compile-time evaluation of f.
>
> This is not an ideal solution though, because not all literal types can be
> non-type template parameters.
>
> I've been thinking about why not all literal types can be non-type
> template parameters. It isn't clear to me yet.
>
The key issue is, how do you determine whether two template-arguments are
"the same" if they're of arbitrary literal type? See
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3413.html
for more information. Using an arbitrary constexpr "operator==" has severe
implementability issues. Using memberwise equality has met strong
opposition from some corners of the committee (and anyway, does not
entirely resolve the implementability issues.)
We can certainly do better than we're currently doing, but we'll need to
tread very carefully. FWIW, I intend to propose this for C++17, with an
exploration of the implementation issues and the restrictions they impose.
Proposing it to be so may also raise conflicts with the new Concepts
> syntax, but I think this is secondary and avoidab;e.
>
I don't foresee any such conflicts.
> Anyway, if all literal types could be non-type template parameters then it
> would solve the problem.
> -Andrew.
>
>
> On Monday, November 11, 2013 1:57:11 AM UTC+1, s.scott...@gmail.com wrote:
>>
>> Hi folks,
>>
>> I have a follow-up paper to "N3583 Exploring constexpr at Runtime". The
>> follow-up is named "Inhibiting constexpr at Runtime." It describes a
>> technique, available in C++11, that can be used to prevent selected
>> constexpr functions from being used at runtime. Such "poisoned" constexpr
>> functions fail to link if used at runtime.
>>
>> The paper concludes that, given the availability of this technique, none
>> of the possible changes described in N3583 are necessary.
>>
>> In case you'd like to take a look, here is a link to the new paper.
>>
>> https://drive.google.com/file/d/0B0-xyi_NILkZZEZQT2VPY21BVTQ/edit?usp=
>> sharing
>>
>> The new paper is only 8 pages long :-). I look forward to your comments.
>>
>> Thanks.
>>
>> Scott Schurr
>>
>> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--bcaec51d25524b2dd804eade5834
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sun, Nov 10, 2013 at 6:43 PM, Andrew Tomazos <span dir=
=3D"ltr"><<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">a=
ndrewtomazos@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><span style=3D"font-family:arial;font-siz=
e:small">I have flicked through both your papers. =A0I think some of your a=
nalysis is based on faulty assumptions, but I agree that it would be nice t=
o be able to restrict a given constexpr function to only be callable during=
translation.</span><div>
<font face=3D"arial"><br></font></div><div><font face=3D"arial">To enforce =
this at the moment the following wrapper is used (as demonstrated by the ty=
pe traits standard library):</font></div><div><font face=3D"arial"><br></fo=
nt></div>
<div><font face=3D"arial">=A0 =A0 template<T param></font></div><div>=
<font face=3D"arial">=A0 =A0 struct F</font></div><div><font face=3D"arial"=
>=A0 =A0 {</font></div><div><font face=3D"arial">=A0 =A0 =A0 =A0 static con=
stexpr R value =3D f(param);</font></div>
<div><span style=3D"font-family:arial;font-size:small">=A0 =A0 };</span><br=
></div><div><font face=3D"arial"><br></font></div><div><font face=3D"arial"=
>and the function `f` is not exposed to clients. =A0Thus to access the expr=
ession `f(3)`, one uses the expression `F<3>::value` instead. =A0The =
function can only be called during template=A0instantiation, and so can onl=
y be called duration translation.</font></div>
<div><font face=3D"arial"><br></font></div><div><font face=3D"arial">One co=
uld also imagine the new C++14 template variables being used instead in a s=
imilar pattern:</font></div><div><br></div><div>=A0 =A0 template<T param=
></div>
<div>=A0 =A0 constexpr R F =3D f(param);</div><div><font face=3D"arial"><br=
></font></div><div><font face=3D"arial">This also enforces only compile-tim=
e evaluation of f.</font></div><div><font face=3D"arial"><br></font></div><=
div><span style=3D"font-family:arial;font-size:small">This is not an ideal =
solution though, because not all literal types can be non-type template par=
ameters.</span></div>
<div><br></div><div>I've been thinking about why not all literal types =
can be non-type template parameters. =A0It isn't clear to me yet.</div>=
</div></blockquote><div><br></div><div>The key issue is, how do you determi=
ne whether two template-arguments are "the same" if they're o=
f arbitrary literal type? See</div>
<div><br></div><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/=
papers/2012/n3413.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/=
2012/n3413.html</a><br></div><div><br></div><div>for more information. Usin=
g an arbitrary constexpr "operator=3D=3D" has severe implementabi=
lity issues. Using memberwise equality has met strong opposition from some =
corners of the committee (and anyway, does not entirely resolve the impleme=
ntability issues.)</div>
<div><br></div><div>We can certainly do better than we're currently doi=
ng, but we'll need to tread very carefully. FWIW, I intend to propose t=
his for C++17, with an exploration of the implementation issues and the res=
trictions they impose.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>Proposing it to be so=
may also raise conflicts with the new Concepts syntax, but I think this is=
secondary and avoidab;e.</div>
</div></blockquote><div><br></div><div>I don't foresee any such conflic=
ts.</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex">
<div dir=3D"ltr"><div>Anyway, if all literal types could be non-type templa=
te parameters then it would solve the problem.</div><span class=3D""><font =
color=3D"#888888"><div>=A0 =A0-Andrew.<br></div></font></span><div><div cla=
ss=3D"h5">
<div><br></div><div><div><br>On Monday, November 11, 2013 1:57:11 AM UTC+1,=
<a href=3D"mailto:s.scott...@gmail.com" target=3D"_blank">s.scott...@gmail=
..com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">
<div dir=3D"ltr">Hi folks,<div><br></div><div>I have a follow-up paper to &=
quot;N3583 Exploring constexpr at Runtime". =A0The follow-up is named =
"Inhibiting constexpr at Runtime." =A0It describes a technique, a=
vailable in C++11, that can be used to prevent selected constexpr functions=
from being used at runtime. =A0Such "poisoned" constexpr functio=
ns fail to link if used at runtime.</div>
<div><br></div><div>The paper concludes that, given the availability of thi=
s technique, none of the possible changes described in N3583 are necessary.=
</div><div><br></div><div>In case you'd like to take a look, here is a =
link to the new paper.</div>
<div><br></div><div><a href=3D"https://drive.google.com/file/d/0B0-xyi_NILk=
ZZEZQT2VPY21BVTQ/edit?usp=3Dsharing" target=3D"_blank">https://drive.google=
..com/file/<u></u>d/0B0-xyi_<u></u>NILkZZEZQT2VPY21BVTQ/edit?usp=3D<u></u>sh=
aring</a><br>
</div><div><br></div><div>The new paper is only 8 pages long :-). =A0I look=
forward to your comments.</div><div><br></div><div>Thanks.</div><div><br><=
/div><div>Scott Schurr</div><div><br></div></div></blockquote></div></div>
</div></div></div><div class=3D""><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--bcaec51d25524b2dd804eade5834--
.
Author: s.scott.schurr@gmail.com
Date: Mon, 11 Nov 2013 22:17:26 -0800 (PST)
Raw View
------=_Part_2549_25811700.1384237046386
Content-Type: text/plain; charset=ISO-8859-1
Hi Andrew,
Thanks very much for looking through the papers.
On Sunday, November 10, 2013 6:49:40 PM UTC-8, Andrew Tomazos wrote:
>
> On Monday, November 11, 2013 3:43:29 AM UTC+1, Andrew Tomazos wrote:
>>
>> Anyway, if all literal types could be non-type template parameters then
>> it would solve the problem.
>>
>
> That is, you would have:
>
> compile-time run-time
> normal function call NO YES
> constexpr function call YES YES
> template instantiation YES NO
>
>
Yeah, I think that's not a bad picture for the state of things today. But
I'd extend it to include the preprocessor
compile-time run-time
normal function call NO YES
constexpr function call YES YES
template instantiation YES NO
macro YES NO
To me what's interesting about this table is looking at what kind of code
is easy to write and maintain. A normal function call is the easiest.
It's easy to understand. Most programmers are qualified to maintain
normal function calls.
Thanks to the efforts of Richard Smith, Gabriel Dos Reis, and others a
constexpr function is almost as easy to write and maintain as a regular
function. Especially with the extended syntax available in C++14. And it
can execute at compile time.
On the other hand, template metaprogramming is hard. Every time I
introduce a new template (one that I write, not invoking one from the
standard library) I put a deficit into my employer's code base. Templates
make the other developers nervous. They don't want to maintain templates
and they don't know how to debug them. Templates are a tool for the
semi-expert, not for the average C++ programmer. And, yeah, they execute
at compile time.
Then there are macros. They start easy, but they get nasty if they develop
much complexity at all. And, yeah, they execute at compile time.
If you wanted to write compile-time code which tool would you use? I'd
pick the constexpr function.
And I do think that compile-time programming should be used a lot more than
it is. Prefer to catch your errors at compile-time.
A constexpr function is *almost* perfect for this. But there's a catch.
If you don't invoke the constexpr function carefully it will turn into a
run-time function. That's usually okay. But when it's not okay the only
recourse is to be extremely careful about declaring variables constexpr.
Or you can deliberately introduce an unresolved symbol and get a link-time
failure.
Anyway, you've seen the papers. You know that's my perspective. I just
don't think that telling people to use template metaprogramming instead of
using constexpt functions is a great answer. Template metaprogramming is
not a tool most C++ programmers want to -- or should be -- using. At least
in my opinion.
Thanks again for looking over the papers. And thanks for your comments.
Scott Schurr
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2549_25811700.1384237046386
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Andrew,<div><br></div><div>Thanks very much for looking=
through the papers.<br><br>On Sunday, November 10, 2013 6:49:40 PM UTC-8, =
Andrew Tomazos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Monday, November 11, 2013 3:43:29 AM UTC+1, Andrew Tomazos wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Anyway, if =
all literal types could be non-type template parameters then it would solve=
the problem.</div></div></blockquote><div><br></div><div>That is, you woul=
d have:</div><div><font face=3D"courier new, monospace"><br></font></div><d=
iv><font face=3D"courier new, monospace"> =
compi=
le-time run-time</font></div><div><font face=3D"courier new, monospa=
ce"> normal function call NO  =
; YES</font></div><div><font face=3D"courier new, mono=
space"> constexpr function call YES =
YES</font></div><div><font face=3D"courier new, monosp=
ace"> template instantiation YES &=
nbsp; NO</font></div><div><font face=3D"courier new, monospace=
"><br></font></div></div></blockquote><div><br></div><div>Yeah, I think tha=
t's not a bad picture for the state of things today. But I'd extend i=
t to include the preprocessor</div><div><br></div><div><font face=3D"courie=
r new, monospace"> &=
nbsp; compile-time ru=
n-time</font></div><div><font face=3D"courier new, monospace"> =
normal function call NO &=
nbsp; YES</font></div><div><font face=3D"courier new, monospace">&nbs=
p; constexpr function call YES &nb=
sp; YES</font></div><div><font face=3D"courier new, monospace"> =
; template instantiation YES &nbs=
p; NO</font></div><div><font face=3D"courier new, monospace"> =
macro =
YES NO</font></div></div><=
div><br></div><div>To me what's interesting about this table is looking at =
what kind of code is easy to write and maintain. A normal function ca=
ll is the easiest. It's easy to understand. Most programmers ar=
e qualified to maintain normal function calls.</div><div><br></div><div>Tha=
nks to the efforts of Richard Smith, Gabriel Dos Reis, and others a constex=
pr function is almost as easy to write and maintain as a regular function. =
Especially with the extended syntax available in C++14. And it =
can execute at compile time.</div><div><br></div><div>On the other hand, te=
mplate metaprogramming is hard. Every time I introduce a new template=
(one that I write, not invoking one from the standard library) I put a def=
icit into my employer's code base. Templates make the other developer=
s nervous. They don't want to maintain templates and they don't know =
how to debug them. Templates are a tool for the semi-expert, not for =
the average C++ programmer. And, yeah, they execute at compile time.<=
/div><div><br></div><div>Then there are macros. They start easy, but =
they get nasty if they develop much complexity at all. And, yeah, the=
y execute at compile time.</div><div><br></div><div>If you wanted to write =
compile-time code which tool would you use? I'd pick the constexpr fu=
nction.</div><div><br></div><div>And I do think that compile-time programmi=
ng should be used a lot more than it is. Prefer to catch your errors =
at compile-time.</div><div><br></div><div>A constexpr function is *almost* =
perfect for this. But there's a catch. If you don't invoke the =
constexpr function carefully it will turn into a run-time function. T=
hat's usually okay. But when it's not okay the only recourse is to be=
extremely careful about declaring variables constexpr. Or you can de=
liberately introduce an unresolved symbol and get a link-time failure.</div=
><div><br></div><div>Anyway, you've seen the papers. You know that's =
my perspective. I just don't think that telling people to use templat=
e metaprogramming instead of using constexpt functions is a great answer. &=
nbsp;Template metaprogramming is not a tool most C++ programmers want to --=
or should be -- using. At least in my opinion.</div><div><br></div><=
div>Thanks again for looking over the papers. And thanks for your com=
ments.<br></div><div><br></div><div>Scott Schurr</div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2549_25811700.1384237046386--
.
Author: s.scott.schurr@gmail.com
Date: Mon, 11 Nov 2013 22:31:47 -0800 (PST)
Raw View
------=_Part_961_28161297.1384237907730
Content-Type: text/plain; charset=ISO-8859-1
Hi Richard,
Thanks very much for taking the time to comment on the paper.
On Sunday, November 10, 2013 6:48:51 PM UTC-8, Richard Smith wrote:
>
>
>
Your technique is not correct: a function that is called in a
> potentially-evaluated constant expression is still odr-used, so the
> compiler is permitted to emit it. Thus you have an odr-violation whether or
> not the expression is evaluated during translation, and the compiler is
> permitted to reject the code either way.
>
That's a great point. I'll need to add that into the failure modes in the
"Cheesy" section.
I'm not a linker expert, but my impression is that most linkers are really
good at removing unreferenced code. If the compiler emits a constexpr
function that is unreferenced by any calls, then my impression is that most
linkers will just throw away the function that the compiler generated. In
that case the unresolved external will not cause a link failure.
Still, probably not all linkers will do that. So, I'm not disagreeing with
the point you're making
And yes, by invoking a link-time error I'm stepping outside of the bounds
of the C++ standard. In that sense perhaps the newest paper doesn't belong
on this site at all.
Thanks very much for your comment. And thanks for the great work you've
done with constexpr.
Scott Schurr
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_961_28161297.1384237907730
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Richard,<div><br></div><div>Thanks very much for taking=
the time to comment on the paper.<br><br>On Sunday, November 10, 2013 6:48=
:51 PM UTC-8, Richard Smith wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div class=3D"gmail_quote"><div> <br></div></di=
v></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div>Your technique is =
not correct: a function that is called in a potentially-evaluated constant =
expression is still odr-used, so the compiler is permitted to emit it. Thus=
you have an odr-violation whether or not the expression is evaluated durin=
g translation, and the compiler is permitted to reject the code either way.=
</div>
<div></div></div></div></div></blockquote><div><br></div><div>That's a grea=
t point. I'll need to add that into the failure modes in the "Cheesy"=
section.</div><div><br></div><div>I'm not a linker expert, but my impressi=
on is that most linkers are really good at removing unreferenced code. &nbs=
p;If the compiler emits a constexpr function that is unreferenced by any ca=
lls, then my impression is that most linkers will just throw away the funct=
ion that the compiler generated. In that case the unresolved external=
will not cause a link failure.</div><div><br></div><div>Still, probably no=
t all linkers will do that. So, I'm not disagreeing with the point yo=
u're making</div><div><br></div><div>And yes, by invoking a link-time error=
I'm stepping outside of the bounds of the C++ standard. In that sens=
e perhaps the newest paper doesn't belong on this site at all.</div><div>&n=
bsp;</div><div>Thanks very much for your comment. And thanks for the =
great work you've done with constexpr.</div><div><br></div><div>Scott Schur=
r</div><div> <br></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_961_28161297.1384237907730--
.