Topic: [c++std-ext-16624] virtual constexpr fields
Author: Bjarne Stroustrup <bjarne@stroustrup.com>
Date: Wed, 18 Mar 2015 17:43:16 -0400
Raw View
This is a multi-part message in MIME format.
--------------000707030406010702030508
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
(1) yes it should be immutable
(2) I described something like that in D&E (and maybe even in the ARM)
(3) what's the important use case?
On 3/18/2015 4:57 PM, Ehsan Akhgari wrote:
> On Wed, Mar 18, 2015 at 4:52 PM, Tony Van Eerd=20
> <tvaneerd@blackberry.com <mailto:tvaneerd@blackberry.com>> wrote:
>
> I would say it needs to be constexpr or static =E2=80=93 at least for=
it
> to be stored in the vtable.
>
> (ie assuming the vtable is shared by all instances of the class
> means that the value is shared by all instances of the class)
>
>
> Yes, exactly. Note that from a pragmatic standpoint, it's probably=20
> important for compilers to be able to store the vtable in read-only=20
> memory in order to protect against security attacks attempting to=20
> overwrite vtable entries at runtime.
>
> *From:*Gabriel Dos Reis [mailto:gdr@microsoft.com
> <mailto:gdr@microsoft.com>]
> *Sent:* Wednesday, March 18, 2015 4:42 PM
> *To:* 'std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>'; C++std-ext; ehsan@mozilla.com
> <mailto:ehsan@mozilla.com>
> *Subject:* [c++std-ext-16622] Re: [std-proposals] virtual
> constexpr fields
>
> Does the non-static data member need to be constexpr if it is
> virtual? Why?
>
> -- Gaby
>
> *From:*'Botond Ballo' via ISO C++ Standard - Future Proposals
> [mailto:std-proposals@isocpp.org]
> *Sent:* Wednesday, March 18, 2015 1:26 PM
> *To:* C++std-ext; ehsan@mozilla.com <mailto:ehsan@mozilla.com>;
> std-proposals@isocpp.org <mailto:std-proposals@isocpp.org>
> *Subject:* [std-proposals] virtual constexpr fields
>
> There are cases where you would like to associate constants with a
> given type. Here is how you can currently do it in C++:
>
> struct Merchandise {
> virtual int price() { return 0; }
> };
>
> struct Shoe : Merchandise {
> virtual int price() { return 10;
> }
>
> If you could do it this way instead:
>
> struct Merchandise {
> virtual constexpr int price =3D 0;
> };
>
> struct Shoe : Merchandise {
> virtual constexpr int price =3D 10;
> }
>
> then the compiler could store the constant value directly in the
> vtable. This would eliminate the double indirection involved in
> dereferencing a function vtable entry, the cost of running that
> function at runtime, and the code size of the function in the
> compiled binary.
>
> Virtual fields would be limited to being constexpr, so that the
> value to be placed in the vtable, like other values in the vtable,
> can be determined at compile time.
>
> Has this, or something similar, ever been proposed? Is there any
> interest in it?
>
> -- Botond and Ehsan
>
> --=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 email to std-proposals+unsubscribe@isocpp.org
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
>
>
> --=20
> Ehsan
--=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/.
--------------000707030406010702030508
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
(1) yes it should be immutable<br>
(2) I described something like that in D&E (and maybe even in
the ARM)<br>
(3) what's the important use case?<br>
<br>
<div class=3D"moz-cite-prefix">On 3/18/2015 4:57 PM, Ehsan Akhgari
wrote:<br>
</div>
<blockquote
cite=3D"mid:CANTur_7HiZ2eHTTaSq-4XReOhCx-zHE_SBuXW5Ga3zaBGH85BQ@mail.gmail.=
com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">
<div class=3D"gmail_quote">On Wed, Mar 18, 2015 at 4:52 PM, Tony
Van Eerd <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:tvaneerd@blackberry.com" target=3D"_blank">t=
vaneerd@blackberry.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">
<div link=3D"blue" vlink=3D"purple" lang=3D"EN-US">
<div>
<p class=3D"MsoNormal"><span
style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif&=
quot;;color:#1f497d">I
would say it needs to be constexpr or static =E2=80=
=93 at
least for it to be stored in the vtable.</span></p>
<p class=3D"MsoNormal"><span
style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif&=
quot;;color:#1f497d">(ie
assuming the vtable is shared by all instances of
the class means that the value is shared by all
instances of the class)</span></p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes, exactly.=C2=A0 Note that from a pragmatic standpoint,
it's probably important for compilers to be able to store
the vtable in read-only memory in order to protect against
security attacks attempting to overwrite vtable entries at
runtime.<br>
</div>
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link=3D"blue" vlink=3D"purple" lang=3D"EN-US">
<div>
<p class=3D"MsoNormal"><span
style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif&=
quot;;color:#1f497d"></span></p>
<p class=3D"MsoNormal"><span
style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif&=
quot;;color:#1f497d">=C2=A0</span></p>
<div style=3D"border:none;border-left:solid blue
1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style=3D"border:none;border-top:solid #b5c4df
1.0pt;padding:3.0pt 0in 0in 0in">
<p class=3D"MsoNormal"><b><span
style=3D"font-size:10.0pt;font-family:"Tahoma","sans-serif&q=
uot;">From:</span></b><span
style=3D"font-size:10.0pt;font-family:"Tahoma","sans-serif&q=
uot;">
Gabriel Dos Reis [mailto:<a
moz-do-not-send=3D"true"
href=3D"mailto:gdr@microsoft.com"
target=3D"_blank">gdr@microsoft.com</a>]
<br>
<b>Sent:</b> Wednesday, March 18, 2015 4:42
PM<br>
<b>To:</b> '<a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org"
target=3D"_blank">std-proposals@isocpp.org</a=
>';
C++std-ext; <a moz-do-not-send=3D"true"
href=3D"mailto:ehsan@mozilla.com"
target=3D"_blank">ehsan@mozilla.com</a><br>
<b>Subject:</b> [c++std-ext-16622] Re:
[std-proposals] virtual constexpr fields</span>=
</p>
</div>
</div>
<div>
<div class=3D"h5">
<p class=3D"MsoNormal">=C2=A0</p>
<p class=3D"MsoNormal"><span
style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif&=
quot;;color:#1f497d">Does
the non-static data member need to be
constexpr if it is virtual?=C2=A0 Why?</span></=
p>
<p class=3D"MsoNormal"><span
style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif&=
quot;;color:#1f497d">=C2=A0</span></p>
<p class=3D"MsoNormal"><span
style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif&=
quot;;color:#1f497d">--
Gaby</span></p>
<p class=3D"MsoNormal"><span
style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif&=
quot;;color:#1f497d">=C2=A0</span></p>
<div>
<div style=3D"border:none;border-top:solid
#e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class=3D"MsoNormal"><b><span
style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif&=
quot;">From:</span></b><span
style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif&=
quot;">
'Botond Ballo' via ISO C++ Standard -
Future Proposals [<a
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org"
target=3D"_blank">mailto:std-proposals@is=
ocpp.org</a>]
<br>
<b>Sent:</b> Wednesday, March 18, 2015
1:26 PM<br>
<b>To:</b> C++std-ext; <a
moz-do-not-send=3D"true"
href=3D"mailto:ehsan@mozilla.com"
target=3D"_blank">ehsan@mozilla.com</a>;
<a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org"
target=3D"_blank">
std-proposals@isocpp.org</a><br>
<b>Subject:</b> [std-proposals] virtual
constexpr fields</span></p>
</div>
</div>
<p class=3D"MsoNormal">=C2=A0</p>
<div>
<div>
<p class=3D"MsoNormal"
style=3D"background:white"><span
style=3D"font-size:9.0pt;font-family:"Helvetica","sans-serif=
";color:black">There
are cases where you would like to
associate constants with a given type.
Here is how you can currently do it in
C++:<br>
<br>
struct Merchandise {<br>
=C2=A0=C2=A0=C2=A0 virtual int price() { re=
turn 0; }<br>
};<br>
<br>
struct Shoe : Merchandise {<br>
=C2=A0=C2=A0=C2=A0 virtual int price() { re=
turn 10;<br>
}<br>
<br>
If you could do it this way instead:<br>
<br>
struct Merchandise {<br>
=C2=A0=C2=A0=C2=A0 virtual constexpr int pr=
ice =3D 0;<br>
};<br>
<br>
struct Shoe : Merchandise {<br>
=C2=A0=C2=A0=C2=A0 virtual constexpr int pr=
ice =3D 10;<br>
}<br>
<br>
then the compiler could store the
constant value directly in the vtable.
This would eliminate the double
indirection involved in dereferencing a
function vtable entry, the cost of
running that function at runtime, and
the code size of the function in the
compiled binary.<br>
<br>
Virtual fields would be limited to being
constexpr, so that the value to be
placed in the vtable, like other values
in the vtable, can be determined at
compile time.<br>
<br>
Has this, or something similar, ever
been proposed? Is there any interest in
it?<br>
<br>
-- Botond and Ehsan</span></p>
</div>
<div>
<p class=3D"MsoNormal"
style=3D"background:white"><span
style=3D"font-size:9.0pt;font-family:"Helvetica","sans-serif=
";color:black">=C2=A0</span></p>
</div>
</div>
<p class=3D"MsoNormal">-- <br>
<br>
--- <br>
You received this message because you are
subscribed to the Google Groups "ISO C++
Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop
receiving emails from it, send an email to
<a moz-do-not-send=3D"true"
href=3D"mailto:std-proposals+unsubscribe@isocpp=
..org"
target=3D"_blank">std-proposals+unsubscribe@iso=
cpp.org</a>.<br>
To post to this group, send email to <a
moz-do-not-send=3D"true"
href=3D"mailto:std-proposals@isocpp.org"
target=3D"_blank">std-proposals@isocpp.org</a>.=
<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"
target=3D"_blank">
http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.</p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear=3D"all">
<br>
-- <br>
<div class=3D"gmail_signature">
<div dir=3D"ltr">Ehsan<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>
<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 />
--------------000707030406010702030508--
.
Author: ehsan.akhgari@gmail.com
Date: Wed, 18 Mar 2015 15:21:56 -0700 (PDT)
Raw View
------=_Part_6959_750417252.1426717316509
Content-Type: multipart/alternative;
boundary="----=_Part_6960_91295533.1426717316509"
------=_Part_6960_91295533.1426717316509
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
One use case is for projects that implement things such as custom RTTI. =20
For example, both LLVM and Mozilla have implemented their own custom RTTI=
=20
that basically amounts to calling a virtual function that returns an=20
identifier unique to the type. It would be nice to be able to optimize=20
this (which at least in the Mozilla code base is a pretty common code path)=
=20
by eliminating the need to do a virtual call, and instead be able to=20
extract this information directly from the vtable.
Cheers,
Ehsan
On Wednesday, March 18, 2015 at 5:43:16 PM UTC-4, Bjarne Stroustrup wrote:
>
> (1) yes it should be immutable
> (2) I described something like that in D&E (and maybe even in the ARM)
> (3) what's the important use case?
>
> On 3/18/2015 4:57 PM, Ehsan Akhgari wrote:
> =20
> On Wed, Mar 18, 2015 at 4:52 PM, Tony Van Eerd <tvan...@blackberry.com=
=20
> <javascript:>> wrote:
>
>> I would say it needs to be constexpr or static =E2=80=93 at least for i=
t to be=20
>> stored in the vtable.
>>
>> (ie assuming the vtable is shared by all instances of the class means=20
>> that the value is shared by all instances of the class)
>> =20
>
> Yes, exactly. Note that from a pragmatic standpoint, it's probably=20
> important for compilers to be able to store the vtable in read-only memor=
y=20
> in order to protect against security attacks attempting to overwrite vtab=
le=20
> entries at runtime.
> =20
>
>> =20
>> =20
>> *From:* Gabriel Dos Reis [mailto:g...@microsoft.com <javascript:>]=20
>> *Sent:* Wednesday, March 18, 2015 4:42 PM
>> *To:* 'std-pr...@isocpp.org <javascript:>'; C++std-ext; eh...@mozilla.co=
m=20
>> <javascript:>
>> *Subject:* [c++std-ext-16622] Re: [std-proposals] virtual constexpr=20
>> fields
>> =20
>> =20
>>
>> Does the non-static data member need to be constexpr if it is virtual? =
=20
>> Why?
>>
>> =20
>>
>> -- Gaby
>>
>> =20
>> =20
>> *From:* 'Botond Ballo' via ISO C++ Standard - Future Proposals [
>> mailto:std...@isocpp.org <javascript:>]=20
>> *Sent:* Wednesday, March 18, 2015 1:26 PM
>> *To:* C++std-ext; eh...@mozilla.com <javascript:>; ...@isocpp.org=20
>> <javascript:>
>> *Subject:* [std-proposals] virtual constexpr fields
>> =20
>> =20
>> =20
>> There are cases where you would like to associate constants with a given=
=20
>> type. Here is how you can currently do it in C++:
>>
>> struct Merchandise {
>> virtual int price() { return 0; }
>> };
>>
>> struct Shoe : Merchandise {
>> virtual int price() { return 10;
>> }
>>
>> If you could do it this way instead:
>>
>> struct Merchandise {
>> virtual constexpr int price =3D 0;
>> };
>>
>> struct Shoe : Merchandise {
>> virtual constexpr int price =3D 10;
>> }
>>
>> then the compiler could store the constant value directly in the vtable.=
=20
>> This would eliminate the double indirection involved in dereferencing a=
=20
>> function vtable entry, the cost of running that function at runtime, and=
=20
>> the code size of the function in the compiled binary.
>>
>> Virtual fields would be limited to being constexpr, so that the value to=
=20
>> be placed in the vtable, like other values in the vtable, can be determi=
ned=20
>> at compile time.
>>
>> Has this, or something similar, ever been proposed? Is there any interes=
t=20
>> in it?
>>
>> -- Botond and Ehsan
>> =20
>> =20
>> =20
>> --=20
>>
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>> =20
> =20
>
>
> --=20
> Ehsan
> =20
>
>=20
--=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_6960_91295533.1426717316509
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">One use case is for projects that implement things such as=
custom RTTI. For example, both LLVM and Mozilla have implemented the=
ir own custom RTTI that basically amounts to calling a virtual function tha=
t returns an identifier unique to the type. It would be nice to be ab=
le to optimize this (which at least in the Mozilla code base is a pretty co=
mmon code path) by eliminating the need to do a virtual call, and instead b=
e able to extract this information directly from the vtable.<br><br>Cheers,=
<br>Ehsan<br><br>On Wednesday, March 18, 2015 at 5:43:16 PM UTC-4, Bjarne S=
troustrup wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
(1) yes it should be immutable<br>
(2) I described something like that in D&E (and maybe even in
the ARM)<br>
(3) what's the important use case?<br>
<br>
<div>On 3/18/2015 4:57 PM, Ehsan Akhgari
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<div class=3D"gmail_quote">On Wed, Mar 18, 2015 at 4:52 PM, Tony
Van Eerd <span dir=3D"ltr"><<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"R-f_jCAlqHIJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'jav=
ascript:';return true;">tvan...@blackberry.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 link=3D"blue" vlink=3D"purple" lang=3D"EN-US">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;fo=
nt-family:"Calibri","sans-serif";color:#1f497d">I
would say it needs to be constexpr or static =E2=80=
=93 at
least for it to be stored in the vtable.</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;fo=
nt-family:"Calibri","sans-serif";color:#1f497d">(ie
assuming the vtable is shared by all instances of
the class means that the value is shared by all
instances of the class)</span></p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes, exactly. Note that from a pragmatic standpoint,
it's probably important for compilers to be able to store
the vtable in read-only memory in order to protect against
security attacks attempting to overwrite vtable entries at
runtime.<br>
</div>
<div> </div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
<div link=3D"blue" vlink=3D"purple" lang=3D"EN-US">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;fo=
nt-family:"Calibri","sans-serif";color:#1f497d"></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;fo=
nt-family:"Calibri","sans-serif";color:#1f497d"> <=
/span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;pa=
dding:0in 0in 0in 4.0pt">
<div>
<div style=3D"border:none;border-top:solid #b5c4df 1.=
0pt;padding:3.0pt 0in 0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:=
10.0pt;font-family:"Tahoma","sans-serif"">From:</span><=
/b><span style=3D"font-size:10.0pt;font-family:"Tahoma","san=
s-serif"">
Gabriel Dos Reis [mailto:<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"R-f_jCAlqHIJ" rel=3D"nofollow"=
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;">g...@microsoft.com</a>]
<br>
<b>Sent:</b> Wednesday, March 18, 2015 4:42
PM<br>
<b>To:</b> '<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"R-f_jCAlqHIJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascr=
ipt:';return true;">std-pr...@isocpp.org</a>';
C++std-ext; <a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"R-f_jCAlqHIJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascr=
ipt:';return true;">eh...@mozilla.com</a><br>
<b>Subject:</b> [c++std-ext-16622] Re:
[std-proposals] virtual constexpr fields</span>=
</p>
</div>
</div>
<div>
<div>
<p class=3D"MsoNormal"> </p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.=
0pt;font-family:"Calibri","sans-serif";color:#1f497d">D=
oes
the non-static data member need to be
constexpr if it is virtual? Why?</span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.=
0pt;font-family:"Calibri","sans-serif";color:#1f497d">&=
nbsp;</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.=
0pt;font-family:"Calibri","sans-serif";color:#1f497d">-=
-
Gaby</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.=
0pt;font-family:"Calibri","sans-serif";color:#1f497d">&=
nbsp;</span></p>
<div>
<div style=3D"border:none;border-top:solid #e1e1e=
1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-s=
ize:11.0pt;font-family:"Calibri","sans-serif"">From:</s=
pan></b><span style=3D"font-size:11.0pt;font-family:"Calibri",&qu=
ot;sans-serif"">
'Botond Ballo' via ISO C++ Standard -
Future Proposals [<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"R-f_jCAlqHIJ" rel=3D"nofollow" on=
mousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">mailto:std...@isocpp.<wbr>org</a>]
<br>
<b>Sent:</b> Wednesday, March 18, 2015
1:26 PM<br>
<b>To:</b> C++std-ext; <a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"R-f_jCAlqHIJ" rel=3D"nofollo=
w" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.h=
ref=3D'javascript:';return true;">eh...@mozilla.com</a>;
<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"R-f_jCAlqHIJ" rel=3D"nofollow" onmousedown=3D"this.=
href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';ret=
urn true;">
...@isocpp.org</a><br>
<b>Subject:</b> [std-proposals] virtual
constexpr fields</span></p>
</div>
</div>
<p class=3D"MsoNormal"> </p>
<div>
<div>
<p class=3D"MsoNormal" style=3D"background:whit=
e"><span style=3D"font-size:9.0pt;font-family:"Helvetica","s=
ans-serif";color:black">There
are cases where you would like to
associate constants with a given type.
Here is how you can currently do it in
C++:<br>
<br>
struct Merchandise {<br>
virtual int price() { re=
turn 0; }<br>
};<br>
<br>
struct Shoe : Merchandise {<br>
virtual int price() { re=
turn 10;<br>
}<br>
<br>
If you could do it this way instead:<br>
<br>
struct Merchandise {<br>
virtual constexpr int pr=
ice =3D 0;<br>
};<br>
<br>
struct Shoe : Merchandise {<br>
virtual constexpr int pr=
ice =3D 10;<br>
}<br>
<br>
then the compiler could store the
constant value directly in the vtable.
This would eliminate the double
indirection involved in dereferencing a
function vtable entry, the cost of
running that function at runtime, and
the code size of the function in the
compiled binary.<br>
<br>
Virtual fields would be limited to being
constexpr, so that the value to be
placed in the vtable, like other values
in the vtable, can be determined at
compile time.<br>
<br>
Has this, or something similar, ever
been proposed? Is there any interest in
it?<br>
<br>
-- Botond and Ehsan</span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"background:whit=
e"><span style=3D"font-size:9.0pt;font-family:"Helvetica","s=
ans-serif";color:black"> </span></p>
</div>
</div>
<p class=3D"MsoNormal">-- <br>
<br>
--- <br>
You received this message because you are
subscribed to the Google Groups "ISO C++
Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop
receiving emails from it, send an email to
<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"R-f_jCAlqHIJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return =
true;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"R-f_jCAlqHIJ" rel=3D=
"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.goog=
le.com/a/isocpp.org/group/std-proposals/" target=3D"_blank" rel=3D"nofollow=
" onmousedown=3D"this.href=3D'http://groups.google.com/a/isocpp.org/group/s=
td-proposals/';return true;" onclick=3D"this.href=3D'http://groups.google.c=
om/a/isocpp.org/group/std-proposals/';return true;">
http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposals/</a>.</=
p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear=3D"all">
<br>
-- <br>
<div>
<div dir=3D"ltr">Ehsan<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote></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_6960_91295533.1426717316509--
------=_Part_6959_750417252.1426717316509--
.
Author: Gabriel Dos Reis <gdr@microsoft.com>
Date: Wed, 18 Mar 2015 22:34:25 +0000
Raw View
--_000_DM2PR0301MB09114B16DBAB57778A76589BB0000DM2PR0301MB0911_
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Immutable isn=E2=80=99t the same as =E2=80=98constexpr=E2=80=99 though. Yo=
u want immutable and statically initialized, and not a non-static data memb=
er =E2=80=93 data that are shared across objects are =E2=80=9Cstatic=E2=80=
=9D.
If I understand correctly, that would be the proper use of =E2=80=9Cstatic=
=E2=80=9D: there is only one copy in the program.
-- Gaby
From: ehsan.akhgari@gmail.com [mailto:ehsan.akhgari@gmail.com]
Sent: Wednesday, March 18, 2015 3:22 PM
To: std-proposals@isocpp.org
Cc: c++std-ext@accu.org; tvaneerd@blackberry.com; bjarne@stroustrup.com
Subject: Re: [c++std-ext-16624] Re: [std-proposals] virtual constexpr field=
s
One use case is for projects that implement things such as custom RTTI. Fo=
r example, both LLVM and Mozilla have implemented their own custom RTTI tha=
t basically amounts to calling a virtual function that returns an identifie=
r unique to the type. It would be nice to be able to optimize this (which =
at least in the Mozilla code base is a pretty common code path) by eliminat=
ing the need to do a virtual call, and instead be able to extract this info=
rmation directly from the vtable.
Cheers,
Ehsan
On Wednesday, March 18, 2015 at 5:43:16 PM UTC-4, Bjarne Stroustrup wrote:
(1) yes it should be immutable
(2) I described something like that in D&E (and maybe even in the ARM)
(3) what's the important use case?
On 3/18/2015 4:57 PM, Ehsan Akhgari wrote:
On Wed, Mar 18, 2015 at 4:52 PM, Tony Van Eerd <tvan...@blackberry.com<java=
script:>> wrote:
I would say it needs to be constexpr or static =E2=80=93 at least for it to=
be stored in the vtable.
(ie assuming the vtable is shared by all instances of the class means that =
the value is shared by all instances of the class)
Yes, exactly. Note that from a pragmatic standpoint, it's probably importa=
nt for compilers to be able to store the vtable in read-only memory in orde=
r to protect against security attacks attempting to overwrite vtable entrie=
s at runtime.
From: Gabriel Dos Reis [mailto:g...@microsoft.com<javascript:>]
Sent: Wednesday, March 18, 2015 4:42 PM
To: 'std-pr...@isocpp.org<javascript:>'; C++std-ext; eh...@mozilla.com<java=
script:>
Subject: [c++std-ext-16622] Re: [std-proposals] virtual constexpr fields
Does the non-static data member need to be constexpr if it is virtual? Why=
?
-- Gaby
From: 'Botond Ballo' via ISO C++ Standard - Future Proposals [mailto:std...=
@isocpp.org<javascript:>]
Sent: Wednesday, March 18, 2015 1:26 PM
To: C++std-ext; eh...@mozilla.com<javascript:>; ...@isocpp.org<javascript:>
Subject: [std-proposals] virtual constexpr fields
There are cases where you would like to associate constants with a given ty=
pe. Here is how you can currently do it in C++:
struct Merchandise {
virtual int price() { return 0; }
};
struct Shoe : Merchandise {
virtual int price() { return 10;
}
If you could do it this way instead:
struct Merchandise {
virtual constexpr int price =3D 0;
};
struct Shoe : Merchandise {
virtual constexpr int price =3D 10;
}
then the compiler could store the constant value directly in the vtable. Th=
is would eliminate the double indirection involved in dereferencing a funct=
ion vtable entry, the cost of running that function at runtime, and the cod=
e size of the function in the compiled binary.
Virtual fields would be limited to being constexpr, so that the value to be=
placed in the vtable, like other values in the vtable, can be determined a=
t compile time.
Has this, or something similar, ever been proposed? Is there any interest i=
n it?
-- Botond and Ehsan
--
---
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-proposal...@isocpp.org<javascript:>.
To post to this group, send email to std-pr...@isocpp.org<javascript:>.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--
Ehsan
--
---
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<mailto:std-proposals+unsubscri=
be@isocpp.org>.
To post to this group, send email to std-proposals@isocpp.org<mailto:std-pr=
oposals@isocpp.org>.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--=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/.
--_000_DM2PR0301MB09114B16DBAB57778A76589BB0000DM2PR0301MB0911_
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Calisto MT";
panose-1:2 4 6 3 5 5 5 3 3 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calisto MT",serif;
color:#7030A0;}
..MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-family:"Calisto MT",se=
rif;color:#7030A0">Immutable isn=E2=80=99t the same as =E2=80=98constexpr=
=E2=80=99 though. You want immutable and statically initialized, and =
not a non-static data member =E2=80=93 data that are shared across objects =
are =E2=80=9Cstatic=E2=80=9D.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:"Calisto MT",se=
rif;color:#7030A0">If I understand correctly, that would be the proper use =
of =E2=80=9Cstatic=E2=80=9D: there is only one copy in the program.<o:p></o=
:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:"Calisto MT",se=
rif;color:#7030A0"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-family:"Calisto MT",se=
rif;color:#7030A0">-- Gaby<o:p></o:p></span></p>
<p class=3D"MsoNormal"><a name=3D"_MailEndCompose"><span style=3D"font-fami=
ly:"Calisto MT",serif;color:#7030A0"><o:p> </o:p></span></a>=
</p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:"=
;Calibri",sans-serif">From:</span></b><span style=3D"font-size:11.0pt;=
font-family:"Calibri",sans-serif"> ehsan.akhgari@gmail.com [mailt=
o:ehsan.akhgari@gmail.com]
<br>
<b>Sent:</b> Wednesday, March 18, 2015 3:22 PM<br>
<b>To:</b> std-proposals@isocpp.org<br>
<b>Cc:</b> c++std-ext@accu.org; tvaneerd@blackberry.com; bjarne@str=
oustrup.com<br>
<b>Subject:</b> Re: [c++std-ext-16624] Re: [std-proposals] virtual =
constexpr fields<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<div>
<p class=3D"MsoNormal">One use case is for projects that implement things s=
uch as custom RTTI. For example, both LLVM and Mozilla have implement=
ed their own custom RTTI that basically amounts to calling a virtual functi=
on that returns an identifier unique to
the type. It would be nice to be able to optimize this (which at lea=
st in the Mozilla code base is a pretty common code path) by eliminating th=
e need to do a virtual call, and instead be able to extract this informatio=
n directly from the vtable.<br>
<br>
Cheers,<br>
Ehsan<br>
<br>
On Wednesday, March 18, 2015 at 5:43:16 PM UTC-4, Bjarne Stroustrup wrote:<=
o:p></o:p></p>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i=
n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">(1) yes it should be =
immutable<br>
(2) I described something like that in D&E (and maybe even in the ARM)<=
br>
(3) what's the important use case?<o:p></o:p></p>
<div>
<p class=3D"MsoNormal">On 3/18/2015 4:57 PM, Ehsan Akhgari wrote:<o:p></o:p=
></p>
</div>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class=3D"MsoNormal">On Wed, Mar 18, 2015 at 4:52 PM, Tony Van Eerd <<=
a href=3D"javascript:" target=3D"_blank">tvan...@blackberry.com</a>> wro=
te:<o:p></o:p></p>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i=
n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:11.0pt;font-family:"Calibri",sa=
ns-serif;color:#1F497D">I would say it needs to be constexpr or static =E2=
=80=93 at least for it to be stored in the vtable.</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:11.0pt;font-family:"Calibri",sa=
ns-serif;color:#1F497D">(ie assuming the vtable is shared by all instances =
of the class means that the value is shared by all
instances of the class)</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Yes, exactly. Note that from a pragmatic stand=
point, it's probably important for compilers to be able to store the vtable=
in read-only memory in order to protect against security attacks attemptin=
g to overwrite vtable entries at runtime.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0i=
n 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:11.0pt;font-family:"Calibri",sa=
ns-serif;color:#1F497D"> </span><o:p></o:p></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><b><span style=3D"font-size:10.0pt;font-family:"Tahoma",=
sans-serif">From:</span></b><span style=3D"font-size:10.0pt;font-family:&qu=
ot;Tahoma",sans-serif"> Gabriel Dos Reis [mailto:<a href=3D"javascript=
:" target=3D"_blank">g...@microsoft.com</a>]
<br>
<b>Sent:</b> Wednesday, March 18, 2015 4:42 PM<br>
<b>To:</b> '<a href=3D"javascript:" target=3D"_blank">std-pr...@isocpp.org<=
/a>'; C++std-ext;
<a href=3D"javascript:" target=3D"_blank">eh...@mozilla.com</a><br>
<b>Subject:</b> [c++std-ext-16622] Re: [std-proposals] virtual cons=
texpr fields</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"> <o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:11.0pt;font-family:"Calibri",sa=
ns-serif;color:#1F497D">Does the non-static data member need to be constexp=
r if it is virtual? Why?</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:11.0pt;font-family:"Calibri",sa=
ns-serif;color:#1F497D"> </span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:11.0pt;font-family:"Calibri",sa=
ns-serif;color:#1F497D">-- Gaby</span><o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span style=3D"font-size:11.0pt;font-family:"Calibri",sa=
ns-serif;color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><b><span style=3D"font-size:11.0pt;font-family:"Calibri"=
,sans-serif">From:</span></b><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri",sans-serif"> 'Botond Ballo' via ISO C++ Standard
- Future Proposals [<a href=3D"javascript:" target=3D"_blank">mailto:std..=
..@isocpp.org</a>]
<br>
<b>Sent:</b> Wednesday, March 18, 2015 1:26 PM<br>
<b>To:</b> C++std-ext; <a href=3D"javascript:" target=3D"_blank">eh=
....@mozilla.com</a>;
<a href=3D"javascript:" target=3D"_blank">...@isocpp.org</a><br>
<b>Subject:</b> [std-proposals] virtual constexpr fields</span><o:p></o:p><=
/p>
</div>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"> <o:p></o:p></p>
<div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;background:white">
<span style=3D"font-size:9.0pt;font-family:"Helvetica",sans-serif=
;color:black">There are cases where you would like to associate constants w=
ith a given type. Here is how you can currently do it in C++:<br>
<br>
struct Merchandise {<br>
virtual int price() { return 0; }<br>
};<br>
<br>
struct Shoe : Merchandise {<br>
virtual int price() { return 10;<br>
}<br>
<br>
If you could do it this way instead:<br>
<br>
struct Merchandise {<br>
virtual constexpr int price =3D 0;<br>
};<br>
<br>
struct Shoe : Merchandise {<br>
virtual constexpr int price =3D 10;<br>
}<br>
<br>
then the compiler could store the constant value directly in the vtable. Th=
is would eliminate the double indirection involved in dereferencing a funct=
ion vtable entry, the cost of running that function at runtime, and the cod=
e size of the function in the compiled
binary.<br>
<br>
Virtual fields would be limited to being constexpr, so that the value to be=
placed in the vtable, like other values in the vtable, can be determined a=
t compile time.<br>
<br>
Has this, or something similar, ever been proposed? Is there any interest i=
n it?<br>
<br>
-- Botond and Ehsan</span><o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto;background:white">
<span style=3D"font-size:9.0pt;font-family:"Helvetica",sans-serif=
;color:black"> </span><o:p></o:p></p>
</div>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto">--
<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"javascript:" target=3D"_blank">std-proposal...@isocpp.org</a>.<b=
r>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">
http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<o:p></o:p><=
/p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class=3D"MsoNormal"><br>
<br clear=3D"all">
<br>
-- <o:p></o:p></p>
<div>
<div>
<p class=3D"MsoNormal">Ehsan<o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<p class=3D"MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
</div>
<p class=3D"MsoNormal">-- <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-proposals&#=
43;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>.<o:p></o:p><=
/p>
</div>
</div>
</body>
</html>
<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 />
--_000_DM2PR0301MB09114B16DBAB57778A76589BB0000DM2PR0301MB0911_--
.
Author: alan.dayton.1@gmail.com
Date: Wed, 17 May 2017 16:48:24 -0700 (PDT)
Raw View
------=_Part_104_1798946218.1495064904621
Content-Type: multipart/alternative;
boundary="----=_Part_105_1504635375.1495064904622"
------=_Part_105_1504635375.1495064904622
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I know this is an old thread, but I've got one use case. I've got a=20
hierarchy of classes that makes use of several small arrays in a member=20
function. Each class has its own set of sizes for the arrays, but the=20
method is still the same regardless of the size of the arrays. I know using=
=20
templates would be one solution, but the template parameters are not known=
=20
until run time, and it's annoying to change function signatures to accept=
=20
templated objects. I'm also working with CUDA and I want to avoid=20
dynamically allocating memory for small arrays.
class Parent
{
public:
__host__ __device__ void CalculateSomething(someParams)
{
std::size_t s =3D GetArraySize();
double array1[s];
double array2[s+1];
double array3[OtherConstexprFunction(s)];
// do stuff with arrays
}
protected:
__host__ __device__ virtual constexpr std::size_t GetArraySize() =3D 0;
};=20
class Child1
{
protected:
__host__ __device__ virtual constexpr std::size_t GetArraySize() {=20
return 1; }
};
class Child2
{
protected:
__host__ __device__ virtual constexpr std::size_t GetArraySize() {=20
return 2; }
};
Here's the template version:
class C
public:
template<std::size_t N>
__host__ __device__ void CalculateSomething(someParams)
{
double array1[N];
double array2[N+1]; // I don't think this or the next line will=20
compile even if they could be constexpr functions because the template=20
parameter is not known until runtime
double array3[OtherFunction(N)];
// do stuff with arrays
}
};
I'm sure I could also do some unclear tricks with macros, but that also=20
seems like a hassle. If you know of a better solution, let me know. But it=
=20
seems like this could be a good use case for constexpr members.
- Alan=20
On Wednesday, March 18, 2015 at 2:43:16 PM UTC-7, Bjarne Stroustrup wrote:
>
> (1) yes it should be immutable
> (2) I described something like that in D&E (and maybe even in the ARM)
> (3) what's the important use case?
>
> On 3/18/2015 4:57 PM, Ehsan Akhgari wrote:
>
> On Wed, Mar 18, 2015 at 4:52 PM, Tony Van Eerd <tvan...@blackberry.com=20
> <javascript:>> wrote:
>
>> I would say it needs to be constexpr or static =E2=80=93 at least for it=
to be=20
>> stored in the vtable.
>>
>> (ie assuming the vtable is shared by all instances of the class means=20
>> that the value is shared by all instances of the class)
>>
>
> Yes, exactly. Note that from a pragmatic standpoint, it's probably=20
> important for compilers to be able to store the vtable in read-only memor=
y=20
> in order to protect against security attacks attempting to overwrite vtab=
le=20
> entries at runtime.
> =20
>
>> =20
>>
>> *From:* Gabriel Dos Reis [mailto:g...@microsoft.com <javascript:>]=20
>> *Sent:* Wednesday, March 18, 2015 4:42 PM
>> *To:* 'std-pr...@isocpp.org <javascript:>'; C++std-ext; eh...@mozilla.co=
m=20
>> <javascript:>
>> *Subject:* [c++std-ext-16622] Re: [std-proposals] virtual constexpr=20
>> fields
>>
>> =20
>>
>> Does the non-static data member need to be constexpr if it is virtual? =
=20
>> Why?
>>
>> =20
>>
>> -- Gaby
>>
>> =20
>>
>> *From:* 'Botond Ballo' via ISO C++ Standard - Future Proposals [
>> mailto:std...@isocpp.org <javascript:>]=20
>> *Sent:* Wednesday, March 18, 2015 1:26 PM
>> *To:* C++std-ext; eh...@mozilla.com <javascript:>; ...@isocpp.org=20
>> <javascript:>
>> *Subject:* [std-proposals] virtual constexpr fields
>>
>> =20
>>
>> There are cases where you would like to associate constants with a given=
=20
>> type. Here is how you can currently do it in C++:
>>
>> struct Merchandise {
>> virtual int price() { return 0; }
>> };
>>
>> struct Shoe : Merchandise {
>> virtual int price() { return 10;
>> }
>>
>> If you could do it this way instead:
>>
>> struct Merchandise {
>> virtual constexpr int price =3D 0;
>> };
>>
>> struct Shoe : Merchandise {
>> virtual constexpr int price =3D 10;
>> }
>>
>> then the compiler could store the constant value directly in the vtable.=
=20
>> This would eliminate the double indirection involved in dereferencing a=
=20
>> function vtable entry, the cost of running that function at runtime, and=
=20
>> the code size of the function in the compiled binary.
>>
>> Virtual fields would be limited to being constexpr, so that the value to=
=20
>> be placed in the vtable, like other values in the vtable, can be determi=
ned=20
>> at compile time.
>>
>> Has this, or something similar, ever been proposed? Is there any interes=
t=20
>> in it?
>>
>> -- Botond and Ehsan
>>
>> =20
>>
>> --=20
>>
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
>
> --=20
> Ehsan
>
>
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20e0ddef-2b8d-4133-b684-f4ca31f5425f%40isocpp.or=
g.
------=_Part_105_1504635375.1495064904622
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I know this is an old thread, but I've got one use cas=
e. I've got a hierarchy of classes that makes use of several small arra=
ys in a member function. Each class has its own set of sizes for the arrays=
, but the method is still the same regardless of the size of the arrays. I =
know using templates would be one solution, but the template parameters are=
not known until run time, and it's annoying to change function signatu=
res to accept templated objects. I'm also working with CUDA and I want =
to avoid dynamically allocating memory for small arrays.<br><br>class Paren=
t<br>{<br>public:<br>=C2=A0=C2=A0=C2=A0=C2=A0 __host__ __device__ void Calc=
ulateSomething(someParams)<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 std::size_t s =3D GetArraySize();<br>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 double array1[s];<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 double array2[s+1];<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 double array3[OtherConstexprFunction(s)];<br><br>=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 // do stuff with arrays<br>=C2=A0=C2=A0=C2=A0 }=
<br><br>protected:<br>=C2=A0=C2=A0=C2=A0 __host__ __device__ virtual conste=
xpr std::size_t GetArraySize() =3D 0;<br>}; <br><br>class Child1<br>{<br>pr=
otected:<br>=C2=A0=C2=A0=C2=A0 __host__ __device__ virtual constexpr std::s=
ize_t GetArraySize() { return 1; }<br>};<br><br>class Child2<br>{<br>protec=
ted:<br>=C2=A0=C2=A0=C2=A0 __host__ __device__ virtual constexpr std::size_=
t GetArraySize() { return 2; }<br>};<br><br>Here's the template version=
:<br>class C<br>public:<br>=C2=A0=C2=A0=C2=A0 template<std::size_t N>=
<br>=C2=A0=C2=A0=C2=A0=C2=A0 __host__ __device__ void CalculateSomething(so=
meParams)<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 double array1[N];<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 doub=
le array2[N+1]; // I don't think this or the next line will compile eve=
n if they could be constexpr functions because the template parameter is no=
t known until runtime<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 double =
array3[OtherFunction(N)];<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
// do stuff with arrays<br>=C2=A0=C2=A0=C2=A0 }<br>};<br><br>I'm sure =
I could also do some unclear tricks with macros, but that also seems like a=
hassle. If you know of a better solution, let me know. But it seems like t=
his could be a good use case for constexpr members.<br><br>- Alan <br><br>O=
n Wednesday, March 18, 2015 at 2:43:16 PM UTC-7, Bjarne Stroustrup wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
(1) yes it should be immutable<br>
(2) I described something like that in D&E (and maybe even in
the ARM)<br>
(3) what's the important use case?<br>
<br>
<div>On 3/18/2015 4:57 PM, Ehsan Akhgari
wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<div class=3D"gmail_quote">On Wed, Mar 18, 2015 at 4:52 PM, Tony
Van Eerd <span dir=3D"ltr"><<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"R-f_jCAlqHIJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;">tvan...@blackberry.com</a>></spa=
n>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
<div link=3D"blue" vlink=3D"purple" lang=3D"EN-US">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;fo=
nt-family:"Calibri","sans-serif";color:#1f497d">I
would say it needs to be constexpr or static =E2=80=
=93 at
least for it to be stored in the vtable.</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;fo=
nt-family:"Calibri","sans-serif";color:#1f497d">(ie
assuming the vtable is shared by all instances of
the class means that the value is shared by all
instances of the class)</span></p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes, exactly.=C2=A0 Note that from a pragmatic standpoint,
it's probably important for compilers to be able to store
the vtable in read-only memory in order to protect against
security attacks attempting to overwrite vtable entries at
runtime.<br>
</div>
<div>=C2=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
<div link=3D"blue" vlink=3D"purple" lang=3D"EN-US">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;fo=
nt-family:"Calibri","sans-serif";color:#1f497d"></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;fo=
nt-family:"Calibri","sans-serif";color:#1f497d">=C2=A0<=
/span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;pa=
dding:0in 0in 0in 4.0pt">
<div>
<div style=3D"border:none;border-top:solid #b5c4df 1.=
0pt;padding:3.0pt 0in 0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:=
10.0pt;font-family:"Tahoma","sans-serif"">From:</span><=
/b><span style=3D"font-size:10.0pt;font-family:"Tahoma","san=
s-serif"">
Gabriel Dos Reis [mailto:<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"R-f_jCAlqHIJ" rel=3D"nofollow"=
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"=
this.href=3D'javascript:';return true;">g...@microsoft.com</a>]
<br>
<b>Sent:</b> Wednesday, March 18, 2015 4:42
PM<br>
<b>To:</b> '<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"R-f_jCAlqHIJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;">std-pr...@isocpp.org</a>';
C++std-ext; <a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"R-f_jCAlqHIJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">eh...@mozilla.com</a><br>
<b>Subject:</b> [c++std-ext-16622] Re:
[std-proposals] virtual constexpr fields</span>=
</p>
</div>
</div>
<div>
<div>
<p class=3D"MsoNormal">=C2=A0</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.=
0pt;font-family:"Calibri","sans-serif";color:#1f497d">D=
oes
the non-static data member need to be
constexpr if it is virtual?=C2=A0 Why?</span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.=
0pt;font-family:"Calibri","sans-serif";color:#1f497d">=
=C2=A0</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.=
0pt;font-family:"Calibri","sans-serif";color:#1f497d">-=
-
Gaby</span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.=
0pt;font-family:"Calibri","sans-serif";color:#1f497d">=
=C2=A0</span></p>
<div>
<div style=3D"border:none;border-top:solid #e1e1e=
1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-s=
ize:11.0pt;font-family:"Calibri","sans-serif"">From:</s=
pan></b><span style=3D"font-size:11.0pt;font-family:"Calibri",&qu=
ot;sans-serif"">
'Botond Ballo' via ISO C++ Standard=
-
Future Proposals [<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"R-f_jCAlqHIJ" rel=3D"nofollow" on=
mousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"thi=
s.href=3D'javascript:';return true;">mailto:std...@isocpp.<wbr>org<=
/a>]
<br>
<b>Sent:</b> Wednesday, March 18, 2015
1:26 PM<br>
<b>To:</b> C++std-ext; <a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"R-f_jCAlqHIJ" rel=3D"nofollo=
w" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">eh...@mozilla.com</a>;
<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"R-f_jCAlqHIJ" rel=3D"nofollow" onmousedown=3D"this.=
href=3D'javascript:';return true;" onclick=3D"this.href=3D'java=
script:';return true;">
...@isocpp.org</a><br>
<b>Subject:</b> [std-proposals] virtual
constexpr fields</span></p>
</div>
</div>
<p class=3D"MsoNormal">=C2=A0</p>
<div>
<div>
<p class=3D"MsoNormal" style=3D"background:whit=
e"><span style=3D"font-size:9.0pt;font-family:"Helvetica","s=
ans-serif";color:black">There
are cases where you would like to
associate constants with a given type.
Here is how you can currently do it in
C++:<br>
<br>
struct Merchandise {<br>
=C2=A0=C2=A0=C2=A0 virtual int price() { re=
turn 0; }<br>
};<br>
<br>
struct Shoe : Merchandise {<br>
=C2=A0=C2=A0=C2=A0 virtual int price() { re=
turn 10;<br>
}<br>
<br>
If you could do it this way instead:<br>
<br>
struct Merchandise {<br>
=C2=A0=C2=A0=C2=A0 virtual constexpr int pr=
ice =3D 0;<br>
};<br>
<br>
struct Shoe : Merchandise {<br>
=C2=A0=C2=A0=C2=A0 virtual constexpr int pr=
ice =3D 10;<br>
}<br>
<br>
then the compiler could store the
constant value directly in the vtable.
This would eliminate the double
indirection involved in dereferencing a
function vtable entry, the cost of
running that function at runtime, and
the code size of the function in the
compiled binary.<br>
<br>
Virtual fields would be limited to being
constexpr, so that the value to be
placed in the vtable, like other values
in the vtable, can be determined at
compile time.<br>
<br>
Has this, or something similar, ever
been proposed? Is there any interest in
it?<br>
<br>
-- Botond and Ehsan</span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"background:whit=
e"><span style=3D"font-size:9.0pt;font-family:"Helvetica","s=
ans-serif";color:black">=C2=A0</span></p>
</div>
</div>
<p class=3D"MsoNormal">-- <br>
<br>
--- <br>
You received this message because you are
subscribed to the Google Groups "ISO C++
Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop
receiving emails from it, send an email to
<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"R-f_jCAlqHIJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascri=
pt:';return true;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"R-f_jCAlqHIJ" rel=3D=
"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;" o=
nclick=3D"this.href=3D'javascript:';return true;">std-pr...@isocpp.=
org</a>.<br>
Visit this group at <a href=3D"http://groups.goog=
le.com/a/isocpp.org/group/std-proposals/" target=3D"_blank" rel=3D"nofollow=
" onmousedown=3D"this.href=3D'http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/';return true;" onclick=3D"this.href=3D'http://gro=
ups.google.com/a/isocpp.org/group/std-proposals/';return true;">
http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposals/</a>.</=
p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear=3D"all">
<br>
-- <br>
<div>
<div dir=3D"ltr">Ehsan<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20e0ddef-2b8d-4133-b684-f4ca31f5425f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/20e0ddef-2b8d-4133-b684-f4ca31f5425f=
%40isocpp.org</a>.<br />
------=_Part_105_1504635375.1495064904622--
------=_Part_104_1798946218.1495064904621--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 17 May 2017 20:19:57 -0700
Raw View
On Wednesday, 17 May 2017 16:48:24 PDT alan.dayton.1@gmail.com wrote:
> double array2[N+1]; // I don't think this or the next line will
> compile even if they could be constexpr functions because the template
> parameter is not known until runtime
Template parameters are ALWAYS known at compile time.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6861789.T8v47eDZmk%40tjmaciei-mobl1.
.
Author: p_hampson@wargaming.net
Date: Thu, 18 May 2017 17:29:57 -0700 (PDT)
Raw View
------=_Part_901_87484277.1495153797659
Content-Type: multipart/alternative;
boundary="----=_Part_902_1322214111.1495153797660"
------=_Part_902_1322214111.1495153797660
Content-Type: text/plain; charset="UTF-8"
On Thursday, May 18, 2017 at 9:48:24 AM UTC+10, alan.d...@gmail.com wrote:
>
> I know this is an old thread, but I've got one use case.
>
Since this thread's come alive, this would possibly also resolve the
initial motivating use-case for p0130r0 <http://wg21.link/P0130>: Comparing
Virtual Methods, effectively bringing the 'fast' example into the virtual
interfaces system.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e5b2efda-d83b-4a70-97b5-a0acec65b8e9%40isocpp.org.
------=_Part_902_1322214111.1495153797660
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Thursday, May 18, 2017 at 9:48:24 AM UTC+10, alan.d=
....@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">I know this is an old thread, but I've got one use case.=C2=A0=
</div></blockquote><div><br></div><div>Since this thread's come alive, =
this would possibly also resolve the initial motivating use-case for=C2=A0<=
a href=3D"http://wg21.link/P0130">p0130r0</a>:=C2=A0Comparing Virtual Metho=
ds, effectively bringing the 'fast' example into the virtual interf=
aces system.</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e5b2efda-d83b-4a70-97b5-a0acec65b8e9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e5b2efda-d83b-4a70-97b5-a0acec65b8e9=
%40isocpp.org</a>.<br />
------=_Part_902_1322214111.1495153797660--
------=_Part_901_87484277.1495153797659--
.
Author: alan.dayton.1@gmail.com
Date: Fri, 19 May 2017 11:15:33 -0700 (PDT)
Raw View
------=_Part_1418_1228156013.1495217733303
Content-Type: text/plain; charset="UTF-8"
Thiago, what I meant to say is that I am accepting command line input from a user and I can't use that to instantiate a template.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ca3c9dc4-c42d-4491-95c4-9b473fae1e83%40isocpp.org.
------=_Part_1418_1228156013.1495217733303--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 19 May 2017 13:27:35 -0700
Raw View
On sexta-feira, 19 de maio de 2017 11:15:33 PDT alan.dayton.1@gmail.com wrote:
> Thiago, what I meant to say is that I am accepting command line input from a
> user and I can't use that to instantiate a template.
Then it's not obvious what you're trying to do.
Please send an example that doesn't require C++ extensions that others may not
be familiar with.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5623780.koTcu0QvCF%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 19 May 2017 13:52:30 -0700 (PDT)
Raw View
------=_Part_1376_80279582.1495227150781
Content-Type: multipart/alternative;
boundary="----=_Part_1377_420339461.1495227150781"
------=_Part_1377_420339461.1495227150781
Content-Type: text/plain; charset="UTF-8"
On Friday, May 19, 2017 at 2:15:33 PM UTC-4, alan.d...@gmail.com wrote:
>
> Thiago, what I meant to say is that I am accepting command line input from
> a user and I can't use that to instantiate a template.
.... that's not possible. That's not *going to be* possible.
Command line input, *by definition* happens at runtime. Template
instantiate happens at compile time. You cannot use a runtime value to do
compile-time things. You're trying to use the wrong tool for the job.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bbea2b2e-d674-442f-9f3a-7025cc33760a%40isocpp.org.
------=_Part_1377_420339461.1495227150781
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, May 19, 2017 at 2:15:33 PM UTC-4, alan.d...@gma=
il.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Thiago, what I me=
ant to say is that I am accepting command line input from a user and I can&=
#39;t use that to instantiate a template.</blockquote><div><br>... that'=
;s not possible. That's not <i>going to be</i> possible.<br><br>Command=
line input, <i>by definition</i> happens at runtime. Template instantiate =
happens at compile time. You cannot use a runtime value to do compile-time =
things. You're trying to use the wrong tool for the job.<br></div></div=
>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bbea2b2e-d674-442f-9f3a-7025cc33760a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bbea2b2e-d674-442f-9f3a-7025cc33760a=
%40isocpp.org</a>.<br />
------=_Part_1377_420339461.1495227150781--
------=_Part_1376_80279582.1495227150781--
.
Author: Paul Hampson <paul.hampson@pobox.com>
Date: Sat, 20 May 2017 01:44:27 -0700 (PDT)
Raw View
------=_Part_1673_73765455.1495269867111
Content-Type: multipart/alternative;
boundary="----=_Part_1674_800500113.1495269867111"
------=_Part_1674_800500113.1495269867111
Content-Type: text/plain; charset="UTF-8"
On Saturday, 20 May 2017 04:15:33 UTC+10, alan.d...@gmail.com wrote:
>
> Thiago, what I meant to say is that I am accepting command line input from
> a user and I can't use that to instantiate a template.
If I'm reading your code example correctly, what you're trying to do is
have the method defined in the parent class be compiled differently
(different sized local arrays) depending on which derived class it's being
called via. The user input selects the derived class, it doesn't specify
the array-size *directly*.
Since the 'do stuff with arrays' doesn't change based on array size, I
think what you actually want is the code that creates those arrays on the
stack to be in an overriding virtual method in each derived class
(pure-virtual in the base class), which can call common 'do stuff with
arrays' with decayed pointers to the arrays, and possibly the size if
needed.
Your compiler might even be able to do nice things with devirtualisation
and inlining there, if you're lucky, which'd produce basically exactly the
code you're trying to get here already.
Then you don't need the extension here, because the overriding method would
either have the size inline or it'd be a static constexpr class member for
the derived class.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/98b07c7a-b826-4ec2-963a-351ad6af9f42%40isocpp.org.
------=_Part_1674_800500113.1495269867111
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, 20 May 2017 04:15:33 UTC+10, alan.d...@gmail.=
com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Thiago, what I mean=
t to say is that I am accepting command line input from a user and I can=
9;t use that to instantiate a template.</blockquote><div><br></div><div>If =
I'm reading your code example correctly, what you're trying to do i=
s have the method defined in the parent class be compiled differently (diff=
erent sized local arrays) depending on which derived class it's being c=
alled via. The user input selects the derived class, it doesn't specify=
the array-size *directly*.</div><div><br></div><div>Since the 'do stuf=
f with arrays' doesn't change based on array size, I think what you=
actually want is the code that creates those arrays on the stack to be in =
an overriding virtual method in each derived class (pure-virtual in the bas=
e class), which can call common 'do stuff with arrays' with decayed=
pointers to the arrays, and possibly the size if needed.</div><div><br></d=
iv><div>Your compiler might even be able to do nice things with devirtualis=
ation and inlining there, if you're lucky, which'd produce basicall=
y exactly the code you're trying to get here already.</div><div><br></d=
iv><div>Then you don't need the extension here, because the overriding =
method would either have the size inline or it'd be a static constexpr =
class member for the derived class.</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/98b07c7a-b826-4ec2-963a-351ad6af9f42%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/98b07c7a-b826-4ec2-963a-351ad6af9f42=
%40isocpp.org</a>.<br />
------=_Part_1674_800500113.1495269867111--
------=_Part_1673_73765455.1495269867111--
.
Author: alan.dayton.1@gmail.com
Date: Tue, 23 May 2017 17:18:01 -0700 (PDT)
Raw View
------=_Part_3790_382236226.1495585081400
Content-Type: text/plain; charset="UTF-8"
Paul, that is a great solution! I agree now that virtual constexpr members are not needed. I was able to use templates to solve the problem as well, though I like your solution better.
class MyClass
{
public:
void Calculate(std::size_t orderOfMethod, otherParams)
{
switch(orderOfMethod)
{
case 0:
Calculate<0>(otherParams);
break;
case 1:
Calculate<1>(otherParams);
break;
...
}
template<std::size_t N>
void Calculate(otherParams)
{
double array1[N+1];
double array2[someConstexprFunction(N)];
//do stuff with arrays
}
};
This is not unreasonable because there are currently only 6 cases and it is unlikely that any others will be added.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c8d487a7-be02-4b02-a3e7-eae6c14db164%40isocpp.org.
------=_Part_3790_382236226.1495585081400--
.