Topic: virtual constexpr fields
Author: "'Botond Ballo' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Wed, 18 Mar 2015 20:25:47 +0000 (UTC)
Raw View
------=_Part_19320_2067555856.1426710347368
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 {
=C2=A0=C2=A0=C2=A0 virtual int price() { return 0; }
};
struct Shoe : Merchandise {
=C2=A0=C2=A0=C2=A0 virtual int price() { return 10;
}
If you could do it this way instead:
struct Merchandise {
=C2=A0=C2=A0=C2=A0 virtual constexpr int price =3D 0;
};
struct Shoe : Merchandise {
=C2=A0=C2=A0=C2=A0 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
--=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_19320_2067555856.1426710347368
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><body><div style=3D"color:#000; background-color:#fff; font-family:He=
lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;fo=
nt-size:12px"><div dir=3D"ltr" id=3D"yui_3_16_0_1_1426691947599_108603">The=
re are cases where you would like to associate constants with a given type.=
Here is how you can currently do it in C++:<br style=3D"" class=3D""><br s=
tyle=3D"" class=3D"">struct Merchandise {<br style=3D"" class=3D""> &n=
bsp; virtual int price() { return 0; }<br style=3D"" class=3D"">};<br=
style=3D"" class=3D""><br style=3D"" class=3D"">struct Shoe : Merchandise =
{<br style=3D"" class=3D""> virtual int price() { return =
10;<br style=3D"" class=3D"">}<br style=3D"" class=3D""><br style=3D"" clas=
s=3D"">If you could do it this way instead:<br style=3D"" class=3D""><br st=
yle=3D"" class=3D"">struct Merchandise {<br style=3D"" class=3D""> &nb=
sp; virtual constexpr int price =3D 0;<br style=3D"" class=3D"">};<br=
style=3D"" class=3D""><br style=3D"" class=3D"">struct Shoe : Merchandise =
{<br style=3D"" class=3D""> virtual constexpr int price =
=3D 10;<br style=3D"" class=3D"">}<br style=3D"" class=3D""><br style=3D"" =
class=3D"">then the compiler could store the constant value directly in the=
vtable. This would eliminate the double indirection involved in dereferenc=
ing a function vtable entry, the cost of running that function at runtime, =
and the code size of the function in the compiled binary.<br style=3D"" cla=
ss=3D""><br style=3D"" class=3D"">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 style=3D"" class=3D"">=
<br style=3D"" class=3D"">Has this, or something similar, ever been propose=
d? Is there any interest in it?<br style=3D"" class=3D""><br style=3D"" cla=
ss=3D"">-- Botond and Ehsan<br></div><div style=3D"" class=3D"" dir=3D"ltr"=
id=3D"yui_3_16_0_1_1426691947599_108603"><br style=3D"" class=3D""></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 />
------=_Part_19320_2067555856.1426710347368--
.
Author: Gabriel Dos Reis <gdr@microsoft.com>
Date: Wed, 18 Mar 2015 20:41:50 +0000
Raw View
--_000_DM2PR0301MB0911105FCB640A60230A94E2B0000DM2PR0301MB0911_
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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-pr=
oposals@isocpp.org]
Sent: Wednesday, March 18, 2015 1:26 PM
To: C++std-ext; ehsan@mozilla.com; std-proposals@isocpp.org
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-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_DM2PR0301MB0911105FCB640A60230A94E2B0000DM2PR0301MB0911_
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;}
/* 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;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
..MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1F497D">Does the non-static data member need =
to be constexpr if it is virtual? Why?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1F497D">-- Gaby<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif;color:#1F497D"><o:p> </o:p></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">From:</span></b><span style=3D"font-size:11.0pt;=
font-family:"Calibri",sans-serif"> 'Botond Ballo' via ISO C+&=
#43; Standard - Future Proposals [mailto:std-proposals@isocpp.org]
<br>
<b>Sent:</b> Wednesday, March 18, 2015 1:26 PM<br>
<b>To:</b> C++std-ext; ehsan@mozilla.com; std-proposals@isocpp.org<=
br>
<b>Subject:</b> [std-proposals] virtual constexpr fields<o:p></o:p></span><=
/p>
</div>
</div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<div>
<div id=3D"yui_3_16_0_1_1426691947599_108603">
<p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-size:=
9.0pt;font-family:"Helvetica",sans-serif;color:black">There are c=
ases 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() { 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<o:p></o:p></span></p>
</div>
<div id=3D"yui_3_16_0_1_1426691947599_108603">
<p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-size:=
9.0pt;font-family:"Helvetica",sans-serif;color:black"><o:p> =
</o:p></span></p>
</div>
</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>
</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_DM2PR0301MB0911105FCB640A60230A94E2B0000DM2PR0301MB0911_--
.
Author: Tony Van Eerd <tvaneerd@blackberry.com>
Date: Wed, 18 Mar 2015 20:52:59 +0000
Raw View
--_000_11B5438424E807459A28BD01C92339BA759E907CXMB122CNCrimnet_
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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)
From: Gabriel Dos Reis [mailto:gdr@microsoft.com]
Sent: Wednesday, March 18, 2015 4:42 PM
To: 'std-proposals@isocpp.org'; C++std-ext; 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-pr=
oposals@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 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-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_11B5438424E807459A28BD01C92339BA759E907CXMB122CNCrimnet_
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 14 (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:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 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";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
..MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">I would say it needs to b=
e constexpr or static =E2=80=93 at least for it to be stored in the vtable.=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">(ie assuming the vtable i=
s shared by all instances of the class means that the value is shared by al=
l instances of the class)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></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"">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:"Tahoma","sans-serif""> Gabriel =
Dos Reis [mailto:gdr@microsoft.com]
<br>
<b>Sent:</b> Wednesday, March 18, 2015 4:42 PM<br>
<b>To:</b> 'std-proposals@isocpp.org'; C++std-ext; ehsan@mozilla.co=
m<br>
<b>Subject:</b> [c++std-ext-16622] Re: [std-proposals] virtual cons=
texpr fields<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">Does the non-static data =
member need to be constexpr if it is virtual? Why?<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D">-- Gaby<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1F497D"><o:p> </o:p></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"">From:</span></b><span style=3D"font-=
size:11.0pt;font-family:"Calibri","sans-serif""> 'Boton=
d Ballo' via ISO C++ Standard - Future Proposals [<a href=3D"mailto=
:std-proposals@isocpp.org">mailto:std-proposals@isocpp.org</a>]
<br>
<b>Sent:</b> Wednesday, March 18, 2015 1:26 PM<br>
<b>To:</b> C++std-ext; <a href=3D"mailto:ehsan@mozilla.com">ehsan@m=
ozilla.com</a>; <a href=3D"mailto:std-proposals@isocpp.org">
std-proposals@isocpp.org</a><br>
<b>Subject:</b> [std-proposals] virtual constexpr fields<o:p></o:p></span><=
/p>
</div>
</div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<div>
<div id=3D"yui_3_16_0_1_1426691947599_108603">
<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 t=
ype. 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<o:p></o:p></span></p>
</div>
<div id=3D"yui_3_16_0_1_1426691947599_108603">
<p class=3D"MsoNormal" style=3D"background:white"><span style=3D"font-size:=
9.0pt;font-family:"Helvetica","sans-serif";color:black"=
><o:p> </o:p></span></p>
</div>
</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_11B5438424E807459A28BD01C92339BA759E907CXMB122CNCrimnet_--
.
Author: Ehsan Akhgari <ehsan@mozilla.com>
Date: Wed, 18 Mar 2015 16:57:01 -0400
Raw View
--001a113a9a64905f93051196552e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Mar 18, 2015 at 4:52 PM, Tony Van Eerd <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 tha=
t
> the value is shared by all instances of the class)
>
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.
>
>
> *From:* Gabriel Dos Reis [mailto:gdr@microsoft.com]
> *Sent:* Wednesday, March 18, 2015 4:42 PM
> *To:* 'std-proposals@isocpp.org'; C++std-ext; ehsan@mozilla.com
> *Subject:* [c++std-ext-16622] Re: [std-proposals] virtual constexpr field=
s
>
>
>
> 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 <std-proposals@isocpp.org>]
> *Sent:* Wednesday, March 18, 2015 1:26 PM
> *To:* C++std-ext; ehsan@mozilla.com; 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 determin=
ed
> at compile time.
>
> Has this, or something similar, ever been proposed? Is there any interest
> in 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
> 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/.
>
--=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/.
--001a113a9a64905f93051196552e
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 W=
ed, Mar 18, 2015 at 4:52 PM, Tony Van Eerd <span dir=3D"ltr"><<a href=3D=
"mailto:tvaneerd@blackberry.com" target=3D"_blank">tvaneerd@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:"Ca=
libri","sans-serif";color:#1f497d">I would say it needs to b=
e constexpr or static =E2=80=93 at least for it to be stored in the vtable.=
<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1f497d">(ie assuming the vtable i=
s shared by all instances of the class means that the value is shared by al=
l instances of the class)<u></u><u></u></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 b=
e able to store the vtable in read-only memory in order to protect against =
security attacks attempting to overwrite vtable entries at runtime.<br></di=
v><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";color:#1=
f497d"></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></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"">From:</span></b><span style=3D"font-s=
ize:10.0pt;font-family:"Tahoma","sans-serif""> Gabriel =
Dos Reis [mailto:<a 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 href=3D"mailto:std-proposals@isocpp.org" target=3D"_blan=
k">std-proposals@isocpp.org</a>'; C++std-ext; <a href=3D"mailto:ehsan@m=
ozilla.com" target=3D"_blank">ehsan@mozilla.com</a><br>
<b>Subject:</b> [c++std-ext-16622] Re: [std-proposals] virtual constexpr fi=
elds<u></u><u></u></span></p>
</div>
</div><div><div class=3D"h5">
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1f497d">Does the non-static data =
member need to be constexpr if it is virtual?=C2=A0 Why?<u></u><u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1f497d">-- Gaby<u></u><u></u></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri","sans-serif";color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></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"">From:</span></b><span style=3D"font-=
size:11.0pt;font-family:"Calibri","sans-serif""> 'B=
otond Ballo' via ISO C++ Standard - Future Proposals [<a href=3D"mailto=
:std-proposals@isocpp.org" target=3D"_blank">mailto:std-proposals@isocpp.or=
g</a>]
<br>
<b>Sent:</b> Wednesday, March 18, 2015 1:26 PM<br>
<b>To:</b> C++std-ext; <a href=3D"mailto:ehsan@mozilla.com" target=3D"_blan=
k">ehsan@mozilla.com</a>; <a href=3D"mailto:std-proposals@isocpp.org" targe=
t=3D"_blank">
std-proposals@isocpp.org</a><br>
<b>Subject:</b> [std-proposals] virtual constexpr fields<u></u><u></u></spa=
n></p>
</div>
</div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></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 t=
ype. Here is how you can currently do it in C++:<br>
<br>
struct Merchandise {<br>
=C2=A0=C2=A0=C2=A0 virtual int price() { return 0; }<br>
};<br>
<br>
struct Shoe : Merchandise {<br>
=C2=A0=C2=A0=C2=A0 virtual int price() { return 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 price =3D 0;<br>
};<br>
<br>
struct Shoe : Merchandise {<br>
=C2=A0=C2=A0=C2=A0 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<u></u><u></u></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"=
><u></u>=C2=A0<u></u></span></p>
</div>
</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" target=3D"_blank">s=
td-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">
http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<u></u><u></=
u></p>
</div></div></div>
</div>
</div>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature"><div dir=3D"ltr">Ehsan<br></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 />
--001a113a9a64905f93051196552e--
.
Author: Gabriel Dos Reis <gdr@microsoft.com>
Date: Wed, 18 Mar 2015 21:27:23 +0000
Raw View
--_000_142671404337652384microsoftcom_
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
If it is going in the vtable, why is it a *non-static* data member?
-- Gaby
________________________________
From: Ehsan Akhgari <ehsan@mozilla.com>
Sent: Wednesday, March 18, 2015 1:57 PM
To: Tony Van Eerd
Cc: c++std-ext@accu.org; std-proposals@isocpp.org
Subject: Re: [std-proposals] virtual constexpr fields
On Wed, Mar 18, 2015 at 4:52 PM, Tony Van Eerd <tvaneerd@blackberry.com<mai=
lto:tvaneerd@blackberry.com>> wrote:
I would say it needs to be constexpr or static - at least for it to be stor=
ed 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: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-pr=
oposals@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 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-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/.
--
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_142671404337652384microsoftcom_
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
</head>
<body dir=3D"ltr">
<style type=3D"text/css" style=3D"display:none"><!-- p {margin-top:0;margin=
-bottom:0;} --></style>
<div role=3D"textbox" style=3D"color: rgb(0, 0, 0); font-family: 'Palatino =
Linotype', 'Book Antiqua', Palatino, serif,'Apple Color Emoji', 'Segoe UI E=
moji', NotoColorEmoji, 'Segoe UI Symbol', 'Android Emoji', EmojiSymbols; fo=
nt-size: 10pt; background-color: rgb(255, 255, 255);" dir=3D"ltr" useinline=
style=3D"true">
<p>If it is going in the vtable, why is it a *non-static* data member?</p>
<p><br>
</p>
<p>-- Gaby</p>
<br>
<br>
<div style=3D"color: rgb(33, 33, 33);">
<hr tabindex=3D"-1" style=3D"width: 98%; display: inline-block;">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font color=3D"#000000" face=3D"Calib=
ri, sans-serif" style=3D"font-size: 11pt;"><b>From:</b> Ehsan Akhgari <e=
hsan@mozilla.com><br>
<b>Sent:</b> Wednesday, March 18, 2015 1:57 PM<br>
<b>To:</b> Tony Van Eerd<br>
<b>Cc:</b> c++std-ext@accu.org; std-proposals@isocpp.org<br>
<b>Subject:</b> Re: [std-proposals] virtual constexpr fields</font>
<div> </div>
</div>
<div>
<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 href=3D"mailto:tvaneerd@blackberry.com" target=3D"_blank">tvaneerd@b=
lackberry.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;">
<div lang=3D"EN-US">
<div>
<p class=3D"MsoNormal"><span style=3D"color: rgb(31, 73, 125); font-family:=
"Calibri","sans-serif"; font-size: 11pt;">I would say =
it needs to be constexpr or static – at least for it to be stored in =
the vtable.<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"color: rgb(31, 73, 125); font-family:=
"Calibri","sans-serif"; font-size: 11pt;">(ie assuming=
the vtable is shared by all instances of the class means that the value is=
shared by all instances of the class)<u></u><u></u></span></p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes, exactly. Note that from a pragmatic standpoint, it's probab=
ly important for compilers to be able to store the vtable in read-only memo=
ry in order to protect against security attacks attempting to overwrite vta=
ble entries at runtime.<br>
</div>
<div> </div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;">
<div lang=3D"EN-US">
<div>
<p class=3D"MsoNormal"><span style=3D"color: rgb(31, 73, 125); font-family:=
"Calibri","sans-serif"; font-size: 11pt;"></span></p>
<p class=3D"MsoNormal"><span style=3D"color: rgb(31, 73, 125); font-family:=
"Calibri","sans-serif"; font-size: 11pt;"><u></u> =
;<u></u></span></p>
<div style=3D"border-width: medium medium medium 1.5pt; border-style: none =
none none solid; border-color: currentColor currentColor currentColor blue;=
padding: 0in 0in 0in 4pt; border-image: none;">
<div>
<div style=3D"border-width: 1pt medium medium; border-style: solid none non=
e; border-color: rgb(181, 196, 223) currentColor currentColor; padding: 3pt=
0in 0in; border-image: none;">
<p class=3D"MsoNormal"><b><span style=3D"font-family: "Tahoma",&q=
uot;sans-serif"; font-size: 10pt;">From:</span></b><span style=3D"font=
-family: "Tahoma","sans-serif"; font-size: 10pt;"> Gabr=
iel Dos Reis [mailto:<a 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 href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">s=
td-proposals@isocpp.org</a>'; C++std-ext;
<a 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 cons=
texpr fields<u></u><u></u></span></p>
</div>
</div>
<div>
<div class=3D"h5">
<p class=3D"MsoNormal"><u></u> <u></u></p>
<p class=3D"MsoNormal"><span style=3D"color: rgb(31, 73, 125); font-family:=
"Calibri","sans-serif"; font-size: 11pt;">Does the non=
-static data member need to be constexpr if it is virtual? Why?<u></u=
><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"color: rgb(31, 73, 125); font-family:=
"Calibri","sans-serif"; font-size: 11pt;"><u></u> =
;<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"color: rgb(31, 73, 125); font-family:=
"Calibri","sans-serif"; font-size: 11pt;">-- Gaby<u></=
u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"color: rgb(31, 73, 125); font-family:=
"Calibri","sans-serif"; font-size: 11pt;"><u></u> =
;<u></u></span></p>
<div>
<div style=3D"border-width: 1pt medium medium; border-style: solid none non=
e; border-color: rgb(225, 225, 225) currentColor currentColor; padding: 3pt=
0in 0in; border-image: none;">
<p class=3D"MsoNormal"><b><span style=3D"font-family: "Calibri",&=
quot;sans-serif"; font-size: 11pt;">From:</span></b><span style=3D"fon=
t-family: "Calibri","sans-serif"; font-size: 11pt;"> 'B=
otond Ballo' via ISO C++ Standard - Future Proposals [<a href=3D"ma=
ilto:std-proposals@isocpp.org" target=3D"_blank">mailto:std-proposals@isocp=
p.org</a>]
<br>
<b>Sent:</b> Wednesday, March 18, 2015 1:26 PM<br>
<b>To:</b> C++std-ext; <a href=3D"mailto:ehsan@mozilla.com" target=
=3D"_blank">ehsan@mozilla.com</a>;
<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals=
@isocpp.org</a><br>
<b>Subject:</b> [std-proposals] virtual constexpr fields<u></u><u></u></spa=
n></p>
</div>
</div>
<p class=3D"MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class=3D"MsoNormal" style=3D"background: white;"><span style=3D"color: b=
lack; font-family: "Helvetica","sans-serif"; font-size:=
9pt;">There are cases where you would like to associate constants with a g=
iven 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<u></u><u></u></span></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"background: white;"><span style=3D"color: b=
lack; font-family: "Helvetica","sans-serif"; font-size:=
9pt;"><u></u> <u></u></span></p>
</div>
</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" target=3D"_blan=
k">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">
std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">
http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<u></u><u></=
u></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>
<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-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>.<br>
</div>
</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_142671404337652384microsoftcom_--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 19 Mar 2015 06:49:49 +0900
Raw View
On Wednesday 18 March 2015 21:27:23 Gabriel Dos Reis wrote:
> If it is going in the vtable, why is it a *non-static* data member?
It should be static.
This will be the first time we have a "virtual static" though.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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/.
.
Author: Brian Bi <bbi5291@gmail.com>
Date: Wed, 18 Mar 2015 14:53:06 -0700
Raw View
--089e0141a498c15d9b0511971bcb
Content-Type: text/plain; charset=UTF-8
operator new and operator delete are already implicitly virtual and static,
aren't they?
On Wed, Mar 18, 2015 at 2:49 PM, Thiago Macieira <thiago@macieira.org>
wrote:
> On Wednesday 18 March 2015 21:27:23 Gabriel Dos Reis wrote:
> > If it is going in the vtable, why is it a *non-static* data member?
>
> It should be static.
>
> This will be the first time we have a "virtual static" though.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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/.
>
--
*Brian Bi*
--
---
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/.
--089e0141a498c15d9b0511971bcb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">operator new and operator delete are already implicitly vi=
rtual and static, aren't they?</div><div class=3D"gmail_extra"><br><div=
class=3D"gmail_quote">On Wed, Mar 18, 2015 at 2:49 PM, Thiago Macieira <sp=
an dir=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank"=
>thiago@macieira.org</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><span class=3D"">On Wednesday 18 March 2015 21:27:23 Gabriel Dos Reis wro=
te:<br>
> If it is going in the vtable, why is it a *non-static* data member?<br=
>
<br>
</span>It should be static.<br>
<br>
This will be the first time we have a "virtual static" though.<br=
>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F005 6EF4 535=
8<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><font=
color=3D"#c0c0c0"><i>Brian Bi</i></font><br><div></div><div></div><div></d=
iv></div></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 />
--089e0141a498c15d9b0511971bcb--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Wed, 18 Mar 2015 18:20:17 -0400
Raw View
On Wed, Mar 18, 2015 at 5:49 PM, Thiago Macieira <thiago@macieira.org> wrote:
> On Wednesday 18 March 2015 21:27:23 Gabriel Dos Reis wrote:
>> If it is going in the vtable, why is it a *non-static* data member?
>
> It should be static.
>
If it's static, it doesn't need to be virtual; if it's virtual, it
doesn't need to be static.
Use cases of static:
Base::var -- you already know the class name, what else you
expect?
void f() const { ... var } -- already most derived without virtual
Use cases of virtual:
ptr->var -- most derived
void f() const { ... var } -- works without static
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--
---
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/.
.
Author: ehsan.akhgari@gmail.com
Date: Wed, 18 Mar 2015 15:25:08 -0700 (PDT)
Raw View
------=_Part_955_1546798655.1426717508487
Content-Type: multipart/alternative;
boundary="----=_Part_956_1755447650.1426717508487"
------=_Part_956_1755447650.1426717508487
Content-Type: text/plain; charset=UTF-8
On Wednesday, March 18, 2015 at 5:49:56 PM UTC-4, Thiago Macieira wrote:
>
> On Wednesday 18 March 2015 21:27:23 Gabriel Dos Reis wrote:
> > If it is going in the vtable, why is it a *non-static* data member?
>
> It should be static.
>
Yes, we can make the syntax include the static keyword.
> This will be the first time we have a "virtual static" though.
>
This was why we were hesitant to use the static keyword, but I don't feel
strongly about this one way or the other.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
>
--
---
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_956_1755447650.1426717508487
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, March 18, 2015 at 5:49:56 PM UTC-4, Thiago M=
acieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Wednesday 18 =
March 2015 21:27:23 Gabriel Dos Reis wrote:
<br>> If it is going in the vtable, why is it a *non-static* data member=
?
<br>
<br>It should be static.
<br></blockquote><div><br>Yes, we can make the syntax include the static ke=
yword.<br> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">This wil=
l be the first time we have a "virtual static" though.
<br></blockquote><div><br>This was why we were hesitant to use the static k=
eyword, but I don't feel strongly about this one way or the other.<br> =
;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNE=
swDUBNCNanbu7euhqLn_62FW8ag';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg=
\75AFQjCNEswDUBNCNanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - th=
iago (AT) <a href=3D"http://kde.org" target=3D"_blank" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde.org=
\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return tr=
ue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fkde=
..org\46sa\75D\46sntz\0751\46usg\75AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';retur=
n true;">kde.org</a>
<br> Software Architect - Intel Open Source Technology Center
<br> PGP/GPG: 0x6EF45358; fingerprint:
<br> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4=
5358
<br>
<br></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_956_1755447650.1426717508487--
------=_Part_955_1546798655.1426717508487--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 19 Mar 2015 07:03:23 +0800
Raw View
--Apple-Mail=_656EEDBE-D78F-4AE6-A3A8-231EAC23D55A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9303=E2=80=9319, at 5:43 AM, Bjarne Stroustrup <bjarne@stro=
ustrup.com> wrote:
>=20
> (3) what's the important use case?
Simple classification functions returning a single value, typically an enum=
erator, shouldn=E2=80=99t require an indirect branch. The other style for t=
his is to use dynamic_cast, which also has too much overhead.
> On 2015=E2=80=9303=E2=80=9319, at 6:20 AM, Zhihao Yuan <zy@miator.net> wr=
ote:
>=20
> If it's static, it doesn't need to be virtual; if it's virtual, it
> doesn't need to be static.
It=E2=80=99s important to require the static keyword. Users need to know th=
at it=E2=80=99s not an instance variable.
> On 2015=E2=80=9303=E2=80=9319, at 4:25 AM, 'Botond Ballo' wrote:
>=20
> Has this, or something similar, ever been proposed? Is there any interest=
in it?
It=E2=80=99s in my backlog of things to propose, although I=E2=80=99ve not =
done my homework to find precedents. Absolutely, go for it.
> On 2015=E2=80=9303=E2=80=9319, at 5:53 AM, Brian Bi <bbi5291@gmail.com> w=
rote:
>=20
> operator new and operator delete are already implicitly virtual and stati=
c, aren't they?
Only operator delete. But that=E2=80=99s more a side-effect of the nature o=
f a pointer to a destructed object. The would-be implicit parameter is conv=
erted to void* and given a name. Also, it=E2=80=99s not an ordinary virtual=
dispatch, but a static call from the most-derived destructor.
--=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/.
--Apple-Mail=_656EEDBE-D78F-4AE6-A3A8-231EAC23D55A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D""><b=
lockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9303=E2=80=
=9319, at 5:43 AM, Bjarne Stroustrup <<a href=3D"mailto:bjarne@stroustru=
p.com" class=3D"">bjarne@stroustrup.com</a>> wrote:</div><br class=3D"Ap=
ple-interchange-newline"><div class=3D""><div bgcolor=3D"#FFFFFF" text=3D"#=
000000" class=3D"">(3) what's the important use case?<br class=3D""></div><=
/div></blockquote><br class=3D""></div><div class=3D"">Simple classificatio=
n functions returning a single value, typically an enumerator, shouldn=E2=
=80=99t require an indirect branch. The other style for this is to use =
;<font face=3D"Courier" class=3D"">dynamic_cast</font>, which also has too =
much overhead.</div><div class=3D""><br class=3D""></div><div class=3D""><b=
r class=3D""></div><div class=3D""><blockquote type=3D"cite" class=3D""><di=
v class=3D"">On 2015=E2=80=9303=E2=80=9319, at 6:20 AM, Zhihao Yuan <<a =
href=3D"mailto:zy@miator.net" class=3D"">zy@miator.net</a>> wrote:</div>=
<br class=3D"Apple-interchange-newline"><div class=3D""><span class=3D"" st=
yle=3D"float: none; display: inline !important;">If it's static, it doesn't=
need to be virtual; if it's virtual, it</span><br class=3D""><span class=
=3D"" style=3D"float: none; display: inline !important;">doesn't need to be=
static.</span><br class=3D""></div></blockquote><br class=3D""></div><div =
class=3D"">It=E2=80=99s important to require the <font face=3D"Courier" cla=
ss=3D"">static</font> keyword. Users need to know that it=E2=80=99s not an =
instance variable.</div><div class=3D""><br class=3D""></div><div class=3D"=
"><br class=3D""></div><div class=3D""><blockquote type=3D"cite" class=3D""=
><div class=3D"">On 2015=E2=80=9303=E2=80=9319, at 4:25 AM, 'Botond Ballo' =
wrote:</div></blockquote></div><div class=3D""><blockquote type=3D"cite" cl=
ass=3D""><br class=3D"Apple-interchange-newline"><div class=3D""><span clas=
s=3D"" style=3D"font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Ar=
ial, 'Lucida Grande', sans-serif; background-color: rgb(255, 255, 255); flo=
at: none; display: inline !important;">Has this, or something similar, ever=
been proposed? Is there any interest in it?</span><br class=3D"" style=3D"=
font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Gra=
nde', sans-serif;"></div></blockquote></div><div class=3D""><div class=3D""=
><span class=3D"" style=3D"font-family: HelveticaNeue, 'Helvetica Neue', He=
lvetica, Arial, 'Lucida Grande', sans-serif; background-color: rgb(255, 255=
, 255); float: none; display: inline !important;"><br class=3D""></span></d=
iv></div><div class=3D""><span class=3D"" style=3D"font-family: HelveticaNe=
ue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; backgr=
ound-color: rgb(255, 255, 255); float: none; display: inline !important;">I=
t=E2=80=99s in my backlog of things to propose, although I=E2=80=99ve not d=
one my homework to find precedents. Absolutely, go for it.</span></div><div=
class=3D""><br class=3D""></div><div class=3D""><br class=3D""></div><div =
class=3D""><blockquote type=3D"cite" class=3D""></blockquote></div><div><bl=
ockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9303=E2=80=
=9319, at 5:53 AM, Brian Bi <<a href=3D"mailto:bbi5291@gmail.com" class=
=3D"">bbi5291@gmail.com</a>> wrote:</div><br class=3D"Apple-interchange-=
newline"><div class=3D""><div dir=3D"ltr" class=3D"">operator new and opera=
tor delete are already implicitly virtual and static, aren't they?</div></d=
iv></blockquote></div><br class=3D""><div class=3D"">Only <font face=
=3D"Courier" class=3D"">operator delete</font>. But that=E2=80=99s more a s=
ide-effect of the nature of a pointer to a destructed object. The would-be =
implicit parameter is converted to <font face=3D"Courier" class=3D"">void*<=
/font> and given a name. Also, it=E2=80=99s not an ordinary virtual dispatc=
h, but a static call from the most-derived destructor.</div><div class=3D""=
><br class=3D""></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 />
--Apple-Mail=_656EEDBE-D78F-4AE6-A3A8-231EAC23D55A--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 18 Mar 2015 18:30:17 -0700 (PDT)
Raw View
------=_Part_7403_1848766964.1426728617273
Content-Type: multipart/alternative;
boundary="----=_Part_7404_508345137.1426728617273"
------=_Part_7404_508345137.1426728617273
Content-Type: text/plain; charset=UTF-8
Setting aside the bikeshed issue of what words to use to declare it,we
first need to define what exactly it is. It's also important to remember
that "vtables" don't exist. They're an implementation detail; no compiler
is required to use them to make virtual functions/derived classes work.
So, you seem to be talking about an object who's storage is directly
associated to a type. But, unlike static data members, every type derived
from it will have *separate* storage. So "static" is the wrong word.
You want these values to be immutable. Once created, their value cannot be
changed (and const-casting your way around it yields undefined behavior).
So they're like a const variable.
While the object value is associated with the type, you want to access them
as though they were a member of an instance of that type. And more to the
point, you want the value returned to be the value fetched from the object
associated with the object's dynamic type. Since a dynamic type is by
definition a runtime fetch, it is certainly not "constexpr".
Each class needs to initialize this value with its own parameters. But this
doesn't happen at construction time; it happens somewhere else. Possibly
before the execution of main(). Which means that it's like a static in
terms of initialization and destruction.
I don't know. This is a whole lot of complexity just to do cheaper RTTI.
Wouldn't it make more sense to just add cheaper RTTI to C++?
--
---
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_7404_508345137.1426728617273
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Setting aside the bikeshed issue of what words to use to d=
eclare it,we first need to define what exactly it is. It's also important t=
o remember that "vtables" don't exist. They're an implementation detail; no=
compiler is required to use them to make virtual functions/derived classes=
work.<i></i><br><br>So, you seem to be talking about an object who's stora=
ge is directly associated to a type. But, unlike static data members, every=
type derived from it will have <i>separate</i> storage. So "static" is the=
wrong word.<br><br>You want these values to be immutable. Once created, th=
eir value cannot be changed (and const-casting your way around it yields un=
defined behavior). So they're like a const variable.<br><br>While the objec=
t value is associated with the type, you want to access them as though the=
y were a member of an instance of that type. And more to the point, you wan=
t the value returned to be the value fetched from the object associated wit=
h the object's dynamic type. Since a dynamic type is by definition a runtim=
e fetch, it is certainly not "constexpr".<br><br>Each class needs to initia=
lize this value with its own parameters. But this doesn't happen at constru=
ction time; it happens somewhere else. Possibly before the execution of mai=
n(). Which means that it's like a static in terms of initialization and des=
truction.<br><br>I don't know. This is a whole lot of complexity just to do=
cheaper RTTI. Wouldn't it make more sense to just add cheaper RTTI to C++?=
<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_7404_508345137.1426728617273--
------=_Part_7403_1848766964.1426728617273--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 18 Mar 2015 20:49:28 -0500
Raw View
--001a113497667d08cf05119a6b0f
Content-Type: text/plain; charset=UTF-8
On 18 March 2015 at 20:30, Nicol Bolas <jmckesson@gmail.com> wrote:
> This is a whole lot of complexity just to do cheaper RTTI.
>
While I see a vocabulary problem (given that this is something new, it
isn't necessarily unusual), I don't see a complexity problem. What
difficulties do you envision to implement it? What difficulties do you
envision to use it?
Personally, I'd like to see more motivating examples, as well as
limitations. For instance: can you store a std::string in the vtable (or
equivalent)?
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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/.
--001a113497667d08cf05119a6b0f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">On 18 March 2015 at 20:30, Nico=
l Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=
=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">This is a whole lo=
t of complexity just to do cheaper RTTI.</div></blockquote><div><br></div><=
div>While I see a vocabulary problem (given that this is something new, it =
isn't necessarily unusual), I don't see a complexity problem.=C2=A0=
What difficulties do you envision to implement it?=C2=A0 What difficulties=
do you envision to use it?</div><div><br></div><div>Personally, I'd li=
ke to see more motivating examples, as well as limitations.=C2=A0 For insta=
nce: =C2=A0can you store a std::string in the vtable (or equivalent)?</div>=
<div>--=C2=A0<br></div></div><div class=3D"gmail_signature">=C2=A0Nevin &qu=
ot;:-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.co=
m" target=3D"_blank">nevin@eviloverlord.com</a>>=C2=A0 (847) 691-1404</d=
iv>
</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 />
--001a113497667d08cf05119a6b0f--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 19 Mar 2015 09:56:19 +0800
Raw View
--Apple-Mail=_6D40968A-FA4A-4A38-BEB2-42DC80DC0F1B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9303=E2=80=9319, at 9:30 AM, Nicol Bolas <jmckesson@gmail.c=
om> wrote:
>=20
> Setting aside the bikeshed issue of what words to use to declare it,we fi=
rst need to define what exactly it is. It's also important to remember that=
"vtables" don't exist. They're an implementation detail; no compiler is re=
quired to use them to make virtual functions/derived classes work.
>=20
> So, you seem to be talking about an object who's storage is directly asso=
ciated to a type. But, unlike static data members, every type derived from =
it will have separate storage. So "static" is the wrong word.
This thread hasn=E2=80=99t actually agreed that, yet. There are two other a=
lternatives:
1. Let the name of the virtual object be an rvalue, like an enumerator, so =
it has no apparent storage. Note that these values will often have enumerat=
ion type.
2. Stick an object pointer in the vtable (or whatever other sort of dispatc=
h system), which refers to an object shared between types of a hierarchy.
Anyway, behavior can be defined however works best, even if the static keyw=
ord gains yet another nuance.
> While the object value is associated with the type, you want to access th=
em as though they were a member of an instance of that type. And more to th=
e point, you want the value returned to be the value fetched from the objec=
t associated with the object's dynamic type. Since a dynamic type is by def=
inition a runtime fetch, it is certainly not "constexpr=E2=80=9D.
There are already rumblings about enabling dynamic types in constant expres=
sion evaluation. In principle, RTTI is no more dynamic than any other part =
of an object. The restriction on literal types is arbitrary.
> Each class needs to initialize this value with its own parameters. But th=
is doesn't happen at construction time; it happens somewhere else. Possibly=
before the execution of main(). Which means that it's like a static in ter=
ms of initialization and destruction.
It=E2=80=99s statically initialized.
> I don't know. This is a whole lot of complexity just to do cheaper RTTI. =
Wouldn't it make more sense to just add cheaper RTTI to C++?
You raise a good question regarding object identity, but there=E2=80=99s no=
complexity there. The proposal is essentially to allow arbitrary literal t=
ypes where we currently have only function pointers. It=E2=80=99s nowhere n=
ear a redesign of RTTI.
--=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/.
--Apple-Mail=_6D40968A-FA4A-4A38-BEB2-42DC80DC0F1B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9303=
=E2=80=9319, at 9:30 AM, Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.=
com" class=3D"">jmckesson@gmail.com</a>> wrote:</div><br class=3D"Apple-=
interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">Setting as=
ide the bikeshed issue of what words to use to declare it,we first need to =
define what exactly it is. It's also important to remember that "vtables" d=
on't exist. They're an implementation detail; no compiler is required to us=
e them to make virtual functions/derived classes work.<i class=3D""></i><br=
class=3D""><br class=3D"">So, you seem to be talking about an object who's=
storage is directly associated to a type. But, unlike static data members,=
every type derived from it will have <i class=3D"">separate</i> storage. S=
o "static" is the wrong word.<br class=3D""></div></div></blockquote><div><=
br class=3D""></div><div>This thread hasn=E2=80=99t actually agreed that, y=
et. There are two other alternatives:</div><div><br class=3D""></div><div>1=
.. Let the name of the virtual object be an rvalue, like an enumerator, so i=
t has no apparent storage. Note that these values will often have enumerati=
on type.</div><div><br class=3D""></div><div>2. Stick an object pointer in =
the vtable (or whatever other sort of dispatch system), which refers to an =
object shared between types of a hierarchy.</div><div><br class=3D""></div>=
<div>Anyway, behavior can be defined however works best, even if the <font =
face=3D"Courier" class=3D"">static</font> keyword gains yet another nuance.=
</div><div><br class=3D""></div><blockquote type=3D"cite" class=3D""><div c=
lass=3D""><div dir=3D"ltr" class=3D"">While the object value is associated=
with the type, you want to access them as though they were a member of an =
instance of that type. And more to the point, you want the value returned t=
o be the value fetched from the object associated with the object's dynamic=
type. Since a dynamic type is by definition a runtime fetch, it is certain=
ly not "constexpr=E2=80=9D.<br class=3D""></div></div></blockquote><div><br=
class=3D""></div><div>There are already rumblings about enabling dynamic t=
ypes in constant expression evaluation. In principle, RTTI is no more dynam=
ic than any other part of an object. The restriction on literal types is ar=
bitrary.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div clas=
s=3D""><div dir=3D"ltr" class=3D"">Each class needs to initialize this valu=
e with its own parameters. But this doesn't happen at construction time; it=
happens somewhere else. Possibly before the execution of main(). Which mea=
ns that it's like a static in terms of initialization and destruction.<br c=
lass=3D""></div></div></blockquote><div><br class=3D""></div><div>It=E2=80=
=99s statically initialized.</div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><div dir=3D"ltr" class=3D"">I don't know. This i=
s a whole lot of complexity just to do cheaper RTTI. Wouldn't it make more =
sense to just add cheaper RTTI to C++?<br class=3D""></div></div></blockquo=
te><br class=3D""></div><div>You raise a good question regarding object ide=
ntity, but there=E2=80=99s no complexity there. The proposal is essentially=
to allow arbitrary literal types where we currently have only function poi=
nters. It=E2=80=99s nowhere near a redesign of RTTI.</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 />
--Apple-Mail=_6D40968A-FA4A-4A38-BEB2-42DC80DC0F1B--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 19 Mar 2015 13:55:31 +0900
Raw View
On Wednesday 18 March 2015 20:49:28 Nevin Liber wrote:
> Personally, I'd like to see more motivating examples, as well as
> limitations. For instance: can you store a std::string in the vtable (or
> equivalent)?
That's where the constexpr keyword comes into play: you should be able to
store anything that is a literal type.
std::string is not a literal type.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 19 Mar 2015 13:20:19 +0800
Raw View
--Apple-Mail=_FA9F822F-9E8D-42CD-860D-44000B7ACB28
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On 2015=E2=80=9303=E2=80=9319, at 12:55 PM, Thiago Macieira <thiago@macie=
ira.org> wrote:
>=20
> That's where the constexpr keyword comes into play: you should be able to=
=20
> store anything that is a literal type.
>=20
> std::string is not a literal type.
std::string & works, though.
struct s {
static std::string kind_str;
static constexpr virtual
std::string & kind =3D kind_str; // provides read-write access
};
The rules for constexpr references are inconsistent. You can bind them to t=
emporaries, provided the temporary is of literal type, but for e.g. std::st=
ring there must be a named object. Such references aren=E2=80=99t always ev=
en compile-time constants. See also http://www.open-std.org/jtc1/sc22/wg21/=
docs/cwg_closed.html#2005 . (Unfortunately I didn=E2=80=99t attend the disc=
ussion where it was closed, and I=E2=80=99m not sure the point of the DR su=
bmission came across.)
Perhaps the strict constexpr requirement can be dropped, but require overri=
des to match in constexpr-ness. Then implementations can add a level of ind=
irection for the non-constant case, essentially automating the above trick.
--=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/.
--Apple-Mail=_FA9F822F-9E8D-42CD-860D-44000B7ACB28
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9303=
=E2=80=9319, at 12:55 PM, Thiago Macieira <<a href=3D"mailto:thiago@maci=
eira.org" class=3D"">thiago@macieira.org</a>> wrote:</div><br class=3D"A=
pple-interchange-newline"><div class=3D"">That's where the constexpr keywor=
d comes into play: you should be able to <br class=3D"">store anything that=
is a literal type.<br class=3D""><br class=3D"">std::string is not a liter=
al type.<br class=3D""></div></blockquote><div><br class=3D""></div></div><=
font face=3D"Courier" class=3D"">std::string &</font> works, thoug=
h.<div class=3D""><br class=3D""></div><div class=3D""><font face=3D"Courie=
r" class=3D"">struct s {</font></div><div class=3D""><font face=3D"Courier"=
class=3D""> static std::string kind_str;</font></div><div cla=
ss=3D""><font face=3D"Courier" class=3D""> static constexpr vi=
rtual</font></div><div class=3D""><font face=3D"Courier" class=3D""> =
std::string & kind =3D kind_str; // provides read-=
write access</font></div><div class=3D""><font face=3D"Courier" class=3D"">=
};<br class=3D""></font><div class=3D""><br class=3D""></div><div class=3D"=
">The rules for constexpr references are inconsistent. You can bind them to=
temporaries, provided the temporary is of literal type, but for e.g. <font=
face=3D"Courier" class=3D"">std::string</font> there must be a named objec=
t. Such references aren=E2=80=99t always even compile-time constants. See a=
lso <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#=
2005" class=3D"">http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.htm=
l#2005</a> . (Unfortunately I didn=E2=80=99t attend the discussion where it=
was closed, and I=E2=80=99m not sure the point of the DR submission came a=
cross.)</div></div><div class=3D""><br class=3D""></div><div class=3D"">Per=
haps the strict constexpr requirement can be dropped, but require overrides=
to match in constexpr-ness. Then implementations can add a level of indire=
ction for the non-constant case, essentially automating the above trick.</d=
iv></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 />
--Apple-Mail=_FA9F822F-9E8D-42CD-860D-44000B7ACB28--
.
Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Thu, 19 Mar 2015 03:30:20 -0700 (PDT)
Raw View
------=_Part_291_1861190388.1426761020909
Content-Type: multipart/alternative;
boundary="----=_Part_292_780048914.1426761020910"
------=_Part_292_780048914.1426761020910
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Althougn not compelling, as the virtual constexprs would normally only be=
=20
used twice, one example of where they could be useful is in service=20
dispatching, eg:
=20
=20
using Protocol =3D /* whatever */; =20
=20
class Handler { =20
public: =20
virtual constexpr Protocol low; // see note (1) =20
virtual constexpr Protocol high; // see note (1) =20
virtual void handle(Protocol protocol, Payload payload) =3D 0; =20
// =E2=80=A6 =20
}; =20
=20
class Dispatcher { =20
public: =20
void register(Handler *handler); =20
void deregister(Handler *handler); =20
// =E2=80=A6 =20
};
=20
In this case, the register and deregister methods would both use=20
handler->high and handler->low.
---
Note (1) This example illustrates one conflict of notation. I would like=
=20
low & high to be pure virtual, but using =E2=80=98=3D 0=E2=80=99 would pres=
umably give high &=20
low the values 0. Thus, I have left the values undefined in the example.
On Wednesday, 18 March 2015 20:25:51 UTC, Botond Ballo wrote:
> 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 determin=
ed=20
> at compile time.
>
> Has this, or something similar, ever been proposed? Is there any interest=
=20
> in it?
>
> -- Botond and 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/.
------=_Part_292_780048914.1426761020910
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><DIV>Althougn not compelling, as the virtual constexprs wo=
uld normally only be used twice, one example of where they could be useful =
is in service dispatching, eg:</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV style=3D"BORDER-BOTTOM: #bbb 1px solid; BORDER-LEFT: #bbb 1px solid; B=
ACKGROUND-COLOR: #fafafa; WORD-WRAP: break-word; BORDER-TOP: #bbb 1px solid=
; BORDER-RIGHT: #bbb 1px solid" class=3Dprettyprint><CODE class=3Dprettypri=
nt>
<DIV class=3Dsubprettyprint><SPAN style=3D"COLOR: #008" class=3Dstyled-by-p=
rettify>using</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify>=
</SPAN><SPAN style=3D"COLOR: #606" class=3Dstyled-by-prettify>Protocol</SP=
AN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN sty=
le=3D"COLOR: #660" class=3Dstyled-by-prettify>=3D</SPAN><SPAN style=3D"COLO=
R: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #800" cla=
ss=3Dstyled-by-prettify>/* whatever */</SPAN><SPAN style=3D"COLOR: #660" cl=
ass=3Dstyled-by-prettify>;</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled=
-by-prettify> <BR> <BR></SPAN><SPAN s=
tyle=3D"COLOR: #008" class=3Dstyled-by-prettify>class</SPAN><SPAN style=3D"=
COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #606"=
class=3Dstyled-by-prettify>Handler</SPAN><SPAN style=3D"COLOR: #000" class=
=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by=
-prettify>{</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> &=
nbsp; <BR></SPAN><SPAN style=3D"COLOR: #008" class=3Dstyled-by-=
prettify>public</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettif=
y>:</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> &n=
bsp; <BR></SPAN><SPAN style=3D"COLOR: #008" class=3Dstyled-by-prettify=
>virtual</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SP=
AN><SPAN style=3D"COLOR: #008" class=3Dstyled-by-prettify>constexpr</SPAN><=
SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=
=3D"COLOR: #606" class=3Dstyled-by-prettify>Protocol</SPAN><SPAN style=3D"C=
OLOR: #000" class=3Dstyled-by-prettify> low</SPAN><SPAN style=3D"COLOR: #66=
0" class=3Dstyled-by-prettify>;</SPAN><SPAN style=3D"COLOR: #000" class=3Ds=
tyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #800" class=3Dstyled-by-pre=
ttify>// see note (1) </SPAN><SPAN style=3D"COLOR: #000" class=
=3Dstyled-by-prettify> <BR></SPAN><SPAN style=3D"COLOR: #008" class=3D=
styled-by-prettify>virtual</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled=
-by-prettify> </SPAN><SPAN style=3D"COLOR: #008" class=3Dstyled-by-prettify=
>constexpr</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> </=
SPAN><SPAN style=3D"COLOR: #606" class=3Dstyled-by-prettify>Protocol</SPAN>=
<SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> high</SPAN><SPAN st=
yle=3D"COLOR: #660" class=3Dstyled-by-prettify>;</SPAN><SPAN style=3D"COLOR=
: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #800" clas=
s=3Dstyled-by-prettify>// see note (1) </SPAN><SPAN style=3D"C=
OLOR: #000" class=3Dstyled-by-prettify> <BR></SPAN><SPAN style=3D"COLO=
R: #008" class=3Dstyled-by-prettify>virtual</SPAN><SPAN style=3D"COLOR: #00=
0" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #008" class=3Ds=
tyled-by-prettify>void</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-=
prettify> handle</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-pretti=
fy>(</SPAN><SPAN style=3D"COLOR: #606" class=3Dstyled-by-prettify>Protocol<=
/SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> protocol</SPA=
N><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>,</SPAN><SPAN styl=
e=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: =
#606" class=3Dstyled-by-prettify>Payload</SPAN><SPAN style=3D"COLOR: #000" =
class=3Dstyled-by-prettify> payload</SPAN><SPAN style=3D"COLOR: #660" class=
=3Dstyled-by-prettify>)</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by=
-prettify> </SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>=
=3D</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><S=
PAN style=3D"COLOR: #066" class=3Dstyled-by-prettify>0</SPAN><SPAN style=3D=
"COLOR: #660" class=3Dstyled-by-prettify>;</SPAN><SPAN style=3D"COLOR: #000=
" class=3Dstyled-by-prettify> <BR></SPAN><SPAN style=3D"=
COLOR: #800" class=3Dstyled-by-prettify>// =E2=80=A6 </SPAN><S=
PAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> <BR></SPAN><SPAN=
style=3D"COLOR: #660" class=3Dstyled-by-prettify>};</SPAN><SPAN style=3D"C=
OLOR: #000" class=3Dstyled-by-prettify> <BR>  =
; <BR></SPAN><SPAN style=3D"COLOR: #008" class=3Dstyled-by-prettify>c=
lass</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><=
SPAN style=3D"COLOR: #606" class=3Dstyled-by-prettify>Dispatcher</SPAN><SPA=
N style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"C=
OLOR: #660" class=3Dstyled-by-prettify>{</SPAN><SPAN style=3D"COLOR: #000" =
class=3Dstyled-by-prettify> <BR></SPAN><SPAN style=3D"CO=
LOR: #008" class=3Dstyled-by-prettify>public</SPAN><SPAN style=3D"COLOR: #6=
60" class=3Dstyled-by-prettify>:</SPAN><SPAN style=3D"COLOR: #000" class=3D=
styled-by-prettify> <BR></SPAN><SPAN style=3D"COLOR: #00=
8" class=3Dstyled-by-prettify>void</SPAN><SPAN style=3D"COLOR: #000" class=
=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #008" class=3Dstyled-by=
-prettify>register</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-pret=
tify>(</SPAN><SPAN style=3D"COLOR: #606" class=3Dstyled-by-prettify>Handler=
</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN=
style=3D"COLOR: #660" class=3Dstyled-by-prettify>*</SPAN><SPAN style=3D"CO=
LOR: #000" class=3Dstyled-by-prettify>handler</SPAN><SPAN style=3D"COLOR: #=
660" class=3Dstyled-by-prettify>);</SPAN><SPAN style=3D"COLOR: #000" class=
=3Dstyled-by-prettify> <BR></SPAN><SPAN style=3D"COLOR: =
#008" class=3Dstyled-by-prettify>void</SPAN><SPAN style=3D"COLOR: #000" cla=
ss=3Dstyled-by-prettify> deregister</SPAN><SPAN style=3D"COLOR: #660" class=
=3Dstyled-by-prettify>(</SPAN><SPAN style=3D"COLOR: #606" class=3Dstyled-by=
-prettify>Handler</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prett=
ify> </SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>*</SPAN>=
<SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify>handler</SPAN><SPAN =
style=3D"COLOR: #660" class=3Dstyled-by-prettify>);</SPAN><SPAN style=3D"CO=
LOR: #000" class=3Dstyled-by-prettify> <BR></SPAN><SPAN =
style=3D"COLOR: #800" class=3Dstyled-by-prettify>// =E2=80=A6 =
</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> <BR></S=
PAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>};</SPAN></DIV><=
/CODE></DIV><BR>
<DIV> </DIV>
<DIV>In this case, the register and deregister methods would both use handl=
er->high and handler->low.</DIV>
<DIV>---</DIV>
<DIV>Note (1) This example illustrates one conflict of notation. I wo=
uld like low & high to be pure virtual, but using =E2=80=98=3D 0=E2=80=
=99 would presumably give high & low the values 0. Thus, I have l=
eft the values undefined in the example.</DIV>
<DIV><BR>On Wednesday, 18 March 2015 20:25:51 UTC, Botond Ballo wrote:</DIV=
>
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>
<DIV>
<DIV style=3D"BACKGROUND-COLOR: #fff; FONT-FAMILY: HelveticaNeue, Helvetica=
Neue, Helvetica, Arial, Lucida Grande, sans-serif; COLOR: #000; FONT-SIZE:=
12px">
<DIV dir=3Dltr>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>struc=
t Merchandise {<BR> virtual int price() { return 0; }<BR>=
};<BR><BR>struct Shoe : Merchandise {<BR> virtual int pri=
ce() { return 10;<BR>}<BR><BR>If you could do it this way instead:<BR><BR>s=
truct Merchandise {<BR> virtual constexpr int price =3D 0=
;<BR>};<BR><BR>struct Shoe : Merchandise {<BR> virtual co=
nstexpr int price =3D 10;<BR>}<BR><BR>then the compiler could store the con=
stant value directly in the vtable. This would eliminate the double indirec=
tion involved in dereferencing a function vtable entry, the cost of running=
that function at runtime, and the code size of the function in the compile=
d binary.<BR><BR>Virtual fields would be limited to being constexpr, so tha=
t the value to be placed in the vtable, like other values in the vtable, ca=
n be determined at compile time.<BR><BR>Has this, or something similar, eve=
r been proposed? Is there any interest in it?<BR><BR>-- Botond and Ehsan<BR=
></DIV>
<DIV dir=3Dltr><BR></DIV></DIV></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_292_780048914.1426761020910--
------=_Part_291_1861190388.1426761020909--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 19 Mar 2015 10:23:11 -0400
Raw View
On 2015-03-18 17:27, Gabriel Dos Reis wrote:
> If it is going in the vtable, why is it a *non-static* data member?
At present, virtual and static are rather orthogonal concepts, i.e. you
*can't have* a virtual static member. In particular, if you have a A*
and you call a static method "on" it, you will always get the member of
A, even if the object is really a B* and B has a same-named member. In
the case that the proposal aims to support, this is NOT the case; you'd
get the member from B.
That said, it seems likely to be useful to be able to access the
constant value without a class instance. However, that's achievable
without the virtual itself being static:
struct A
{
constexpr static auto StaticType = 10;
constexpr virtual type = StaticType;
}
(...and I could argue that this makes for better code style, as it is
explicit when you're using the static value and when you're using the
instance virtual value.)
It's also worth noting that the only practical difference between a
constexpr static and a (proposed) constexpr virtual is that the latter
presumably requires a class instance to access; it's immutable in both
cases.
Incidentally, a proposal should probably note that this is already
partly achievable by having a non-virtual const member on the base class
with a protected ctor that derived classes use to provide their own
value for the same. I can think of at least a couple reasons offhand why
this is an inferior approach compared to the proposal, but I shall leave
enumeration of the same as an exercise for the proposal writer :-).
--
Matthew
--
---
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/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 19 Mar 2015 23:32:33 +0900
Raw View
On Thursday 19 March 2015 13:20:19 David Krauss wrote:
> > On 2015=E2=80=9303=E2=80=9319, at 12:55 PM, Thiago Macieira <thiago@mac=
ieira.org> wrote:
> >=20
> > That's where the constexpr keyword comes into play: you should be able =
to
> > store anything that is a literal type.
> >=20
> > std::string is not a literal type.
>=20
> std::string & works, though.
>=20
> struct s {
> static std::string kind_str;
> static constexpr virtual
> std::string & kind =3D kind_str; // provides read-write access
> };
Sure, it initialises a reference, but it's referencing a type that may not=
=20
have been initialised yet or may have already been destroyed.
> The rules for constexpr references are inconsistent. You can bind them to
> temporaries, provided the temporary is of literal type, but for e.g.
> std::string there must be a named object. Such references aren=E2=80=99t =
always
> even compile-time constants. See also
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#2005 .
> (Unfortunately I didn=E2=80=99t attend the discussion where it was closed=
, and I=E2=80=99m
> not sure the point of the DR submission came across.)
>=20
> Perhaps the strict constexpr requirement can be dropped, but require
> overrides to match in constexpr-ness. Then implementations can add a leve=
l
> of indirection for the non-constant case, essentially automating the abov=
e
> trick.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=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: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 19 Mar 2015 10:46:19 -0400
Raw View
On 2015-03-18 21:30, Nicol Bolas wrote:
> You want these values to be immutable. Once created, their value cannot be
> changed (and const-casting your way around it yields undefined behavior).
> So they're like a const variable.
>
> [...] And more to the point, you want the value returned to be the
> value fetched from the object associated with the object's dynamic
> type. Since a dynamic type is by definition a runtime fetch, it is
> certainly not "constexpr".
Except that a qualified member access *is* constexpr. Also I think the
point is partly an implicit requirement that the compiler is able to
determine the qualified value at compile time (which is necessary of
course to be able to write the constructed value into the vtable). For
similar reasons, such member may not be of a non-constexpr type.
And... on further thought I'm just going to flat out disagree. The
member itself is constexpr. Runtime access of the member on a runtime
instance is not, of course, but if you think about it, that's not really
different from calling a constexpr function at runtime. Doing so does
not make such a function "certainly not constexpr".
On the other hand, if you have a *compile time* instance of a class with
a constexpr virtual data member, I'd expect that to work *at compile
time*... ergo, it is indeed constexpr.
> While the object value is associated with the type, you want to access them
> as though they were a member of an instance of that type.
True, but the compiler should be able to handle this easily; it's very
similar to taking the address of a virtual member function. A virtual
member function is similarly a function associated with the type, but
accessed as though a member of an instance.
> I don't know. This is a whole lot of complexity just to do cheaper RTTI.
> Wouldn't it make more sense to just add cheaper RTTI to C++?
I wouldn't say "just"... while that is *an* obvious use case, I'm not
convinced it is the only one. For example:
class Creature
{
public:
constexpr virtual double base_hp = nullptr;
constexpr virtual double movement_rate = nullptr;
// etc.
}
(Which brings up another point; are pure virtuals allowed? If yes, how
are they declared, considering that '0' may be a legal value? I used
'nullptr' above, but this is another potential bikeshed discussion.)
--
Matthew
--
---
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/.
.
Author: jgottman6@gmail.com
Date: Fri, 20 Mar 2015 18:39:26 -0700 (PDT)
Raw View
------=_Part_1232_861976290.1426901966993
Content-Type: multipart/alternative;
boundary="----=_Part_1233_310823368.1426901966993"
------=_Part_1233_310823368.1426901966993
Content-Type: text/plain; charset=UTF-8
Another, possibly simpler way of achieving the same effect is to weaken the
rule that virtual functions can't be constexpr. If we say that *final *virtual
functions can be final, then we can define Shoe::price as
struct Shoe : Merchandise {
constexpr int price() override final { return 10;
}
This would be perfectly safe, because the compiler could always compute
Shoe::price() without having to look at a vtable.
Joe Gottman
On Wednesday, March 18, 2015 at 4:25:51 PM UTC-4, Botond Ballo wrote:
>
> 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 = 0;
> };
>
> struct Shoe : Merchandise {
> virtual constexpr int price = 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
>
>
--
---
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_1233_310823368.1426901966993
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Another, possibly simpler way of achieving the same effect=
is to weaken the rule that virtual functions can't be constexpr. If =
we say that <i>final </i>virtual functions can be final, then we can define=
Shoe::price as<br><br><div class=3D"prettyprint" style=3D"background-color=
: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid=
; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">struct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Shoe</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">Merchandise</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">constexpr</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> price</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">override</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">final</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pre=
ttify">10</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></=
code></div><br>This would be perfectly safe, because the compiler could alw=
ays compute Shoe::price() without having to look at a vtable.<br><br>Joe Go=
ttman<br><br><br><br>On Wednesday, March 18, 2015 at 4:25:51 PM UTC-4, Boto=
nd Ballo wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><div style=
=3D"color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Ne=
ue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:12px"><div dir=3D"ltr=
">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() { return 0; }<br>};<br><br>str=
uct Shoe : Merchandise {<br> virtual int price() { return=
10;<br>}<br><br>If you could do it this way instead:<br><br>struct Merchan=
dise {<br> virtual constexpr int price =3D 0;<br>};<br><b=
r>struct Shoe : Merchandise {<br> virtual constexpr int p=
rice =3D 10;<br>}<br><br>then the compiler could store the constant value d=
irectly in the vtable. This would eliminate the double indirection involved=
in dereferencing a function vtable entry, the cost of running that functio=
n 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 t=
o be placed in the vtable, like other values in the vtable, can be determin=
ed at compile time.<br><br>Has this, or something similar, ever been propos=
ed? Is there any interest in it?<br><br>-- Botond and Ehsan<br></div><div d=
ir=3D"ltr"><br></div></div></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_1233_310823368.1426901966993--
------=_Part_1232_861976290.1426901966993--
.
Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Sat, 21 Mar 2015 06:34:37 +0000
Raw View
That doesn't fit the bill, as the OP would want to get the value from
a base class pointer/reference.
On 3/21/15, jgottman6@gmail.com <jgottman6@gmail.com> wrote:
> Another, possibly simpler way of achieving the same effect is to weaken the
>
> rule that virtual functions can't be constexpr. If we say that *final
> *virtual
> functions can be final, then we can define Shoe::price as
>
>
> struct Shoe : Merchandise {
> constexpr int price() override final { return 10;
> }
>
> This would be perfectly safe, because the compiler could always compute
> Shoe::price() without having to look at a vtable.
>
> Joe Gottman
>
>
>
> On Wednesday, March 18, 2015 at 4:25:51 PM UTC-4, Botond Ballo wrote:
>>
>> 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 = 0;
>> };
>>
>> struct Shoe : Merchandise {
>> virtual constexpr int price = 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
>>
>>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 21 Mar 2015 14:09:12 -0700
Raw View
On Friday 20 March 2015 18:39:26 jgottman6@gmail.com wrote:
> Another, possibly simpler way of achieving the same effect is to weaken the
> rule that virtual functions can't be constexpr. If we say that *final
> *virtual functions can be final, then we can define Shoe::price as
>
>
> struct Shoe : Merchandise {
> constexpr int price() override final { return 10;
> }
>
> This would be perfectly safe, because the compiler could always compute
> Shoe::price() without having to look at a vtable.
The whole point is that it shouldn't be final.
struct FancyShoe : Shoe {
constexpr int price() override { return 20; }
};
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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/.
.
Author: Myriachan <myriachan@gmail.com>
Date: Mon, 23 Mar 2015 14:30:33 -0700 (PDT)
Raw View
------=_Part_5147_276563614.1427146233529
Content-Type: multipart/alternative;
boundary="----=_Part_5148_142679684.1427146233529"
------=_Part_5148_142679684.1427146233529
Content-Type: text/plain; charset=UTF-8
I've wanted a "static virtual" concept just for convenience reasons to
solve similar problems. The point would just be to avoid having to have a
secondary static function.
enum class Type : int
{
SHOE,
};
struct Merchandise
{
virtual Type GetType() const = 0;
};
struct Shoe : public Merchandise
{
static virtual Type GetType() const override { return Type::SHOE; }
};
Type type1 = Shoe().GetType();
Type type2 = Shoe::GetType();
assert(type1 == type2);
One possible implementation would be to still be a "thiscall" function,
whatever that means to the implementation, but ignoring the "this"
parameter. Shoe::GetType() could then pass nullptr as this. Another
possible implementation is to emit two functions of different mangled
names, one static and one virtual. Either implementation would work fine.
Rules as I imagine them:
1. Destructors can't be static virtual.
2. static virtual functions cannot reference this. (obvious)
3. The static attribute is not heritable: a non-static virtual function may
override a static virtual function.
Possible solutions to the function pointer problem:
4a. It is not possible to get a non-member pointer to a static virtual
function.
--or--
4b. Ampersand-prefixed member pointer expressions (I don't remember their
formal name)--i.e., &Shoe::GetType--would disambiguate member function
pointer and non-member function pointer by context, like occurs for
overloaded functions.
Melissa
--
---
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_5148_142679684.1427146233529
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I've wanted a "static virtual" concept just for convenienc=
e reasons to solve similar problems. The point would just be to avoid=
having to have a secondary static function.<br><br><div class=3D"prettypri=
nt" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 1=
87, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><=
code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">enum</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by=
-prettify">Type</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br> SHOE</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">struct</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pret=
tify">Merchandise</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbs=
p; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
virtual</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #606;" class=3D"styled-by-prettify">Type</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">GetType</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">=
0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" c=
lass=3D"styled-by-prettify">Shoe</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">pub=
lic</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">Merchandise</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">static</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">virtual</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;"=
class=3D"styled-by-prettify">Type</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">GetType</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">const=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">override</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">Type</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">SHOE</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #606;" c=
lass=3D"styled-by-prettify">Type</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> type1 </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">Shoe</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
).</span><span style=3D"color: #606;" class=3D"styled-by-prettify">GetType<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #606;" class=3D"styled-by-prettify">Type</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> type2 </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" c=
lass=3D"styled-by-prettify">Shoe</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">GetType</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
assert</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">type1 </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> type2</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><br=
>One possible implementation would be to still be a "thiscall" function, wh=
atever that means to the implementation, but ignoring the "<span style=3D"f=
ont-family: courier new,monospace;">this</span>" parameter. <span sty=
le=3D"font-family: courier new,monospace;">Shoe::GetType()</span> could the=
n pass <span style=3D"font-family: courier new,monospace;">nullptr</span> a=
s <span style=3D"font-family: courier new,monospace;">this</span>. An=
other possible implementation is to emit two functions of different mangled=
names, one static and one virtual. Either implementation would work =
fine.<br><br>Rules as I imagine them:<br><br>1. Destructors can't be <span =
style=3D"font-family: courier new,monospace;">static virtual</span>.<br>2. =
<span style=3D"font-family: courier new,monospace;">static virtual</span> f=
unctions cannot reference <span style=3D"font-family: courier new,monospace=
;">this</span>. (obvious)<br>3. The <span style=3D"font-family: couri=
er new,monospace;">static</span> attribute is not heritable: a non-<span st=
yle=3D"font-family: courier new,monospace;">static virtual</span> function =
may override a <span style=3D"font-family: courier new,monospace;">static v=
irtual</span> function.<br><br>Possible solutions to the function pointer p=
roblem:<br>4a. It is not possible to get a non-member pointer to a <span st=
yle=3D"font-family: courier new,monospace;">static virtual</span> function.=
<br>--or--<br>4b. Ampersand-prefixed member pointer expressions (I don't re=
member their formal name)--i.e., <span style=3D"font-family: courier new,mo=
nospace;">&Shoe::GetType</span>--would disambiguate member function poi=
nter and non-member function pointer by context, like occurs for overloaded=
functions.<br><br>Melissa<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_5148_142679684.1427146233529--
------=_Part_5147_276563614.1427146233529--
.
Author: "wkaras via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 18 Feb 2016 14:45:59 -0800 (PST)
Raw View
------=_Part_1183_953164628.1455835559555
Content-Type: multipart/alternative;
boundary="----=_Part_1184_195945860.1455835559555"
------=_Part_1184_195945860.1455835559555
Content-Type: text/plain; charset=UTF-8
Is it a viable alternative to just drop the rule that constexpr functions
cannot be virtual, and add a rule that constexpr virtual functions cannot
have parameters? This would permit the compiler to store a constant in the
vtable rather than a function address. Would this cause too many corner
cases for member function pointers?
On Wednesday, March 18, 2015 at 4:25:51 PM UTC-4, Botond Ballo wrote:
>
> 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 = 0;
> };
>
> struct Shoe : Merchandise {
> virtual constexpr int price = 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
>
>
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1184_195945860.1455835559555
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Is it a viable alternative to just drop the rule that cons=
texpr functions cannot be virtual, and add a rule that constexpr virtual fu=
nctions cannot have parameters?=C2=A0 This would permit the compiler to sto=
re a constant in the vtable rather than a function address.=C2=A0 Would thi=
s cause too many corner cases for member function pointers?<br><br>On Wedne=
sday, March 18, 2015 at 4:25:51 PM UTC-4, Botond Ballo wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div><div style=3D"color:#000;background-col=
or:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Gra=
nde,sans-serif;font-size:12px"><div dir=3D"ltr">There are cases where you w=
ould like to associate constants with a given type. Here is how you can cur=
rently do it in C++:<br><br>struct Merchandise {<br>=C2=A0=C2=A0=C2=A0 virt=
ual int price() { return 0; }<br>};<br><br>struct Shoe : Merchandise {<br>=
=C2=A0=C2=A0=C2=A0 virtual int price() { return 10;<br>}<br><br>If you coul=
d do it this way instead:<br><br>struct Merchandise {<br>=C2=A0=C2=A0=C2=A0=
virtual constexpr int price =3D 0;<br>};<br><br>struct Shoe : Merchandise =
{<br>=C2=A0=C2=A0=C2=A0 virtual constexpr int price =3D 10;<br>}<br><br>the=
n 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 s=
ize 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, l=
ike other values in the vtable, can be determined at compile time.<br><br>H=
as this, or something similar, ever been proposed? Is there any interest in=
it?<br><br>-- Botond and Ehsan<br></div><div dir=3D"ltr"><br></div></div><=
/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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_1184_195945860.1455835559555--
------=_Part_1183_953164628.1455835559555--
.
Author: Gabriel Dos Reis <gdr@microsoft.com>
Date: Thu, 18 Feb 2016 23:01:48 +0000
Raw View
--_000_BLUPR03MB117C4211F7CFC95C335784EB0AF0BLUPR03MB117namprd_
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
The real reason I put that restriction in there in the first place was beca=
use people were still not comfortable with the idea that a compiler could r=
un a function at compile-time. So, we wanted to make it as simple and as c=
oncrete as possible =E2=80=93 just to deal with the various FUD being throw=
n around 10 years ago.
The simplest (and correct, IMO) fix is to remove that restriction. We alre=
ady require compilers to track object=E2=80=99s dynamic type when doing con=
stexpr evaluation. Please, don=E2=80=99t replace that restriction with ano=
ther restriction. We=E2=80=99ve learned the value of constexpr for the las=
t 10 years and we are now all conformable with the notion.
I am not expressing opinion about the =E2=80=98virtual fields=E2=80=99 them=
selves (which I must have heard of for the umpteenth time now, since at lea=
st 1995.)
-- Gaby
From: wkaras via ISO C++ Standard - Future Proposals [mailto:std-proposals@=
isocpp.org]
Sent: Thursday, February 18, 2016 2:46 PM
To: ISO C++ Standard - Future Proposals <std-proposals@isocpp.org>
Cc: c++std-ext@accu.org; ehsan@mozilla.com; botond_ballo@yahoo.ca
Subject: [std-proposals] Re: virtual constexpr fields
Is it a viable alternative to just drop the rule that constexpr functions c=
annot be virtual, and add a rule that constexpr virtual functions cannot ha=
ve parameters? This would permit the compiler to store a constant in the v=
table rather than a function address. Would this cause too many corner cas=
es for member function pointers?
On Wednesday, March 18, 2015 at 4:25:51 PM UTC-4, Botond Ballo wrote:
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-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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/<https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fgro=
ups.google.com%2fa%2fisocpp.org%2fgroup%2fstd-proposals%2f&data=3D01%7c01%7=
cgdr%40microsoft.com%7cf12ad7a3c39a41ea803008d338b5484d%7c72f988bf86f141af9=
1ab2d7cd011db47%7c1&sdata=3DcUBS2HF9zEnwjz%2fNE4CeLPPe6pSLhC7s%2bficR5C2l%2=
f4%3d>.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--_000_BLUPR03MB117C4211F7CFC95C335784EB0AF0BLUPR03MB117namprd_
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;}
/* 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;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
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.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
..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-size:11.0pt;font-family:"Ca=
libri",sans-serif">The real reason I put that restriction in there in =
the first place was because people were still not comfortable with the idea=
that a compiler could run a function at compile-time.
So, we wanted to make it as simple and as concrete as possible =E2=80=93 j=
ust to deal with the various FUD being thrown around 10 years ago.<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif">The simplest (and correct, IMO) fix is to remove th=
at restriction. We already require compilers to track object=E2=80=99=
s dynamic type when doing constexpr evaluation. Please, don=E2=80=99t
replace that restriction with another restriction. We=E2=80=99ve lea=
rned the value of constexpr for the last 10 years and we are now all confor=
mable with the notion.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif">I am not expressing opinion about the =E2=80=98virt=
ual fields=E2=80=99 themselves (which I must have heard of for the umpteent=
h time now, since at least 1995.)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif">-- Gaby<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:"Ca=
libri",sans-serif"><o:p> </o:p></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 #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"> wkaras via ISO C++ Sta=
ndard - Future Proposals [mailto:std-proposals@isocpp.org]
<br>
<b>Sent:</b> Thursday, February 18, 2016 2:46 PM<br>
<b>To:</b> ISO C++ Standard - Future Proposals <std-proposals@is=
ocpp.org><br>
<b>Cc:</b> c++std-ext@accu.org; ehsan@mozilla.com; botond_ballo@yah=
oo.ca<br>
<b>Subject:</b> [std-proposals] Re: virtual constexpr fields<o:p></o:p></sp=
an></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<div>
<p class=3D"MsoNormal">Is it a viable alternative to just drop the rule tha=
t constexpr functions cannot be virtual, and add a rule that constexpr virt=
ual functions cannot have parameters? This would permit the compiler =
to store a constant in the vtable rather
than a function address. Would this cause too many corner cases for =
member function pointers?<br>
<br>
On Wednesday, March 18, 2015 at 4:25:51 PM UTC-4, Botond Ballo 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>
<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 c=
ases 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() { 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<o:p></o:p></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"><o:p> =
</o:p></span></p>
</div>
</div>
</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"https://na01.safelinks.protection.outlook.co=
m/?url=3Dhttps%3a%2f%2fgroups.google.com%2fa%2fisocpp.org%2fgroup%2fstd-pro=
posals%2f&data=3D01%7c01%7cgdr%40microsoft.com%7cf12ad7a3c39a41ea803008=
d338b5484d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DcUBS2HF9zEnwj=
z%2fNE4CeLPPe6pSLhC7s%2bficR5C2l%2f4%3d">
https://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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--_000_BLUPR03MB117C4211F7CFC95C335784EB0AF0BLUPR03MB117namprd_--
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 19 Feb 2016 10:59:10 +0800
Raw View
--Apple-Mail=_60260FF3-D7D1-4457-BCF4-2D9597A21F5E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
All, please take care when using reply-all in this thread. It=E2=80=99s get=
ting cross-posted to the internal reflector.
> On 2016=E2=80=9302=E2=80=9319, at 6:45 AM, wkaras via ISO C++ Standard - =
Future Proposals <std-proposals@isocpp.org> wrote:
>=20
> Is it a viable alternative to just drop the rule that constexpr functions=
cannot be virtual, and add a rule that constexpr virtual functions cannot =
have parameters? This would permit the compiler to store a constant in the=
vtable rather than a function address. Would this cause too many corner c=
ases for member function pointers?
The result of that function call would be a prvalue, which is a suboptimal =
way to access the externally-linked object which would implement a virtual =
field.
Also, a constexpr function doesn=E2=80=99t always have to produce a constan=
t. Given a member function, the standard only asks that some input paramete=
r values result in successful constant evaluation, no diagnostic required. =
If it=E2=80=99s a member of a class template, that=E2=80=99s loosened to so=
me combination of template and function parameters.=20
Virtual fields would behave like constexpr objects, not functions.
--=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 https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_60260FF3-D7D1-4457-BCF4-2D9597A21F5E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D"">Al=
l, please take care when using reply-all in this thread. It=E2=80=99s getti=
ng cross-posted to the internal reflector.</div><div class=3D""><br class=
=3D""></div><div class=3D""><br class=3D""></div><div><blockquote type=3D"c=
ite" class=3D""><div class=3D"">On 2016=E2=80=9302=E2=80=9319, at 6:45 AM, =
wkaras via ISO C++ Standard - Future Proposals <<a href=3D"mailto:std-pr=
oposals@isocpp.org" class=3D"">std-proposals@isocpp.org</a>> wrote:</div=
><br class=3D"Apple-interchange-newline"><div class=3D""><span style=3D"fon=
t-family: Helvetica; font-size: 12px; font-style: normal; font-variant: nor=
mal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align=
: start; text-indent: 0px; text-transform: none; white-space: normal; widow=
s: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; di=
splay: inline !important;" class=3D"">Is it a viable alternative to just dr=
op the rule that constexpr functions cannot be virtual, and add a rule that=
constexpr virtual functions cannot have parameters? This would permi=
t the compiler to store a constant in the vtable rather than a function add=
ress. Would this cause too many corner cases for member function poin=
ters?</span><br style=3D"font-family: Helvetica; font-size: 12px; font-styl=
e: normal; font-variant: normal; font-weight: normal; letter-spacing: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px;" class=3D""></div></blockquote></div><br class=3D""><div class=
=3D"">The result of that function call would be a prvalue, which is a subop=
timal way to access the externally-linked object which would implement a vi=
rtual field.</div><div class=3D""><br class=3D""></div><div class=3D"">Also=
, a constexpr function doesn=E2=80=99t always have to produce a constant. G=
iven a member function, the standard only asks that some input parameter va=
lues result in successful constant evaluation, no diagnostic required. If i=
t=E2=80=99s a member of a class template, that=E2=80=99s loosened to some c=
ombination of template and function parameters. </div><div class=3D"">=
<br class=3D""></div><div class=3D"">Virtual fields would behave like const=
expr objects, not functions.</div><div class=3D""><br class=3D""></div></bo=
dy></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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_60260FF3-D7D1-4457-BCF4-2D9597A21F5E--
.
Author: ytqclys@gmail.com
Date: Thu, 18 Feb 2016 22:22:51 -0800 (PST)
Raw View
------=_Part_2105_1342255497.1455862971812
Content-Type: multipart/alternative;
boundary="----=_Part_2106_2030345814.1455862971820"
------=_Part_2106_2030345814.1455862971820
Content-Type: text/plain; charset=UTF-8
A point to perhaps consider is an analogy to virtual base classes. The
classic example is where D inherits from B and C, all of which inherit
virtually from A. But B and C, rather than inheriting virtually from A,
could simply (both) have a virtual member function that returns a pointer
to A. D could override these virtual member functions, returning its this
pointer (implicitly cast to A *). It seems a similar trade off. You
eliminate the need for a somewhat pesky language feature that is not so
frequently used. The price is the overhead of a function call that is not
needed with the pesky feature (plus the bother of having to do overrides of
A member functions in D that could have been done in B or C).
On Wednesday, March 18, 2015 at 4:25:51 PM UTC-4, Botond Ballo wrote:
>
> 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 = 0;
> };
>
> struct Shoe : Merchandise {
> virtual constexpr int price = 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
>
>
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_2106_2030345814.1455862971820
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>A point to perhaps consider is an analogy to virtual b=
ase classes.=C2=A0 The classic example is where D inherits from B and C, al=
l of which inherit virtually from A.=C2=A0 But B and C, rather than inherit=
ing virtually from A, could simply (both) have a virtual member function th=
at returns a pointer to A.=C2=A0 D could override these virtual member func=
tions, returning its this pointer (implicitly cast to A *).=C2=A0 It seems =
a similar trade off.=C2=A0 You eliminate the need for a somewhat pesky lang=
uage feature that is not so frequently used.=C2=A0 The price is the overhea=
d of a function call that is not needed with the pesky feature (plus the bo=
ther of having to do overrides of A member functions in D that could have b=
een done in B or C).<br><br><br>On Wednesday, March 18, 2015 at 4:25:51 PM =
UTC-4, Botond Ballo wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
><div style=3D"color:#000;background-color:#fff;font-family:HelveticaNeue,H=
elvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:12px"><div=
dir=3D"ltr">There are cases where you would like to associate constants wi=
th 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() { return 0; }<br>};=
<br><br>struct Shoe : Merchandise {<br>=C2=A0=C2=A0=C2=A0 virtual int price=
() { return 10;<br>}<br><br>If you could do it this way instead:<br><br>str=
uct Merchandise {<br>=C2=A0=C2=A0=C2=A0 virtual constexpr int price =3D 0;<=
br>};<br><br>struct Shoe : Merchandise {<br>=C2=A0=C2=A0=C2=A0 virtual cons=
texpr int price =3D 10;<br>}<br><br>then the compiler could store the const=
ant value directly in the vtable. This would eliminate the double indirecti=
on involved in dereferencing a function vtable entry, the cost of running t=
hat 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<br><=
/div><div dir=3D"ltr"><br></div></div></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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_2106_2030345814.1455862971820--
------=_Part_2105_1342255497.1455862971812--
.