Topic: Allow inline functions to be evaluated in
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 4 Oct 2015 06:47:03 -0700 (PDT)
Raw View
------=_Part_2454_403943503.1443966423119
Content-Type: multipart/alternative;
boundary="----=_Part_2455_1433685744.1443966423126"
------=_Part_2455_1433685744.1443966423126
Content-Type: text/plain; charset=UTF-8
On Sunday, October 4, 2015 at 8:52:53 AM UTC-4, TONGARI J wrote:
>
> We currently have 2 evaluation contexts in standrard C++:
>
> - normal context
> - constant context
>
> In non-standard world, we also have language-extensions like CUDA and
> C++AMP that provides GPU evaluation context.
>
> Before C++11, we only had normal context in standrard. Everytime a new
> evaluation context is introduced into the language, it also requires us to
> 'mark' the functions manually in order to adopt the new context, for
> example:
>
> - constant expression - `constexpr`
> - CUDA - `__device__`
> - C++AMP - `restrict(amp)`
> - coroutine - probably `resumable` or `async`
> - etc...
>
> This is annoying, why can't the compiler treat inline functions in a
> context-agnostic way?
>
Because each of those contexts have restrictions on what is allowed within
them. `constexpr` is quite restrictive compared to runtime. I don't know
what goes on in `__device__` or `restrict(amp)`, but I'd bet they are also
restrictive as well.
If I write code that I intend to be able to run at constexpr time, I *want*
the compiler to make sure that I've written it correctly. I don't want the
compiler to allow me to write invalid `constexpr` code and not tell me just
because all of my uses of that function happen to be evaluated at runtime.
It's interesting that the template one compiles while the non-template one
> fails.
>
>
The way standard algorithms exploits `constexpr` thus seems 'hacky' -- it
> makes use of the weakness of `constexpr` that it can't check if the
> functions called are really `constexpr` if they depend on the template
> args.
>
It's not exploring "weakness" in `constexpr`; it's exploiting rules in
template instantiation. When you write a template function, whether the
operations are constexpr or not depends on the template arguments passed
in. So the compiler cannot detect any errors. And more importantly, the
*user* cannot know if they've done the right thing or not.
Therefore, the rules are different for template functions than non-template
functions (no matter how much Bjarne seems to want to turn them into the
same thing). In non-template code, you're saying "This function *will be*
constexpr." In template code, you're saying, "Declare this function
constexpr if all of the substituted operations are constexpr." I'm not
positive, but I'd bet that the first phase of two-phase-lookup for template
constexpr will statically fail if non-dependent operations are not
constexpr.
I understand what you want. I just don't know *why* you want it. Why do you
want to shut off compile-time checking?
I'm aware of the concerns shown here:
> http://stackoverflow.com/a/19830673/2969631
>
It's interesting that you linked to the second answer, but seem to have
ignored all of the (very good) points in the *first* answer. That argues
more strongly even against you `generic` idea.
--
---
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_2455_1433685744.1443966423126
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Sunday, October 4, 2015 at 8:52:53 AM UTC-4, TONGARI J wrote:<bl=
ockquote 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>We currentl=
y have 2 evaluation contexts in standrard C++:</div><div><ul><li>normal con=
text<br></li><li>constant context</li></ul></div><div>In non-standard world=
, we also have language-extensions like CUDA and C++AMP that provides GPU e=
valuation context.</div><div><br></div><div>Before C++11, we only had norma=
l context=C2=A0in standrard. Everytime a new evaluation context is introduc=
ed into the language, it also requires us to 'mark' the functions m=
anually in order to adopt the new context, for example:</div><div><ul><li>c=
onstant expression - `<font face=3D"courier new, monospace">constexpr</font=
>`<br></li><li>CUDA - `<font face=3D"courier new, monospace">__device__</fo=
nt>`<br></li><li>C++AMP - `<font face=3D"courier new, monospace">restrict(a=
mp)</font>`<br></li><li>coroutine - probably `<font face=3D"courier new, mo=
nospace">resumable</font>` or `<font face=3D"courier new, monospace">async<=
/font>`<br></li><li>etc...</li></ul></div><div>This is annoying, why can=
9;t the compiler treat inline functions in a context-agnostic way?</div></d=
iv></blockquote><div><br>Because each of those contexts have restrictions o=
n what is allowed within them. `constexpr` is quite restrictive compared to=
runtime. I don't know what goes on in `__device__` or `restrict(amp)`,=
but I'd bet they are also restrictive as well.<br><br>If I write code =
that I intend to be able to run at constexpr time, I <i>want</i> the compil=
er to make sure that I've written it correctly. I don't want the co=
mpiler to allow me to write invalid `constexpr` code and not tell me just b=
ecause all of my uses of that function happen to be evaluated at runtime.<b=
r><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div></div><div>It's interesting that the template one compiles while th=
e non-template one fails.</div></div></blockquote><blockquote style=3D"marg=
in: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-l=
eft: 1ex;" class=3D"gmail_quote"><div>=C2=A0</div></blockquote><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>The way standard alg=
orithms exploits `<font face=3D"courier new, monospace">constexpr</font>` t=
hus seems 'hacky' -- it makes use of the weakness of `<font face=3D=
"courier new, monospace">constexpr</font>` that it can't check if the f=
unctions called are really `<font face=3D"courier new, monospace">constexpr=
</font>` if they depend on the template args.</div></div></blockquote><div>=
<br>It's not exploring "weakness" in `constexpr`; it's ex=
ploiting rules in template instantiation. When you write a template functio=
n, whether the operations are constexpr or not depends on the template argu=
ments passed in. So the compiler cannot detect any errors. And more importa=
ntly, the <i>user</i> cannot know if they've done the right thing or no=
t.<br><br>Therefore, the rules are different for template functions than no=
n-template functions (no matter how much=20
Bjarne seems to want to turn them into the same thing). In non-template cod=
e, you're saying "This function <i>will be</i> constexpr." In=
template code, you're saying, "Declare this function constexpr if=
all of the substituted operations are constexpr." I'm not positiv=
e, but I'd bet that the first phase of two-phase-lookup for template co=
nstexpr will statically fail if non-dependent operations are not constexpr.=
<br><br>I understand what you want. I just don't know <i>why</i> you wa=
nt it. Why do you want to shut off compile-time checking?<br><br></div><blo=
ckquote 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></div><div>I=
'm aware of the concerns shown here:</div><div><a href=3D"http://stacko=
verflow.com/a/19830673/2969631" target=3D"_blank" rel=3D"nofollow" onmoused=
own=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fstackove=
rflow.com%2Fa%2F19830673%2F2969631\46sa\75D\46sntz\0751\46usg\75AFQjCNHuGmZ=
EDNLKrsCCTAEl6fhJjDdOaw';return true;" onclick=3D"this.href=3D'http=
://www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fa%2F19830673%2F2=
969631\46sa\75D\46sntz\0751\46usg\75AFQjCNHuGmZEDNLKrsCCTAEl6fhJjDdOaw'=
;return true;">http://stackoverflow.com/a/<wbr>19830673/2969631</a></div></=
div></blockquote><div><br>It's interesting that you linked to the secon=
d answer, but seem to have ignored all of the (very good) points in the <i>=
first</i> answer. That argues more strongly even against you `generic` idea=
..</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_2455_1433685744.1443966423126--
------=_Part_2454_403943503.1443966423119--
.
Author: TONGARI J <tongari95@gmail.com>
Date: Sun, 4 Oct 2015 23:03:57 +0800
Raw View
--001a113fb33ac89a4a052148b4dd
Content-Type: text/plain; charset=UTF-8
2015-10-04 21:47 GMT+08:00 Nicol Bolas <jmckesson@gmail.com>:
>
>
> On Sunday, October 4, 2015 at 8:52:53 AM UTC-4, TONGARI J wrote:
>>
>> We currently have 2 evaluation contexts in standrard C++:
>>
>> - normal context
>> - constant context
>>
>> In non-standard world, we also have language-extensions like CUDA and
>> C++AMP that provides GPU evaluation context.
>>
>> Before C++11, we only had normal context in standrard. Everytime a new
>> evaluation context is introduced into the language, it also requires us to
>> 'mark' the functions manually in order to adopt the new context, for
>> example:
>>
>> - constant expression - `constexpr`
>> - CUDA - `__device__`
>> - C++AMP - `restrict(amp)`
>> - coroutine - probably `resumable` or `async`
>> - etc...
>>
>> This is annoying, why can't the compiler treat inline functions in a
>> context-agnostic way?
>>
>
> Because each of those contexts have restrictions on what is allowed within
> them. `constexpr` is quite restrictive compared to runtime. I don't know
> what goes on in `__device__` or `restrict(amp)`, but I'd bet they are also
> restrictive as well.
>
> If I write code that I intend to be able to run at constexpr time, I
> *want* the compiler to make sure that I've written it correctly. I don't
> want the compiler to allow me to write invalid `constexpr` code and not
> tell me just because all of my uses of that function happen to be evaluated
> at runtime.
>
No disagreement here, but that's not the point. I'm not asking the compiler
to allow me to write invalid `constexpr` code, I'm just asking it to allow
me to write `generic` code that could be potentially treated as constant
expression.
> It's interesting that the template one compiles while the non-template one
>> fails.
>>
>
>>
> The way standard algorithms exploits `constexpr` thus seems 'hacky' -- it
>> makes use of the weakness of `constexpr` that it can't check if the
>> functions called are really `constexpr` if they depend on the template
>> args.
>>
>
> It's not exploring "weakness" in `constexpr`; it's exploiting rules in
> template instantiation. When you write a template function, whether the
> operations are constexpr or not depends on the template arguments passed
> in. So the compiler cannot detect any errors. And more importantly, the
> *user* cannot know if they've done the right thing or not.
>
> Therefore, the rules are different for template functions than
> non-template functions (no matter how much Bjarne seems to want to turn
> them into the same thing). In non-template code, you're saying "This
> function *will be* constexpr." In template code, you're saying, "Declare
> this function constexpr if all of the substituted operations are constexpr."
>
That's the source of confusing. A better constexpr design, IMHO, should
restrict the template one as well.
That is, in my example, if the function template `min` is declared
constexpr, `min(A{}, A{})` should fail to compile, to make it generic, it
should be declared as `generic` instead.
> I'm not positive, but I'd bet that the first phase of two-phase-lookup for
> template constexpr will statically fail if non-dependent operations are not
> constexpr.
>
> I understand what you want. I just don't know *why* you want it. Why do
> you want to shut off compile-time checking?
>
I think the reason is obvious. Yesterday we introduced constant expression
into the language, what happened? the STL are now updated with bunch of `
constexpr` here and there, and the user code that wants to take advantage
of that also needs to be manually marked. Tomorrow we introduce another
fancy-context and now, we need to mark the code again to adopt the new
context. What a frustrating process.
What if I, as the author of the function, want to tell the compiler that
this function has the potential to be evaluated in any context? We need a
way to do that, and that could be `inline`, or better yet,`generic`.
> I'm aware of the concerns shown here:
>> http://stackoverflow.com/a/19830673/2969631
>>
>
> It's interesting that you linked to the second answer, but seem to have
> ignored all of the (very good) points in the *first* answer. That argues
> more strongly even against you `generic` idea.
>
Well, the arguments are just not promising to me. When you call a generic
function, if it's not applicable to a certain context, it just fails to
compile, and you'll get the error, no harm will be caused.
--
---
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/.
--001a113fb33ac89a4a052148b4dd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2015=
-10-04 21:47 GMT+08:00 Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:=
jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span>:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><span class=3D""><br><br>On Sunday, October 4, 2015 at =
8:52:53 AM UTC-4, TONGARI J wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>=
We currently have 2 evaluation contexts in standrard C++:</div><div><ul><li=
>normal context<br></li><li>constant context</li></ul></div><div>In non-sta=
ndard world, we also have language-extensions like CUDA and C++AMP that pro=
vides GPU evaluation context.</div><div><br></div><div>Before C++11, we onl=
y had normal context=C2=A0in standrard. Everytime a new evaluation context =
is introduced into the language, it also requires us to 'mark' the =
functions manually in order to adopt the new context, for example:</div><di=
v><ul><li>constant expression - `<font face=3D"courier new, monospace">cons=
texpr</font>`<br></li><li>CUDA - `<font face=3D"courier new, monospace">__d=
evice__</font>`<br></li><li>C++AMP - `<font face=3D"courier new, monospace"=
>restrict(amp)</font>`<br></li><li>coroutine - probably `<font face=3D"cour=
ier new, monospace">resumable</font>` or `<font face=3D"courier new, monosp=
ace">async</font>`<br></li><li>etc...</li></ul></div><div>This is annoying,=
why can't the compiler treat inline functions in a context-agnostic wa=
y?</div></div></blockquote></span><div><br>Because each of those contexts h=
ave restrictions on what is allowed within them. `constexpr` is quite restr=
ictive compared to runtime. I don't know what goes on in `__device__` o=
r `restrict(amp)`, but I'd bet they are also restrictive as well.<br><b=
r>If I write code that I intend to be able to run at constexpr time, I <i>w=
ant</i> the compiler to make sure that I've written it correctly. I don=
't want the compiler to allow me to write invalid `constexpr` code and =
not tell me just because all of my uses of that function happen to be evalu=
ated at runtime.<br></div></blockquote><div><br></div><div>No disagreement =
here, but that's not the point. I'm not asking the compiler to allo=
w me to write invalid `constexpr` code, I'm just asking it to=C2=A0allo=
w me to write=C2=A0`generic` code that could be potentially treated as=C2=
=A0constant expression.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div></div><=
span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>It's =
interesting that the template one compiles while the non-template one fails=
..</div></div></blockquote><blockquote style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,20=
4);padding-left:1ex" class=3D"gmail_quote"><div>=C2=A0</div></blockquote><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div>The way standard algorithms exploits `=
<font face=3D"courier new, monospace">constexpr</font>` thus seems 'hac=
ky' -- it makes use of the weakness of `<font face=3D"courier new, mono=
space">constexpr</font>` that it can't check if the functions called ar=
e really `<font face=3D"courier new, monospace">constexpr</font>` if they d=
epend on the template args.</div></div></blockquote></span><div><br>It'=
s not exploring "weakness" in `constexpr`; it's exploiting ru=
les in template instantiation. When you write a template function, whether =
the operations are constexpr or not depends on the template arguments passe=
d in. So the compiler cannot detect any errors. And more importantly, the <=
i>user</i> cannot know if they've done the right thing or not.<br><br>T=
herefore, the rules are different for template functions than non-template =
functions (no matter how much=20
Bjarne seems to want to turn them into the same thing). In non-template cod=
e, you're saying "This function <i>will be</i> constexpr." In=
template code, you're saying, "Declare this function constexpr if=
all of the substituted operations are constexpr."</div></blockquote><=
div><br></div><div>That's the source of confusing. A better constexpr d=
esign, IMHO, should restrict the template one as well.</div><div>That is, i=
n my example, if the function template `<span style=3D"font-family:'cou=
rier new',monospace;font-size:14px">min</span>` is declared constexpr, =
`<span style=3D"font-family:'courier new',monospace;font-size:14px"=
>min(A{}, A{})</span>` should fail to compile, to make it generic, it shoul=
d be declared as `<span style=3D"font-family:'courier new',monospac=
e;font-size:14px">generic</span>` instead.</div><div>=C2=A0</div><blockquot=
e 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;padding-lef=
t:1ex"><div>I'm not positive, but I'd bet that the first phase of t=
wo-phase-lookup for template constexpr will statically fail if non-dependen=
t operations are not constexpr.<br><br>I understand what you want. I just d=
on't know <i>why</i> you want it. Why do you want to shut off compile-t=
ime checking?<br></div></blockquote><div><br></div><div>I think the reason =
is obvious. Yesterday we=C2=A0introduced constant expression into the langu=
age, what happened? the STL are now updated with bunch of=C2=A0<span style=
=3D"font-size:14px">`</span><span style=3D"font-family:'courier new'=
;,monospace;font-size:14px">constexpr</span>` here and there, and the user =
code that wants to take advantage of that also needs to be manually marked.=
Tomorrow we introduce another fancy-context and now, we need to mark the c=
ode again to adopt the new context. What a=C2=A0frustrating process.</div><=
div><br></div><div>What if I, as the author of the function, want to tell t=
he compiler that this function has the potential to be evaluated in any con=
text? We need a way to do that, and that could be=C2=A0<span style=3D"font-=
size:14px">`</span><font face=3D"courier new, monospace" style=3D"font-size=
:14px">inline</font><span style=3D"font-size:14px">`,=C2=A0</span>or better=
yet,<span style=3D"font-size:14px">`</span><font face=3D"courier new, mono=
space" style=3D"font-size:14px">generic</font><span style=3D"font-size:14px=
">`.</span></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div></div><span class=
=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>I'm aware of th=
e concerns shown here:</div><div><a href=3D"http://stackoverflow.com/a/1983=
0673/2969631" rel=3D"nofollow" target=3D"_blank">http://stackoverflow.com/a=
/19830673/2969631</a></div></div></blockquote></span><div><br>It's inte=
resting that you linked to the second answer, but seem to have ignored all =
of the (very good) points in the <i>first</i> answer. That argues more stro=
ngly even against you `generic` idea.</div></blockquote><div><br></div><div=
>Well, the arguments are just not promising to me. When you call a generic =
function, if it's not applicable to a certain context, it just fails to=
compile, and you'll get the error, no harm will be caused.</div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />
--001a113fb33ac89a4a052148b4dd--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sun, 4 Oct 2015 17:07:51 +0200
Raw View
--f46d0418270cae43be052148c2f7
Content-Type: text/plain; charset=UTF-8
On Sun, Oct 4, 2015 at 2:52 PM, TONGARI J <tongari95@gmail.com> wrote:
> A more reasonable way is to allow inline functions to be context-agnostic
> so we can define `min` as:
>
> template<class T>
> inline const T& min( const T& a, const T& b )
> {
> return (b < a) ? b : a;
> }
>
> When evaluated in constant context, the restrictions of
> constant-expression are automatically imposed,
>
This has been suggested before. You are essentially asking that all
functions that could be constexpr, be implicitly constexpr. Likewise for
the other "contexts".
The problem is compile-time. Compiling a constexpr function (for example)
is expensive. Doing it automatically for all function definitions would
increase compile times too much.
You have to explicitly mark the functions you want to use in constexpr
contexts, so the compiler knows it doesn't have to do the extra analysis
for all the other ones.
--
---
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/.
--f46d0418270cae43be052148c2f7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Oct 4, 2015 at 2:52 PM, TONGARI J <span dir=3D"ltr"><<a href=3D"mail=
to:tongari95@gmail.com" target=3D"_blank">tongari95@gmail.com</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>A more rea=
sonable way is to allow inline functions to be context-agnostic so we can d=
efine `<font face=3D"courier new, monospace">min</font>` as:<br></div><div>=
<br></div><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-w=
ord;background-color:rgb(250,250,250)"><code><div><span style=3D"color:#008=
">template</span><span style=3D"color:#660"><</span><span style=3D"color=
:#008">class</span><span style=3D"color:#000"> T</span><span style=3D"color=
:#660">></span><span style=3D"color:#000"> <br></span><span style=3D"col=
or:#008">inline</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#008">const</span><span style=3D"color:#000"> T</span><span style=3D"col=
or:#660">&</span><span style=3D"color:#000"> min</span><span style=3D"c=
olor:#660">(</span><span style=3D"color:#000"> </span><span style=3D"color:=
#008">const</span><span style=3D"color:#000"> T</span><span style=3D"color:=
#660">&</span><span style=3D"color:#000"> a</span><span style=3D"color:=
#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#008"=
>const</span><span style=3D"color:#000"> T</span><span style=3D"color:#660"=
>&</span><span style=3D"color:#000"> b </span><span style=3D"color:#660=
">)</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">=
{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"=
color:#008">return</span><span style=3D"color:#000"> </span><span style=3D"=
color:#660">(</span><span style=3D"color:#000">b </span><span style=3D"colo=
r:#660"><</span><span style=3D"color:#000"> a</span><span style=3D"color=
:#660">)</span><span style=3D"color:#000"> </span><span style=3D"color:#660=
">?</span><span style=3D"color:#000"> b </span><span style=3D"color:#660">:=
</span><span style=3D"color:#000"> a</span><span style=3D"color:#660">;</sp=
an><span style=3D"color:#000"><br></span><span style=3D"color:#660">}</span=
></div></code></div><div><br></div><div>When evaluated in constant context,=
the restrictions of constant-expression are automatically imposed, </div><=
/div></blockquote><div></div></div></div><div class=3D"gmail_extra"><br></d=
iv><div class=3D"gmail_extra">This has been suggested before.=C2=A0 You are=
essentially asking that all functions that could be constexpr, be implicit=
ly constexpr.=C2=A0 Likewise for the other "contexts".</div><div =
class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">The problem is c=
ompile-time.=C2=A0 Compiling a constexpr function (for example) is expensiv=
e.=C2=A0 Doing it automatically for all function definitions would increase=
compile times too much.</div><div class=3D"gmail_extra"><br></div><div cla=
ss=3D"gmail_extra">You have to explicitly mark the functions you want to us=
e in constexpr contexts, so the compiler knows it doesn't have to do th=
e extra analysis for all the other ones.</div><div class=3D"gmail_extra"><b=
r></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />
--f46d0418270cae43be052148c2f7--
.
Author: TONGARI J <tongari95@gmail.com>
Date: Sun, 4 Oct 2015 23:13:50 +0800
Raw View
--047d7b10c9cb207a4e052148d895
Content-Type: text/plain; charset=UTF-8
2015-10-04 23:07 GMT+08:00 Andrew Tomazos <andrewtomazos@gmail.com>:
> On Sun, Oct 4, 2015 at 2:52 PM, TONGARI J <tongari95@gmail.com> wrote:
>
>> A more reasonable way is to allow inline functions to be context-agnostic
>> so we can define `min` as:
>>
>> template<class T>
>> inline const T& min( const T& a, const T& b )
>> {
>> return (b < a) ? b : a;
>> }
>>
>> When evaluated in constant context, the restrictions of
>> constant-expression are automatically imposed,
>>
>
> This has been suggested before. You are essentially asking that all
> functions that could be constexpr, be implicitly constexpr. Likewise for
> the other "contexts".
>
> The problem is compile-time. Compiling a constexpr function (for example)
> is expensive. Doing it automatically for all function definitions would
> increase compile times too much.
>
> You have to explicitly mark the functions you want to use in constexpr
> contexts, so the compiler knows it doesn't have to do the extra analysis
> for all the other ones.
>
Yeah, I'm aware of that, please see the tail of my mail. I was suggesting a
new keyword `generic` if that's an issue. `generic` won't introduce more
overhead than `constexpr `, so what currently marked `constexpr ` in STL
could be marked as `generic` when feasible.
--
---
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/.
--047d7b10c9cb207a4e052148d895
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2015=
-10-04 23:07 GMT+08:00 Andrew Tomazos <span dir=3D"ltr"><<a href=3D"mail=
to:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.com</a>&g=
t;</span>:<br><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;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><div class=
=3D"gmail_extra"><div class=3D"gmail_quote">On Sun, Oct 4, 2015 at 2:52 PM,=
TONGARI J <span dir=3D"ltr"><<a href=3D"mailto:tongari95@gmail.com" tar=
get=3D"_blank">tongari95@gmail.com</a>></span> wrote:<br><blockquote cla=
ss=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;padding-left:1ex=
"><div dir=3D"ltr"><div>A more reasonable way is to allow inline functions =
to be context-agnostic so we can define `<font face=3D"courier new, monospa=
ce">min</font>` as:<br></div><div><br></div><div style=3D"border:1px solid =
rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><c=
ode><div><span style=3D"color:rgb(0,0,136)">template</span><span style=3D"c=
olor:rgb(102,102,0)"><</span><span style=3D"color:rgb(0,0,136)">class</s=
pan><span style=3D"color:rgb(0,0,0)"> T</span><span style=3D"color:rgb(102,=
102,0)">></span><span style=3D"color:rgb(0,0,0)"> <br></span><span style=
=3D"color:rgb(0,0,136)">inline</span><span style=3D"color:rgb(0,0,0)"> </sp=
an><span style=3D"color:rgb(0,0,136)">const</span><span style=3D"color:rgb(=
0,0,0)"> T</span><span style=3D"color:rgb(102,102,0)">&</span><span sty=
le=3D"color:rgb(0,0,0)"> min</span><span style=3D"color:rgb(102,102,0)">(</=
span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,=
136)">const</span><span style=3D"color:rgb(0,0,0)"> T</span><span style=3D"=
color:rgb(102,102,0)">&</span><span style=3D"color:rgb(0,0,0)"> a</span=
><span style=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,=
0)"> </span><span style=3D"color:rgb(0,0,136)">const</span><span style=3D"c=
olor:rgb(0,0,0)"> T</span><span style=3D"color:rgb(102,102,0)">&</span>=
<span style=3D"color:rgb(0,0,0)"> b </span><span style=3D"color:rgb(102,102=
,0)">)</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"col=
or:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color:rgb(0,0,136)">return</span><span style=3D"c=
olor:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">(</span><span=
style=3D"color:rgb(0,0,0)">b </span><span style=3D"color:rgb(102,102,0)">&=
lt;</span><span style=3D"color:rgb(0,0,0)"> a</span><span style=3D"color:rg=
b(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> </span><span style=
=3D"color:rgb(102,102,0)">?</span><span style=3D"color:rgb(0,0,0)"> b </spa=
n><span style=3D"color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0=
,0)"> a</span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"c=
olor:rgb(0,0,0)"><br></span><span style=3D"color:rgb(102,102,0)">}</span></=
div></code></div><div><br></div><div>When evaluated in constant context, th=
e restrictions of constant-expression are automatically imposed, </div></di=
v></blockquote><div></div></div></div><div class=3D"gmail_extra"><br></div>=
</span><div class=3D"gmail_extra">This has been suggested before.=C2=A0 You=
are essentially asking that all functions that could be constexpr, be impl=
icitly constexpr.=C2=A0 Likewise for the other "contexts".</div><=
div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">The problem =
is compile-time.=C2=A0 Compiling a constexpr function (for example) is expe=
nsive.=C2=A0 Doing it automatically for all function definitions would incr=
ease compile times too much.</div><div class=3D"gmail_extra"><br></div><div=
class=3D"gmail_extra">You have to explicitly mark the functions you want t=
o use in constexpr contexts, so the compiler knows it doesn't have to d=
o the extra analysis for all the other ones.</div></div></blockquote><div><=
br></div><div>Yeah, I'm aware of that, please see the tail of my mail. =
I was suggesting a new keyword `generic` if that's an issue.=C2=A0`gene=
ric`=C2=A0won't introduce more overhead than `constexpr=C2=A0`, so what=
currently marked `constexpr=C2=A0` in STL could be marked as `generic` whe=
n feasible.</div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />
--047d7b10c9cb207a4e052148d895--
.
Author: =?UTF-8?Q?Agust=c3=adn_K-ballo_Berg=c3=a9?= <kaballo86@hotmail.com>
Date: Sun, 4 Oct 2015 14:37:01 -0300
Raw View
On 10/4/2015 12:07 PM, Andrew Tomazos wrote:
> The problem is compile-time. Compiling a constexpr function (for
> example) is expensive. Doing it automatically for all function
> definitions would increase compile times too much.
The problem is not only compile-time, `constexpr` may affects whether=20
the program is well-formed. Constexpr functions are potentially=20
instantiated in unevaluated contexts. Have a look at CWG1581 for the=20
gory details, or check https://llvm.org/bugs/show_bug.cgi?id=3D23141 for=20
an actual case of `constexpr`-induced breakage.
> You have to explicitly mark the functions you want to use in constexpr
> contexts, so the compiler knows it doesn't have to do the extra analysis
> for all the other ones.
....nor breaks your program by doing something you did not want it to do.
Regards,
--=20
Agust=C3=ADn K-ballo Berg=C3=A9.-
http://talesofcpp.fusionfenix.com
--=20
---=20
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 e=
mail 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-proposa=
ls/.
.
Author: Jeremy Maitin-Shepard <jeremy@jeremyms.com>
Date: Sun, 4 Oct 2015 10:48:14 -0700 (PDT)
Raw View
------=_Part_3239_1970774455.1443980894907
Content-Type: multipart/alternative;
boundary="----=_Part_3240_81867770.1443980894907"
------=_Part_3240_81867770.1443980894907
Content-Type: text/plain; charset=UTF-8
On Sunday, October 4, 2015 at 8:07:56 AM UTC-7, Andrew Tomazos wrote:
>
> On Sun, Oct 4, 2015 at 2:52 PM, TONGARI J <tong...@gmail.com <javascript:>
> > wrote:
>
>> A more reasonable way is to allow inline functions to be context-agnostic
>> so we can define `min` as:
>>
>> template<class T>
>> inline const T& min( const T& a, const T& b )
>> {
>> return (b < a) ? b : a;
>> }
>>
>> When evaluated in constant context, the restrictions of
>> constant-expression are automatically imposed,
>>
>
> This has been suggested before. You are essentially asking that all
> functions that could be constexpr, be implicitly constexpr. Likewise for
> the other "contexts".
>
> The problem is compile-time. Compiling a constexpr function (for example)
> is expensive. Doing it automatically for all function definitions would
> increase compile times too much.
>
> You have to explicitly mark the functions you want to use in constexpr
> contexts, so the compiler knows it doesn't have to do the extra analysis
> for all the other ones.
>
I'm not sure I understand this point. I am not really aware of exactly how
constexpr evaluation is handled in compilers, but I assume it comes down to
storing some type of AST when the function is parsed, and then either
evaluating directly based on that or possibly converting it to some
intermediate representation, which could presumably be done in a JIT
fashion when actually required. In terms of just processing the
definition, I don't see how there can be a significantly greater cost to a
function marked inline constexpr compared to a function just marked inline
(or a template).
It seems that the only extra work should come when the function is actually
being evaluated in a constexpr context, i.e.
constexpr auto x = foo();
If it is never evaluated in a constexpr context, the extra cost should
never occur. Of course even in a runtime context the compiler may choose
to do constant folding, but it already may do that even for functions not
marked constexpr, so again there is no added cost to constexpr.
Another key point is that when designing a library, or any code designed to
be reusable, there tends to be no way to know that something would not
potentially be useful at compile-time, except if it is simply impossible,
e.g. because it involves a system call. Gradually every utility function
and algorithm in the c++ standard library is being marked constexpr. If we
get dynamic memory allocation at compile-time, which I hope we will, then
every data structure would also become fully constexpr, essentially leaving
just the C library, iostreams, and threading non-constexpr, and we could
potentially even allow threading at compile time. constexpr on functions
is starting to become just a syntactic tax.
--
---
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_3240_81867770.1443980894907
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, October 4, 2015 at 8:07:56 AM UTC-7, Andrew Tomazos wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"=
gmail_quote">On Sun, Oct 4, 2015 at 2:52 PM, TONGARI J <span dir=3D"ltr">&l=
t;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Tpcgxw=
6JCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';r=
eturn true;" onclick=3D"this.href=3D'javascript:';return true;">ton=
g...@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><div>A more reasonable way is to allow inline functions to be =
context-agnostic so we can define `<font face=3D"courier new, monospace">mi=
n</font>` as:<br></div><div><br></div><div style=3D"border:1px solid rgb(18=
7,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><code><d=
iv><span style=3D"color:#008">template</span><span style=3D"color:#660"><=
;</span><span style=3D"color:#008">class</span><span style=3D"color:#000"> =
T</span><span style=3D"color:#660">></span><span style=3D"color:#000"> <=
br></span><span style=3D"color:#008">inline</span><span style=3D"color:#000=
"> </span><span style=3D"color:#008">const</span><span style=3D"color:#000"=
> T</span><span style=3D"color:#660">&</span><span style=3D"color:#000"=
> min</span><span style=3D"color:#660">(</span><span style=3D"color:#000"> =
</span><span style=3D"color:#008">const</span><span style=3D"color:#000"> T=
</span><span style=3D"color:#660">&</span><span style=3D"color:#000"> a=
</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#008">const</span><span style=3D"color:#000"> T</spa=
n><span style=3D"color:#660">&</span><span style=3D"color:#000"> b </sp=
an><span style=3D"color:#660">)</span><span style=3D"color:#000"><br></span=
><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color:#008">return</span><span style=3D"color:=
#000"> </span><span style=3D"color:#660">(</span><span style=3D"color:#000"=
>b </span><span style=3D"color:#660"><</span><span style=3D"color:#000">=
a</span><span style=3D"color:#660">)</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#660">?</span><span style=3D"color:#000"> b </span=
><span style=3D"color:#660">:</span><span style=3D"color:#000"> a</span><sp=
an style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span=
style=3D"color:#660">}</span></div></code></div><div><br></div><div>When e=
valuated in constant context, the restrictions of constant-expression are a=
utomatically imposed, </div></div></blockquote><div></div></div></div><div>=
<br></div><div>This has been suggested before.=C2=A0 You are essentially as=
king that all functions that could be constexpr, be implicitly constexpr.=
=C2=A0 Likewise for the other "contexts".</div><div><br></div><di=
v>The problem is compile-time.=C2=A0 Compiling a constexpr function (for ex=
ample) is expensive.=C2=A0 Doing it automatically for all function definiti=
ons would increase compile times too much.</div><div><br></div><div>You hav=
e to explicitly mark the functions you want to use in constexpr contexts, s=
o the compiler knows it doesn't have to do the extra analysis for all t=
he other ones.</div></div></blockquote><div><br>I'm not sure I understa=
nd this point.=C2=A0 I am not really aware of exactly how constexpr evaluat=
ion is handled in compilers, but I assume it comes down to storing some typ=
e of AST when the function is parsed, and then either evaluating directly b=
ased on that or possibly converting it to some intermediate representation,=
which could presumably be done in a JIT fashion when actually required.=C2=
=A0 In terms of just processing the definition, I don't see how there c=
an be a significantly greater cost to a function marked inline constexpr co=
mpared to a function just marked inline (or a template).<br><br>It seems th=
at the only extra work should come when the function is actually being eval=
uated in a constexpr context, i.e.<br><br>constexpr auto x =3D foo();<br><b=
r>If it is never evaluated in a constexpr context, the extra cost should ne=
ver occur.=C2=A0 Of course even in a runtime context the compiler may choos=
e to do constant folding, but it already may do that even for functions not=
marked constexpr, so again there is no added cost to constexpr.<br><br>Ano=
ther key point is that when designing a library, or any code designed to be=
reusable, there tends to be no way to know that something would not potent=
ially be useful at compile-time, except if it is simply impossible, e.g. be=
cause it involves a system call.=C2=A0 Gradually every utility function and=
algorithm in the c++ standard library is being marked constexpr.=C2=A0 If =
we get dynamic memory allocation at compile-time, which I hope we will, the=
n every data structure would also become fully constexpr, essentially leavi=
ng just the C library, iostreams, and threading non-constexpr, and we could=
potentially even allow threading at compile time.=C2=A0 constexpr on funct=
ions is starting to become just a syntactic tax.<br></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_3240_81867770.1443980894907--
------=_Part_3239_1970774455.1443980894907--
.
Author: Jeremy Maitin-Shepard <jeremy@jeremyms.com>
Date: Sun, 4 Oct 2015 11:18:48 -0700 (PDT)
Raw View
------=_Part_3313_753990516.1443982729010
Content-Type: multipart/alternative;
boundary="----=_Part_3314_1359496908.1443982729010"
------=_Part_3314_1359496908.1443982729010
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, October 4, 2015 at 10:37:07 AM UTC-7, Agust=C3=ADn K-ballo Berg=
=C3=A9=20
wrote:
>
> On 10/4/2015 12:07 PM, Andrew Tomazos wrote:=20
> > The problem is compile-time. Compiling a constexpr function (for=20
> > example) is expensive. Doing it automatically for all function=20
> > definitions would increase compile times too much.=20
>
> The problem is not only compile-time, `constexpr` may affects whether=20
> the program is well-formed. Constexpr functions are potentially=20
> instantiated in unevaluated contexts. Have a look at CWG1581 for the=20
> gory details, or check https://llvm.org/bugs/show_bug.cgi?id=3D23141 for=
=20
> an actual case of `constexpr`-induced breakage.=20
>
I don't see a specific resolution listed for that issue, specifically in=20
regards to the "Note from the April, 2013 meeting", which seems to address=
=20
the critical part.
--=20
---=20
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 e=
mail 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-proposa=
ls/.
------=_Part_3314_1359496908.1443982729010
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, October 4, 2015 at 10:37:07 AM UTC-7, Agust=C3=ADn K-ballo Berg=
=C3=A9 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10/4/2015 12:0=
7 PM, Andrew Tomazos wrote:
<br>> The problem is compile-time. =C2=A0Compiling a constexpr function =
(for
<br>> example) is expensive. =C2=A0Doing it automatically for all functi=
on
<br>> definitions would increase compile times too much.
<br>
<br>The problem is not only compile-time, `constexpr` may affects whether=
=20
<br>the program is well-formed. Constexpr functions are potentially=20
<br>instantiated in unevaluated contexts. Have a look at CWG1581 for the=20
<br>gory details, or check <a href=3D"https://llvm.org/bugs/show_bug.cgi?id=
=3D23141" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D=
9;https://www.google.com/url?q\75https%3A%2F%2Fllvm.org%2Fbugs%2Fshow_bug.c=
gi%3Fid%3D23141\46sa\75D\46sntz\0751\46usg\75AFQjCNFONqxcgSN_KISuTw8jWnwS1m=
zBfw';return true;" onclick=3D"this.href=3D'https://www.google.com/=
url?q\75https%3A%2F%2Fllvm.org%2Fbugs%2Fshow_bug.cgi%3Fid%3D23141\46sa\75D\=
46sntz\0751\46usg\75AFQjCNFONqxcgSN_KISuTw8jWnwS1mzBfw';return true;">h=
ttps://llvm.org/bugs/show_<wbr>bug.cgi?id=3D23141</a> for=20
<br>an actual case of `constexpr`-induced breakage.
<br></blockquote><div><br>I don't see a specific resolution listed for =
that issue, specifically in regards to the "Note from the April, 2013 =
meeting", which seems to address the critical part.<br></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_3314_1359496908.1443982729010--
------=_Part_3313_753990516.1443982729010--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 4 Oct 2015 11:39:51 -0700 (PDT)
Raw View
------=_Part_2615_1491706365.1443983991256
Content-Type: multipart/alternative;
boundary="----=_Part_2616_952678255.1443983991256"
------=_Part_2616_952678255.1443983991256
Content-Type: text/plain; charset=UTF-8
On Sunday, October 4, 2015 at 11:03:59 AM UTC-4, TONGARI J wrote:
>
> 2015-10-04 21:47 GMT+08:00 Nicol Bolas <jmck...@gmail.com <javascript:>>:
>
>> On Sunday, October 4, 2015 at 8:52:53 AM UTC-4, TONGARI J wrote:
>>>
>>> We currently have 2 evaluation contexts in standrard C++:
>>>
>> I'm aware of the concerns shown here:
>>> http://stackoverflow.com/a/19830673/2969631
>>>
>>
>> It's interesting that you linked to the second answer, but seem to have
>> ignored all of the (very good) points in the *first* answer. That argues
>> more strongly even against you `generic` idea.
>>
>
> Well, the arguments are just not promising to me. When you call a generic
> function, if it's not applicable to a certain context, it just fails to
> compile, and you'll get the error, no harm will be caused.
>
The strongest argument (to me) made in that post against your idea has to
do with contracts.
A function signature is a contract between me, the user of that function,
and you, the writer of that function. When you put a parameter into that
signature, it is my responsibility to provide a value for that parameter
when I call your function. And C++ statically checks that this contract is
being fulfilled.
Similarly, when you put `constexpr` in a function's signature, you are
saying that it is legal for me to use this function in constant contexts.
When you put `constexpr` in a template function's signature, you are saying
that it is legal for me to use this function in constant contexts when
instantiated with types that fulfill certain conditions (which due to lack
of syntax, are currently un-specifiable).
OK, so what does `generic` mean? What contract does that create?
It certainly *does not* mean `constexpr`; I have no guarantees that the
function with such a decoration will be executable in a constant expression
context. So what does it mean to me?
If you give me a library function that is `constexpr`, I am free to use it
in a `constexpr` way. However, if you later update that library to remove
`constexpr` from the function's signature, that represents a *breaking
change*. Which you should inform people of before giving them an update.
The most important part of this breaking change is this: it did not happen
by accident (probably). To make this change, you had to *change the
function's signature*. And thereby change the contract with the user. You
couldn't do that by accident.
If you give me a library function that is `generic`... what can I do with
that? Even if your current implementation happens to permit usage in
constant expressions, what guarantee do I have that you won't change that
in the future? A function signature is supposed to be a contract, but yours
is very... loose. It tells me nothing about where I may use it.
Even worse, you can change the contract *by accident*. If none of your
tests use the function in constant expressions, then you can accidentally
do something that is not constexpr-legal. Your code won't complain at all.
You will have changed the contract without being aware of it. And
therefore, you will have broken me without knowing that you should tell me
first.
To protect myself from such dangerous, accidental changes, I will have no
choice but to treat your `generic` functions as though they were not
potentially `constexpr`. I'll likely write a non-constexpr wrapper function
that forwards from/to it.
So you've ultimately gained *nothing*.
--
---
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_2616_952678255.1443983991256
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, October 4, 2015 at 11:03:59 AM UTC-4, TONGARI J wrote:<blockquot=
e 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><div class=3D"gmai=
l_quote">2015-10-04 21:47 GMT+08:00 Nicol Bolas <span dir=3D"ltr"><<a hr=
ef=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"FlRrldeICwAJ"=
rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return t=
rue;" onclick=3D"this.href=3D'javascript:';return true;">jmck...@gm=
ail.com</a>></span>:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex"><span>On Sunday, October 4, 201=
5 at 8:52:53 AM UTC-4, TONGARI J wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb=
(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv>We currently have 2 evaluation contexts in standrard C++: <br></div></di=
v></blockquote></span></blockquote><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div></div><span><bloc=
kquote 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;paddin=
g-left:1ex"><div dir=3D"ltr"><div></div><div>I'm aware of the concerns =
shown here:</div><div><a href=3D"http://stackoverflow.com/a/19830673/296963=
1" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fstackoverflow.com%2Fa%2F19830673%2F29=
69631\46sa\75D\46sntz\0751\46usg\75AFQjCNHuGmZEDNLKrsCCTAEl6fhJjDdOaw';=
return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75htt=
p%3A%2F%2Fstackoverflow.com%2Fa%2F19830673%2F2969631\46sa\75D\46sntz\0751\4=
6usg\75AFQjCNHuGmZEDNLKrsCCTAEl6fhJjDdOaw';return true;">http://stackov=
erflow.com/a/<wbr>19830673/2969631</a></div></div></blockquote></span><div>=
<br>It's interesting that you linked to the second answer, but seem to =
have ignored all of the (very good) points in the <i>first</i> answer. That=
argues more strongly even against you `generic` idea.</div></blockquote><d=
iv><br></div><div>Well, the arguments are just not promising to me. When yo=
u call a generic function, if it's not applicable to a certain context,=
it just fails to compile, and you'll get the error, no harm will be ca=
used.</div></div></div></div></blockquote><div><br>The strongest argument (=
to me) made in that post against your idea has to do with contracts.<br><br=
>A function signature is a contract between me, the user of that function, =
and you, the writer of that function. When you put a parameter into that si=
gnature, it is my responsibility to provide a value for that parameter when=
I call your function. And C++ statically checks that this contract is bein=
g fulfilled.<br><br>Similarly, when you put `constexpr` in a function's=
signature, you are saying that it is legal for me to use this function in =
constant contexts. When you put `constexpr` in a template function's si=
gnature, you are saying that it is legal for me to use this function in con=
stant contexts when instantiated with types that fulfill certain conditions=
(which due to lack of syntax, are currently un-specifiable).<br><br>OK, so=
what does `generic` mean? What contract does that create?<br><br>It certai=
nly <i>does not</i> mean `constexpr`; I have no guarantees that the functio=
n with such a decoration will be executable in a constant expression contex=
t. So what does it mean to me?<br><br>If you give me a library function tha=
t is `constexpr`, I am free to use it in a `constexpr` way. However, if you=
later update that library to remove `constexpr` from the function's si=
gnature, that represents a <i>breaking change</i>. Which you should inform =
people of before giving them an update.<br><br>The most important part of t=
his breaking change is this: it did not happen by accident (probably). To m=
ake this change, you had to <i>change the function's signature</i>. And=
thereby change the contract with the user. You couldn't do that by acc=
ident.<br><br>If you give me a library function that is `generic`... what c=
an I do with that? Even if your current implementation happens to permit us=
age in constant expressions, what guarantee do I have that you won't ch=
ange that in the future? A function signature is supposed to be a contract,=
but yours is very... loose. It tells me nothing about where I may use it.<=
br><br>Even worse, you can change the contract <i>by accident</i>. If none =
of your tests use the function in constant expressions, then you can accide=
ntally do something that is not constexpr-legal. Your code won't compla=
in at all. You will have changed the contract without being aware of it. An=
d therefore, you will have broken me without knowing that you should tell m=
e first.<br><br>To protect myself from such dangerous, accidental changes, =
I will have no choice but to treat your `generic` functions as though they =
were not potentially `constexpr`. I'll likely write a non-constexpr wra=
pper function that forwards from/to it.<br><br>So you've ultimately gai=
ned <i>nothing</i>.<br></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_2616_952678255.1443983991256--
------=_Part_2615_1491706365.1443983991256--
.
Author: =?UTF-8?Q?Agust=c3=adn_K-ballo_Berg=c3=a9?= <kaballo86@hotmail.com>
Date: Sun, 4 Oct 2015 15:44:41 -0300
Raw View
On 10/4/2015 3:18 PM, Jeremy Maitin-Shepard wrote:
> On Sunday, October 4, 2015 at 10:37:07 AM UTC-7, Agust=C3=ADn K-ballo Ber=
g=C3=A9
> wrote:
>
> On 10/4/2015 12:07 PM, Andrew Tomazos wrote:
> > The problem is compile-time. Compiling a constexpr function (for
> > example) is expensive. Doing it automatically for all function
> > definitions would increase compile times too much.
>
> The problem is not only compile-time, `constexpr` may affects whether
> the program is well-formed. Constexpr functions are potentially
> instantiated in unevaluated contexts. Have a look at CWG1581 for the
> gory details, or check https://llvm.org/bugs/show_bug.cgi?id=3D23141
> <https://llvm.org/bugs/show_bug.cgi?id=3D23141> for
> an actual case of `constexpr`-induced breakage.
>
>
> I don't see a specific resolution listed for that issue, specifically in
> regards to the "Note from the April, 2013 meeting", which seems to
> address the critical part.
You don't see a resolution because that issue is still active.
Regards,
--=20
Agust=C3=ADn K-ballo Berg=C3=A9.-
http://talesofcpp.fusionfenix.com
--=20
---=20
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 e=
mail 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-proposa=
ls/.
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sun, 4 Oct 2015 22:38:45 +0200
Raw View
--001a11c2b90c21228f05214d6274
Content-Type: text/plain; charset=UTF-8
On Sun, Oct 4, 2015 at 7:48 PM, Jeremy Maitin-Shepard <jeremy@jeremyms.com>
wrote:
> On Sunday, October 4, 2015 at 8:07:56 AM UTC-7, Andrew Tomazos wrote:
>>
>> On Sun, Oct 4, 2015 at 2:52 PM, TONGARI J <tong...@gmail.com> wrote:
>>
>>> A more reasonable way is to allow inline functions to be
>>> context-agnostic so we can define `min` as:
>>>
>>> template<class T>
>>> inline const T& min( const T& a, const T& b )
>>> {
>>> return (b < a) ? b : a;
>>> }
>>>
>>> When evaluated in constant context, the restrictions of
>>> constant-expression are automatically imposed,
>>>
>>
>> This has been suggested before. You are essentially asking that all
>> functions that could be constexpr, be implicitly constexpr. Likewise for
>> the other "contexts".
>>
>> The problem is compile-time. Compiling a constexpr function (for
>> example) is expensive. Doing it automatically for all function definitions
>> would increase compile times too much.
>>
>> You have to explicitly mark the functions you want to use in constexpr
>> contexts, so the compiler knows it doesn't have to do the extra analysis
>> for all the other ones.
>>
>
> I'm not sure I understand this point. I am not really aware of exactly
> how constexpr evaluation is handled in compilers, but I assume it comes
> down to storing some type of AST when the function is parsed, and then
> either evaluating directly based on that or possibly converting it to some
> intermediate representation, which could presumably be done in a JIT
> fashion when actually required.
>
I just tested it (gcc 5.2) and observed that a 5-line C++14 constexpr
function definition takes 5% longer to compile (~105us) than the same
inline function (~100us) (even if it isn't used). This is less than I
expected, but still quite significant.
It is unclear to me whether this completely highlights the performance
concerns about implicit constexpr. Admittedly I am reporting them
second-hand.
--
---
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/.
--001a11c2b90c21228f05214d6274
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Oct 4, 2015 at 7:48 PM, Jeremy Maitin-Shepard <span dir=3D"ltr"><<a =
href=3D"mailto:jeremy@jeremyms.com" target=3D"_blank">jeremy@jeremyms.com</=
a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sunday, October 4=
, 2015 at 8:07:56 AM UTC-7, Andrew Tomazos wrote:<span class=3D""><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_qu=
ote">On Sun, Oct 4, 2015 at 2:52 PM, TONGARI J <span dir=3D"ltr"><<a rel=
=3D"nofollow">tong...@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div>A more reasonable way is to allow inlin=
e functions to be context-agnostic so we can define `<font face=3D"courier =
new, monospace">min</font>` as:<br></div><div><br></div><div style=3D"borde=
r:1px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,=
250,250)"><code><div><span style=3D"color:#008">template</span><span style=
=3D"color:#660"><</span><span style=3D"color:#008">class</span><span sty=
le=3D"color:#000"> T</span><span style=3D"color:#660">></span><span styl=
e=3D"color:#000"> <br></span><span style=3D"color:#008">inline</span><span =
style=3D"color:#000"> </span><span style=3D"color:#008">const</span><span s=
tyle=3D"color:#000"> T</span><span style=3D"color:#660">&</span><span s=
tyle=3D"color:#000"> min</span><span style=3D"color:#660">(</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#008">const</span><span styl=
e=3D"color:#000"> T</span><span style=3D"color:#660">&</span><span styl=
e=3D"color:#000"> a</span><span style=3D"color:#660">,</span><span style=3D=
"color:#000"> </span><span style=3D"color:#008">const</span><span style=3D"=
color:#000"> T</span><span style=3D"color:#660">&</span><span style=3D"=
color:#000"> b </span><span style=3D"color:#660">)</span><span style=3D"col=
or:#000"><br></span><span style=3D"color:#660">{</span><span style=3D"color=
:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">return</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#660">(</span><span st=
yle=3D"color:#000">b </span><span style=3D"color:#660"><</span><span sty=
le=3D"color:#000"> a</span><span style=3D"color:#660">)</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">?</span><span style=3D"c=
olor:#000"> b </span><span style=3D"color:#660">:</span><span style=3D"colo=
r:#000"> a</span><span style=3D"color:#660">;</span><span style=3D"color:#0=
00"><br></span><span style=3D"color:#660">}</span></div></code></div><div><=
br></div><div>When evaluated in constant context, the restrictions of const=
ant-expression are automatically imposed, </div></div></blockquote><div></d=
iv></div></div><div><br></div><div>This has been suggested before.=C2=A0 Yo=
u are essentially asking that all functions that could be constexpr, be imp=
licitly constexpr.=C2=A0 Likewise for the other "contexts".</div>=
<div><br></div><div>The problem is compile-time.=C2=A0 Compiling a constexp=
r function (for example) is expensive.=C2=A0 Doing it automatically for all=
function definitions would increase compile times too much.</div><div><br>=
</div><div>You have to explicitly mark the functions you want to use in con=
stexpr contexts, so the compiler knows it doesn't have to do the extra =
analysis for all the other ones.</div></div></blockquote></span><div><br>I&=
#39;m not sure I understand this point.=C2=A0 I am not really aware of exac=
tly how constexpr evaluation is handled in compilers, but I assume it comes=
down to storing some type of AST when the function is parsed, and then eit=
her evaluating directly based on that or possibly converting it to some int=
ermediate representation, which could presumably be done in a JIT fashion w=
hen actually required.</div></blockquote><div></div></div><br></div><div cl=
ass=3D"gmail_extra">I just tested it (gcc 5.2) and observed that a 5-line C=
++14 constexpr function definition takes 5% longer to compile (~105us) than=
the same inline function (~100us) (even if it isn't used).=C2=A0 This =
is less than I expected, but still quite significant.</div><div class=3D"gm=
ail_extra"><br></div><div class=3D"gmail_extra">It is unclear to me whether=
this completely highlights the performance concerns about implicit constex=
pr.=C2=A0 Admittedly I am reporting them second-hand.</div><div class=3D"gm=
ail_extra"><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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />
--001a11c2b90c21228f05214d6274--
.
Author: TONGARI J <tongari95@gmail.com>
Date: Mon, 5 Oct 2015 10:05:20 +0800
Raw View
--001a113f921e12ea52052151f225
Content-Type: text/plain; charset=UTF-8
2015-10-05 4:38 GMT+08:00 Andrew Tomazos <andrewtomazos@gmail.com>:
> On Sun, Oct 4, 2015 at 7:48 PM, Jeremy Maitin-Shepard <jeremy@jeremyms.com
> > wrote:
>
>> On Sunday, October 4, 2015 at 8:07:56 AM UTC-7, Andrew Tomazos wrote:
>>>
>>> On Sun, Oct 4, 2015 at 2:52 PM, TONGARI J <tong...@gmail.com> wrote:
>>>
>>>> A more reasonable way is to allow inline functions to be
>>>> context-agnostic so we can define `min` as:
>>>>
>>>> template<class T>
>>>> inline const T& min( const T& a, const T& b )
>>>> {
>>>> return (b < a) ? b : a;
>>>> }
>>>>
>>>> When evaluated in constant context, the restrictions of
>>>> constant-expression are automatically imposed,
>>>>
>>>
>>> This has been suggested before. You are essentially asking that all
>>> functions that could be constexpr, be implicitly constexpr. Likewise for
>>> the other "contexts".
>>>
>>> The problem is compile-time. Compiling a constexpr function (for
>>> example) is expensive. Doing it automatically for all function definitions
>>> would increase compile times too much.
>>>
>>> You have to explicitly mark the functions you want to use in constexpr
>>> contexts, so the compiler knows it doesn't have to do the extra analysis
>>> for all the other ones.
>>>
>>
>> I'm not sure I understand this point. I am not really aware of exactly
>> how constexpr evaluation is handled in compilers, but I assume it comes
>> down to storing some type of AST when the function is parsed, and then
>> either evaluating directly based on that or possibly converting it to some
>> intermediate representation, which could presumably be done in a JIT
>> fashion when actually required.
>>
>
> I just tested it (gcc 5.2) and observed that a 5-line C++14 constexpr
> function definition takes 5% longer to compile (~105us) than the same
> inline function (~100us) (even if it isn't used). This is less than I
> expected, but still quite significant.
>
> It is unclear to me whether this completely highlights the performance
> concerns about implicit constexpr. Admittedly I am reporting them
> second-hand.
>
Out of curiosity, is your test function templated or not?
--
---
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/.
--001a113f921e12ea52052151f225
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2015=
-10-05 4:38 GMT+08:00 Andrew Tomazos <span dir=3D"ltr"><<a href=3D"mailt=
o:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.com</a>>=
;</span>:<br><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;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><div class=
=3D"gmail_extra"><div class=3D"gmail_quote">On Sun, Oct 4, 2015 at 7:48 PM,=
Jeremy Maitin-Shepard <span dir=3D"ltr"><<a href=3D"mailto:jeremy@jerem=
yms.com" target=3D"_blank">jeremy@jeremyms.com</a>></span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd=
ing-left:1ex">On Sunday, October 4, 2015 at 8:07:56 AM UTC-7, Andrew Tomazo=
s wrote:<span><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;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_qu=
ote">On Sun, Oct 4, 2015 at 2:52 PM, TONGARI J <span dir=3D"ltr"><<a rel=
=3D"nofollow">tong...@gmail.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div dir=3D"ltr"><div>A more reasonable way is to allow inline functions to=
be context-agnostic so we can define `<font face=3D"courier new, monospace=
">min</font>` as:<br></div><div><br></div><div style=3D"border:1px solid rg=
b(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><cod=
e><div><span style=3D"color:rgb(0,0,136)">template</span><span style=3D"col=
or:rgb(102,102,0)"><</span><span style=3D"color:rgb(0,0,136)">class</spa=
n><span style=3D"color:rgb(0,0,0)"> T</span><span style=3D"color:rgb(102,10=
2,0)">></span><span style=3D"color:rgb(0,0,0)"> <br></span><span style=
=3D"color:rgb(0,0,136)">inline</span><span style=3D"color:rgb(0,0,0)"> </sp=
an><span style=3D"color:rgb(0,0,136)">const</span><span style=3D"color:rgb(=
0,0,0)"> T</span><span style=3D"color:rgb(102,102,0)">&</span><span sty=
le=3D"color:rgb(0,0,0)"> min</span><span style=3D"color:rgb(102,102,0)">(</=
span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,=
136)">const</span><span style=3D"color:rgb(0,0,0)"> T</span><span style=3D"=
color:rgb(102,102,0)">&</span><span style=3D"color:rgb(0,0,0)"> a</span=
><span style=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,=
0)"> </span><span style=3D"color:rgb(0,0,136)">const</span><span style=3D"c=
olor:rgb(0,0,0)"> T</span><span style=3D"color:rgb(102,102,0)">&</span>=
<span style=3D"color:rgb(0,0,0)"> b </span><span style=3D"color:rgb(102,102=
,0)">)</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"col=
or:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color:rgb(0,0,136)">return</span><span style=3D"c=
olor:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">(</span><span=
style=3D"color:rgb(0,0,0)">b </span><span style=3D"color:rgb(102,102,0)">&=
lt;</span><span style=3D"color:rgb(0,0,0)"> a</span><span style=3D"color:rg=
b(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> </span><span style=
=3D"color:rgb(102,102,0)">?</span><span style=3D"color:rgb(0,0,0)"> b </spa=
n><span style=3D"color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0=
,0)"> a</span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"c=
olor:rgb(0,0,0)"><br></span><span style=3D"color:rgb(102,102,0)">}</span></=
div></code></div><div><br></div><div>When evaluated in constant context, th=
e restrictions of constant-expression are automatically imposed, </div></di=
v></blockquote><div></div></div></div><div><br></div><div>This has been sug=
gested before.=C2=A0 You are essentially asking that all functions that cou=
ld be constexpr, be implicitly constexpr.=C2=A0 Likewise for the other &quo=
t;contexts".</div><div><br></div><div>The problem is compile-time.=C2=
=A0 Compiling a constexpr function (for example) is expensive.=C2=A0 Doing =
it automatically for all function definitions would increase compile times =
too much.</div><div><br></div><div>You have to explicitly mark the function=
s you want to use in constexpr contexts, so the compiler knows it doesn'=
;t have to do the extra analysis for all the other ones.</div></div></block=
quote></span><div><br>I'm not sure I understand this point.=C2=A0 I am =
not really aware of exactly how constexpr evaluation is handled in compiler=
s, but I assume it comes down to storing some type of AST when the function=
is parsed, and then either evaluating directly based on that or possibly c=
onverting it to some intermediate representation, which could presumably be=
done in a JIT fashion when actually required.</div></blockquote><div></div=
></div><br></div></span><div class=3D"gmail_extra">I just tested it (gcc 5.=
2) and observed that a 5-line C++14 constexpr function definition takes 5% =
longer to compile (~105us) than the same inline function (~100us) (even if =
it isn't used).=C2=A0 This is less than I expected, but still quite sig=
nificant.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ext=
ra">It is unclear to me whether this completely highlights the performance =
concerns about implicit constexpr.=C2=A0 Admittedly I am reporting them sec=
ond-hand.</div></div></blockquote><div><br></div><div>Out of curiosity, is =
your test function templated or not?</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />
--001a113f921e12ea52052151f225--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Mon, 5 Oct 2015 15:38:48 +0200
Raw View
--f46d04374a051bdae805215ba25d
Content-Type: text/plain; charset=UTF-8
On Mon, Oct 5, 2015 at 4:05 AM, TONGARI J <tongari95@gmail.com> wrote:
> 2015-10-05 4:38 GMT+08:00 Andrew Tomazos <andrewtomazos@gmail.com>:
>
>> On Sun, Oct 4, 2015 at 7:48 PM, Jeremy Maitin-Shepard <
>> jeremy@jeremyms.com> wrote:
>>
>>> On Sunday, October 4, 2015 at 8:07:56 AM UTC-7, Andrew Tomazos wrote:
>>>>
>>>> On Sun, Oct 4, 2015 at 2:52 PM, TONGARI J <tong...@gmail.com> wrote:
>>>>
>>>>> A more reasonable way is to allow inline functions to be
>>>>> context-agnostic so we can define `min` as:
>>>>>
>>>>> template<class T>
>>>>> inline const T& min( const T& a, const T& b )
>>>>> {
>>>>> return (b < a) ? b : a;
>>>>> }
>>>>>
>>>>> When evaluated in constant context, the restrictions of
>>>>> constant-expression are automatically imposed,
>>>>>
>>>>
>>>> This has been suggested before. You are essentially asking that all
>>>> functions that could be constexpr, be implicitly constexpr. Likewise for
>>>> the other "contexts".
>>>>
>>>> The problem is compile-time. Compiling a constexpr function (for
>>>> example) is expensive. Doing it automatically for all function definitions
>>>> would increase compile times too much.
>>>>
>>>> You have to explicitly mark the functions you want to use in constexpr
>>>> contexts, so the compiler knows it doesn't have to do the extra analysis
>>>> for all the other ones.
>>>>
>>>
>>> I'm not sure I understand this point. I am not really aware of exactly
>>> how constexpr evaluation is handled in compilers, but I assume it comes
>>> down to storing some type of AST when the function is parsed, and then
>>> either evaluating directly based on that or possibly converting it to some
>>> intermediate representation, which could presumably be done in a JIT
>>> fashion when actually required.
>>>
>>
>> I just tested it (gcc 5.2) and observed that a 5-line C++14 constexpr
>> function definition takes 5% longer to compile (~105us) than the same
>> inline function (~100us) (even if it isn't used). This is less than I
>> expected, but still quite significant.
>>
>> It is unclear to me whether this completely highlights the performance
>> concerns about implicit constexpr. Admittedly I am reporting them
>> second-hand.
>>
>
> Out of curiosity, is your test function templated or not?
>
> not.
--
---
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/.
--f46d04374a051bdae805215ba25d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Oct 5, 2015 at 4:05 AM, TONGARI J <span dir=3D"ltr"><<a href=
=3D"mailto:tongari95@gmail.com" target=3D"_blank">tongari95@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div cl=
ass=3D"gmail_extra"><div class=3D"gmail_quote"><div><div class=3D"h5">2015-=
10-05 4:38 GMT+08:00 Andrew Tomazos <span dir=3D"ltr"><<a href=3D"mailto=
:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.com</a>>=
</span>:<br><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-s=
tyle:solid;padding-left:1ex"><div dir=3D"ltr"><span><div class=3D"gmail_ext=
ra"><div class=3D"gmail_quote">On Sun, Oct 4, 2015 at 7:48 PM, Jeremy Maiti=
n-Shepard <span dir=3D"ltr"><<a href=3D"mailto:jeremy@jeremyms.com" targ=
et=3D"_blank">jeremy@jeremyms.com</a>></span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
>On Sunday, October 4, 2015 at 8:07:56 AM UTC-7, Andrew Tomazos wrote:<span=
><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;=
padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Sun, =
Oct 4, 2015 at 2:52 PM, TONGARI J <span dir=3D"ltr"><<a rel=3D"nofollow"=
>tong...@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"lt=
r"><div>A more reasonable way is to allow inline functions to be context-ag=
nostic so we can define `<font face=3D"courier new, monospace">min</font>` =
as:<br></div><div><br></div><div style=3D"border:1px solid rgb(187,187,187)=
;word-wrap:break-word;background-color:rgb(250,250,250)"><code><div><span s=
tyle=3D"color:rgb(0,0,136)">template</span><span style=3D"color:rgb(102,102=
,0)"><</span><span style=3D"color:rgb(0,0,136)">class</span><span style=
=3D"color:rgb(0,0,0)"> T</span><span style=3D"color:rgb(102,102,0)">></s=
pan><span style=3D"color:rgb(0,0,0)"> <br></span><span style=3D"color:rgb(0=
,0,136)">inline</span><span style=3D"color:rgb(0,0,0)"> </span><span style=
=3D"color:rgb(0,0,136)">const</span><span style=3D"color:rgb(0,0,0)"> T</sp=
an><span style=3D"color:rgb(102,102,0)">&</span><span style=3D"color:rg=
b(0,0,0)"> min</span><span style=3D"color:rgb(102,102,0)">(</span><span sty=
le=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">const</s=
pan><span style=3D"color:rgb(0,0,0)"> T</span><span style=3D"color:rgb(102,=
102,0)">&</span><span style=3D"color:rgb(0,0,0)"> a</span><span style=
=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> </span>=
<span style=3D"color:rgb(0,0,136)">const</span><span style=3D"color:rgb(0,0=
,0)"> T</span><span style=3D"color:rgb(102,102,0)">&</span><span style=
=3D"color:rgb(0,0,0)"> b </span><span style=3D"color:rgb(102,102,0)">)</spa=
n><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(102,=
102,0)">{</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><=
span style=3D"color:rgb(0,0,136)">return</span><span style=3D"color:rgb(0,0=
,0)"> </span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"co=
lor:rgb(0,0,0)">b </span><span style=3D"color:rgb(102,102,0)"><</span><s=
pan style=3D"color:rgb(0,0,0)"> a</span><span style=3D"color:rgb(102,102,0)=
">)</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb=
(102,102,0)">?</span><span style=3D"color:rgb(0,0,0)"> b </span><span style=
=3D"color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"> a</span=
><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,=
0)"><br></span><span style=3D"color:rgb(102,102,0)">}</span></div></code></=
div><div><br></div><div>When evaluated in constant context, the restriction=
s of constant-expression are automatically imposed, </div></div></blockquot=
e><div></div></div></div><div><br></div><div>This has been suggested before=
..=C2=A0 You are essentially asking that all functions that could be constex=
pr, be implicitly constexpr.=C2=A0 Likewise for the other "contexts&qu=
ot;.</div><div><br></div><div>The problem is compile-time.=C2=A0 Compiling =
a constexpr function (for example) is expensive.=C2=A0 Doing it automatical=
ly for all function definitions would increase compile times too much.</div=
><div><br></div><div>You have to explicitly mark the functions you want to =
use in constexpr contexts, so the compiler knows it doesn't have to do =
the extra analysis for all the other ones.</div></div></blockquote></span><=
div><br>I'm not sure I understand this point.=C2=A0 I am not really awa=
re of exactly how constexpr evaluation is handled in compilers, but I assum=
e it comes down to storing some type of AST when the function is parsed, an=
d then either evaluating directly based on that or possibly converting it t=
o some intermediate representation, which could presumably be done in a JIT=
fashion when actually required.</div></blockquote><div></div></div><br></d=
iv></span><div class=3D"gmail_extra">I just tested it (gcc 5.2) and observe=
d that a 5-line C++14 constexpr function definition takes 5% longer to comp=
ile (~105us) than the same inline function (~100us) (even if it isn't u=
sed).=C2=A0 This is less than I expected, but still quite significant.</div=
><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">It is uncl=
ear to me whether this completely highlights the performance concerns about=
implicit constexpr.=C2=A0 Admittedly I am reporting them second-hand.</div=
></div></blockquote><div><br></div></div></div><div>Out of curiosity, is yo=
ur test function templated or not?</div><div><br></div></div></div></div></=
blockquote><div>not.</div><div><br></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />
--f46d04374a051bdae805215ba25d--
.
Author: TONGARI J <tongari95@gmail.com>
Date: Tue, 6 Oct 2015 07:28:37 -0700 (PDT)
Raw View
------=_Part_5957_1165073260.1444141718076
Content-Type: multipart/alternative;
boundary="----=_Part_5958_448158224.1444141718076"
------=_Part_5958_448158224.1444141718076
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
It's interesting to know that the paper P0069R0[1] claims that they've=20
implemented the "inline-is-generic" idea (or sort of) already, quoting from=
=20
the paper [2.2]:
The C++AMP specification defined a new =E2=80=9Crestrict=E2=80=9D keyword w=
hich restricted=20
> the language features allowed in the code region and also identified the=
=20
> code to compile for the accelerator. However, in hindsight the =E2=80=9Cr=
estrict=E2=80=9D=20
> keyword has several downsides. Composing functions becomes tricky as the=
=20
> =E2=80=9Crestrict=E2=80=9D keyword tends to ripple through the call hiera=
rchy.=20
> Additionally, re-using existing code is nontrivial, even in cases where t=
he=20
> functions are short and available in header files (e.g. std::min). HCC=20
> employs a more sophisticated mechanism so that compiler effort focuses on=
=20
> the parallel loops, and only generates and optimizes accelerator code whe=
re=20
> required. As described in the previous section, HCC provides several=20
> mechanisms for programmers to mark parallel regions - specifically=20
> hc::parallel_for_each and [[hc_grid_launch]]. These markers indicate that=
=20
> the marked functions will execute on the accelerator. Likewise, any=20
> functions called by these marked functions execute on the accelerator. Th=
us=20
> the compiler can identify which functions will execute on the accelerator=
=20
> and, in cases where the functions are defined in header files, *can=20
> automatically generate correct accelerator code without the need for=20
> additional function attributes*.
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0069r0.pdf
--=20
---=20
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 e=
mail 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-proposa=
ls/.
------=_Part_5958_448158224.1444141718076
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It's interesting to know that the paper=C2=A0P0069R0[1=
]=C2=A0claims that they've implemented the "inline-is-generic"=
; idea (or sort of) already, quoting from the paper [2.2]:<div><br></div><d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; bo=
rder-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-st=
yle: solid; padding-left: 1ex;">The C++AMP specification defined a new =E2=
=80=9Crestrict=E2=80=9D keyword which restricted the language features
allowed in the code region and also identified the code to compile for the =
accelerator. However, in
hindsight the =E2=80=9Crestrict=E2=80=9D keyword has several downsides. Com=
posing functions becomes tricky as the
=E2=80=9Crestrict=E2=80=9D keyword tends to ripple through the call hierarc=
hy. Additionally, re-using existing code is nontrivial,
even in cases where the functions are short and available in header files (=
e.g. std::min).
HCC employs a more sophisticated mechanism so that compiler effort focuses =
on the parallel loops, and
only generates and optimizes accelerator code where required. As described =
in the previous section,
HCC provides several mechanisms for programmers to mark parallel regions - =
specifically
hc::parallel_for_each and [[hc_grid_launch]]. These markers indicate that t=
he marked functions will
execute on the accelerator. Likewise, any functions called by these marked =
functions execute on the
accelerator. Thus the compiler can identify which functions will execute on=
the accelerator and, in cases
where the functions are defined in header files, <b>can automatically gener=
ate correct accelerator code
without the need for additional function attributes</b>.</blockquote><div><=
br></div><div>[1]=C2=A0http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2=
015/p0069r0.pdf</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_5958_448158224.1444141718076--
------=_Part_5957_1165073260.1444141718076--
.