Topic: Non-polymorphic references
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Tue, 28 Feb 2017 05:53:02 -0800 (PST)
Raw View
------=_Part_1420_1866976180.1488289982091
Content-Type: multipart/alternative;
boundary="----=_Part_1421_1011895376.1488289982092"
------=_Part_1421_1011895376.1488289982092
Content-Type: text/plain; charset=UTF-8
I'd like to discuss the following problem. In C++ reference of type T can
refer to any type derived from T as well as to T itself. It creates some
issues.
1) Suppression of devirtualization.
struct C
{
virtual void f();
};
C c;
c.f(); // the call likely will be devirtualized
f(c);
void f(C &c)
{
c.f(); // the call unlikely will be devirtualized
}
Sometimes we don't need polymorphic behavior, just want to pass the
reference to concrete object (function decomposition).
2) Object slicing.
void f(C &c);
Want only objects of exactly class C to be accepted (no derived) but don't
want to copy the object.
*Possible solution.*
Add new qualifier for references:
C & final cref
Binds only to objects of exactly type C (but not to references).
void f(C & final c)
{
c.f(); // the call can be devirtualized again
}
C c;
f(c); // OK
class D : public C {};
D d;
f(d); // ERROR
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a14b0840-bb47-4bbd-afe5-2237f3ba8f93%40isocpp.org.
------=_Part_1421_1011895376.1488289982092
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'd like to discuss the following problem. In C++ refe=
rence of type T can refer to any type derived from T as well as to T itself=
.. It creates some issues.<br><br>1) Suppression of devirtualization.<br><br=
><div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187,=
187, 187); border-style: solid; border-width: 1px; overflow-wrap: break-wo=
rd;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subpre=
ttyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">struct<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> C<br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">virtual</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" cla=
ss=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-b=
y-prettify"><br><br>C c</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>c</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">f</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #800;" class=3D"styled-by-prettify">// the call likely will be devirtua=
lized</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>f=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">c</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color:=
#008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">C </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">c</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>=C2=A0 =C2=A0 c</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">f</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"s=
tyled-by-prettify">// the call unlikely will be devirtualized</span><span s=
tyle=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></span></div></code></div><br>Som=
etimes we don't need polymorphic behavior, just want to pass the refere=
nce to concrete object (function decomposition).<br><br>2) Object slicing.<=
br><br><code class=3D"prettyprint"><div style=3D"background-color: rgb(250,=
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-w=
idth: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">C </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">c</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></=
div><span style=3D"color: #000;" class=3D"styled-by-prettify"></span></code=
><br>Want only objects of exactly class C to be accepted (no derived) but d=
on't want to copy the object.<br><br><b>Possible solution.</b><br><br>A=
dd new qualifier for references:<br><br><div style=3D"background-color: rgb=
(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bor=
der-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000=
;" class=3D"styled-by-prettify">C </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">final</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> cref<br></span></div></code></div><br>Binds only to objects of exactl=
y type C (but not to references).<br><br><div style=3D"background-color: rg=
b(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bo=
rder-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">C </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">final</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> c</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 c</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">f</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>// the call can be devirtualized again</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"style=
d-by-prettify"><br><br>C c</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>f</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">c</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">// OK</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> D </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">public</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> C </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{};</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>D d</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>f</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">d</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: #800;" class=3D"styled-b=
y-prettify">// ERROR</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span></div></code></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a14b0840-bb47-4bbd-afe5-2237f3ba8f93%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a14b0840-bb47-4bbd-afe5-2237f3ba8f93=
%40isocpp.org</a>.<br />
------=_Part_1421_1011895376.1488289982092--
------=_Part_1420_1866976180.1488289982091--
.
Author: TONGARI J <tongari95@gmail.com>
Date: Tue, 28 Feb 2017 06:28:07 -0800 (PST)
Raw View
------=_Part_8479_1635471607.1488292087918
Content-Type: multipart/alternative;
boundary="----=_Part_8480_1258983516.1488292087918"
------=_Part_8480_1258983516.1488292087918
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 28, 2017 at 9:53:02 PM UTC+8, Victor Dyachenko wrote:
>
> *Possible solution.*
>
> Add new qualifier for references:
>
> C & final cref
>
> Binds only to objects of exactly type C (but not to references).
>
> void f(C & final c)
> {
> c.f(); // the call can be devirtualized again
> }
>
> C c;
> f(c); // OK
>
> class D : public C {};
> D d;
> f(d); // ERROR
>
I see some problems:
- final is a contextual keyword, with your proposed syntax, it's hard to
keep it contextual.
- You should lift the restriction to not accept normal references, e.g:
C& c2 = d;
f(c2); // This should be forbidden
C final& c3 = c; // A final reference
f(c3); // OK
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fa9face1-b95d-4eb1-a12c-71ff37e4a130%40isocpp.org.
------=_Part_8480_1258983516.1488292087918
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 28, 2017 at 9:53:02 PM UTC+8, Victor =
Dyachenko wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><b>Possible solution.</b><br><br>Add new qualifier for references:<br><b=
r><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,=
187);border-style:solid;border-width:1px"><code><div><span style=3D"color:#=
000">C </span><span style=3D"color:#660">&</span><span style=3D"color:#=
000"> </span><span style=3D"color:#008">final</span><span style=3D"color:#0=
00"> cref<br></span></div></code></div><br>Binds only to objects of exactly=
type C (but not to references).<br><br><div style=3D"background-color:rgb(=
250,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:=
1px"><code><div><span style=3D"color:#008">void</span><span style=3D"color:=
#000"> f</span><span style=3D"color:#660">(</span><span style=3D"color:#000=
">C </span><span style=3D"color:#660">&</span><span style=3D"color:#000=
"> </span><span style=3D"color:#008">final</span><span style=3D"color:#000"=
> c</span><span style=3D"color:#660">)</span><span style=3D"color:#000"><br=
></span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=
=C2=A0 =C2=A0 c</span><span style=3D"color:#660">.</span><span style=3D"col=
or:#000">f</span><span style=3D"color:#660">();</span><span style=3D"color:=
#000"> </span><span style=3D"color:#800">// the call can be devirtualized a=
gain</span><span style=3D"color:#000"><br></span><span style=3D"color:#660"=
>}</span><span style=3D"color:#000"><br><br>C c</span><span style=3D"color:=
#660">;</span><span style=3D"color:#000"><br>f</span><span style=3D"color:#=
660">(</span><span style=3D"color:#000">c</span><span style=3D"color:#660">=
);</span><span style=3D"color:#000"> </span><span style=3D"color:#800">// O=
K</span><span style=3D"color:#000"><br><br></span><span style=3D"color:#008=
">class</span><span style=3D"color:#000"> D </span><span style=3D"color:#66=
0">:</span><span style=3D"color:#000"> </span><span style=3D"color:#008">pu=
blic</span><span style=3D"color:#000"> C </span><span style=3D"color:#660">=
{};</span><span style=3D"color:#000"><br>D d</span><span style=3D"color:#66=
0">;</span><span style=3D"color:#000"><br>f</span><span style=3D"color:#660=
">(</span><span style=3D"color:#000">d</span><span style=3D"color:#660">);<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#800">// ERRO=
R</span></div></code></div></div></blockquote><div><br></div><div>I see som=
e problems:</div><div><ul><li><span style=3D"color: rgb(0, 0, 136); font-fa=
mily: monospace; background-color: rgb(250, 250, 250);">final</span>=C2=A0i=
s a contextual keyword, with your proposed syntax, it's hard to keep it=
contextual.<br></li><li>You should lift the restriction to not accept norm=
al references, e.g:<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">C</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">&</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> c2=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> d</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>f</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">c2</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettif=
y">// This should be forbidden</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>C </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">final</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">&</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> c3 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> c</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">// A final </span><span style=3D"=
color: rgb(34, 34, 34); font-family: Arial, Helvetica, sans-serif; backgrou=
nd-color: rgb(255, 255, 255);"><span style=3D"color: #800;" class=3D"styled=
-by-prettify">reference</span></span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>f</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">c3</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #800;" class=3D"styled-by-prettify">// OK</span></div><=
/code></div></li></ul></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fa9face1-b95d-4eb1-a12c-71ff37e4a130%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fa9face1-b95d-4eb1-a12c-71ff37e4a130=
%40isocpp.org</a>.<br />
------=_Part_8480_1258983516.1488292087918--
------=_Part_8479_1635471607.1488292087918--
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Tue, 28 Feb 2017 06:32:08 -0800 (PST)
Raw View
------=_Part_1232_2108627192.1488292328973
Content-Type: multipart/alternative;
boundary="----=_Part_1233_2015328737.1488292328973"
------=_Part_1233_2015328737.1488292328973
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 28, 2017 at 5:28:08 PM UTC+3, TONGARI J wrote:
>
> I see some problems:
>
> - final is a contextual keyword, with your proposed syntax, it's hard
> to keep it contextual.
>
> Notation may be different. I don't mind.
>
> -
> - You should lift the restriction to not accept normal references, e.g:
>
> "Binds only to objects of exactly type C (*but not to references*)"
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/33c9c597-5917-45aa-86e3-dc08f23d024c%40isocpp.org.
------=_Part_1233_2015328737.1488292328973
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 28, 2017 at 5:28:08 PM UTC+3, TONGARI=
J wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I se=
e some problems:<div><ul><li><span style=3D"color:rgb(0,0,136);font-family:=
monospace;background-color:rgb(250,250,250)">final</span>=C2=A0is a context=
ual keyword, with your proposed syntax, it's hard to keep it contextual=
..<br></li></ul></div></div></blockquote><div>=C2=A0Notation may be differen=
t. I don't mind.<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div><ul><li></li><li>You should lift the restriction to n=
ot accept normal references, e.g:<code><div><span style=3D"color:#000"></sp=
an><span style=3D"color:#800"></span></div></code></li></ul></div></div></b=
lockquote><div>"Binds only to objects of exactly type C (<b>but not to=
references</b>)"</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/33c9c597-5917-45aa-86e3-dc08f23d024c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/33c9c597-5917-45aa-86e3-dc08f23d024c=
%40isocpp.org</a>.<br />
------=_Part_1233_2015328737.1488292328973--
------=_Part_1232_2108627192.1488292328973--
.
Author: TONGARI J <tongari95@gmail.com>
Date: Tue, 28 Feb 2017 07:10:27 -0800 (PST)
Raw View
------=_Part_8368_242216741.1488294627226
Content-Type: multipart/alternative;
boundary="----=_Part_8369_200678462.1488294627226"
------=_Part_8369_200678462.1488294627226
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 28, 2017 at 10:32:09 PM UTC+8, Victor Dyachenko wrote:
>
> On Tuesday, February 28, 2017 at 5:28:08 PM UTC+3, TONGARI J wrote:
>>
>>
>> - You should lift the restriction to not accept normal references,
>> e.g:
>>
>> "Binds only to objects of exactly type C (*but not to references*)"
>
Somehow my eyes didn't work correctly :p
Anyway, you should add it to your example.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a54eb456-0b4c-4881-bcf9-d328528896c7%40isocpp.org.
------=_Part_8369_200678462.1488294627226
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 28, 2017 at 10:32:09 PM UTC+8, Victor=
Dyachenko wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Tuesday, February 28, 2017 at 5:28:08 PM UTC+3, TONGARI J wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><ul><li>You should lif=
t the restriction to not accept normal references, e.g:<code><div><span sty=
le=3D"color:#000"></span><span style=3D"color:#800"></span></div></code></l=
i></ul></div></blockquote><div>"Binds only to objects of exactly type =
C (<b>but not to references</b>)"</div></div></blockquote><div><br></d=
iv><div>Somehow my eyes didn't work correctly :p</div><div>Anyway, you =
should add it to your example.=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a54eb456-0b4c-4881-bcf9-d328528896c7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a54eb456-0b4c-4881-bcf9-d328528896c7=
%40isocpp.org</a>.<br />
------=_Part_8369_200678462.1488294627226--
------=_Part_8368_242216741.1488294627226--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 28 Feb 2017 08:00:06 -0800 (PST)
Raw View
------=_Part_8073_621312880.1488297606732
Content-Type: multipart/alternative;
boundary="----=_Part_8074_1707908893.1488297606733"
------=_Part_8074_1707908893.1488297606733
Content-Type: text/plain; charset=UTF-8
If we're going to explore this devirutalization problem, then I think it is
important to be able to explore the full breadth of the problem.
For example, this proposed idea works fine for cases where it is statically
impossible for the type to be the wrong type. But
This is a problem that ought to work just as well for pointers as
references:
auto pc = new C();
f(*pc);
The compiler can clearly see that `pc` has `C` as its dynamic type. Yet
this example isn't supported by your idea (as I understand it).
Also, what about cases where a pointer has to pass a pointer through a
`void*` or an `any`? Such objects have a dynamic type, and the user knows
exactly what that type is (otherwise they couldn't reconstitute it). But
the compiler cannot make that determination?
To deal with all of these cases, we need something stronger. We need to
recognize that pointers and references *equally* want to participate in
this sort of thing, which I will refer to as `exact` rather than `final`.
An `exact` pointer/reference can be converted into a non-`exact`
pointer/reference, but the reverse is not true. And in cases where the
compiler cannot statically detect the `exact`ness of a pointer/reference,
users need the equivalent of a `const_cast` for it.
When you add all of this up, what do you get? A third cv-qualifier. Though
it is a bit backwards from normal cv-qualfiiers. You can freely add `const`
to a pointer/reference, but you cannot remove `const` without an explicit
cast. Here, we need the opposite: we should be able to freely remove
`exact` from a pointer/reference, but you cannot add it back without an
explicit cast. So unlike the others, the qualified version is the more
accepting version rather than the more restricted one.
`new` expressions would return `T exact*`, which would naturally decay to a
`T*`, but could be stored in a `T exact*t` that preserves the fact that it
is exactly what it says. Performing `&` on a variable of type `T` (unless
it overrides it) will return a `T exact*` as well. Variables of type `T`
will preferentially bind to `T exact&` before `T&`, through overload
resolution mechanics. Something similar goes for prvalues. `any_cast`, by
virtue of how it works, should always return `exact` pointers (it doesn't
return references at all).
It would also be good to have `dynamic_cast` be able to safely convert a
pointer/reference to an `exact` pointer/reference, returning
nullptr/throwing if the specified `T exact*/&` is not the dynamic type of
the object.
My biggest concern with such a feature is that it will encourage
proliferation of `exact` qualifications on function parameters, even though
most of them will not even be polymorphic types.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/03a578bb-859a-4f16-8dee-5a87f8f50dc7%40isocpp.org.
------=_Part_8074_1707908893.1488297606733
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">If we're going to explore this devirutalization proble=
m, then I think it is important to be able to explore the full breadth of t=
he problem.<br><br>For example, this proposed idea works fine for cases whe=
re it is statically impossible for the type to be the wrong type. But <br><=
br>This is a problem that ought to work just as well for pointers as refere=
nces:<br><br><div style=3D"background-color: rgb(250, 250, 250); border-col=
or: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wr=
ap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
pc </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">new</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> C</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>f</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(*</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">pc</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span></div></code></div><br>The compiler can clearly see that `pc`=
has `C` as its dynamic type. Yet this example isn't supported by your =
idea (as I understand it).<br><br>Also, what about cases where a pointer ha=
s to pass a pointer through a `void*` or an `any`?=20
Such objects have a dynamic type, and the user knows exactly what that type=
is (otherwise they couldn't reconstitute it). But the compiler
cannot make that determination?<br><br>To deal with all of these cases, we=
need something stronger. We need to recognize that pointers and references=
<i>equally</i> want to participate in this sort of thing, which I will ref=
er to as `exact` rather than `final`. An `exact` pointer/reference can be c=
onverted into a non-`exact` pointer/reference, but the reverse is not true.=
And in cases where the compiler cannot statically detect the `exact`ness o=
f a pointer/reference, users need the equivalent of a `const_cast` for it.<=
br><br>When you add all of this up, what do you get? A third cv-qualifier. =
Though it is a bit backwards from normal cv-qualfiiers. You can freely add =
`const` to a pointer/reference, but you cannot remove `const` without an ex=
plicit cast. Here, we need the opposite: we should be able to freely remove=
`exact` from a pointer/reference, but you cannot add it back without an ex=
plicit cast. So unlike the others, the qualified version is the more accept=
ing version rather than the more restricted one.<br><br>`new` expressions w=
ould return `T exact*`, which would naturally decay to a `T*`, but could be=
stored in a `T exact*t` that preserves the fact that it is exactly what it=
says. Performing `&` on a variable of type `T` (unless it overrides it=
) will return a `T exact*` as well. Variables of type `T` will preferential=
ly bind to `T exact&` before `T&`, through overload resolution mech=
anics. Something similar goes for prvalues. `any_cast`, by virtue of how it=
works, should always return `exact` pointers (it doesn't return refere=
nces at all).<br><br>It would also be good to have `dynamic_cast` be able t=
o safely convert a pointer/reference to an `exact` pointer/reference, retur=
ning nullptr/throwing if the specified `T exact*/&` is not the dynamic =
type of the object.<br><br>My biggest concern with such a feature is that i=
t will encourage proliferation of `exact` qualifications on function parame=
ters, even though most of them will not even be polymorphic types.<br></div=
>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/03a578bb-859a-4f16-8dee-5a87f8f50dc7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/03a578bb-859a-4f16-8dee-5a87f8f50dc7=
%40isocpp.org</a>.<br />
------=_Part_8074_1707908893.1488297606733--
------=_Part_8073_621312880.1488297606732--
.
Author: joseph.thomson@gmail.com
Date: Tue, 28 Feb 2017 08:25:24 -0800 (PST)
Raw View
------=_Part_8415_1923231801.1488299124461
Content-Type: multipart/alternative;
boundary="----=_Part_8416_1722571570.1488299124462"
------=_Part_8416_1722571570.1488299124462
Content-Type: text/plain; charset=UTF-8
>
> `new` expressions would return `T exact*`, which would naturally decay to
> a `T*`, but could be stored in a `T exact*t` that preserves the fact that
> it is exactly what it says. Performing `&` on a variable of type `T`
> (unless it overrides it) will return a `T exact*` as well. Variables of
> type `T` will preferentially bind to `T exact&` before `T&`, through
> overload resolution mechanics. Something similar goes for prvalues.
> `any_cast`, by virtue of how it works, should always return `exact`
> pointers (it doesn't return references at all).
>
> It would also be good to have `dynamic_cast` be able to safely convert a
> pointer/reference to an `exact` pointer/reference, returning
> nullptr/throwing if the specified `T exact*/&` is not the dynamic type of
> the object.
>
Won't this break existing code by messing with type deduction?
Is this really a problem that needs solving? Good class hierarchy design
and appropriate use of `final` should be sufficient to avoid unnecessary
virtual function calls.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2bb44c09-3de3-4efd-baa4-b5cec200be8f%40isocpp.org.
------=_Part_8416_1722571570.1488299124462
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">`new` expressions would return `T exact*`, which would naturally decay =
to a `T*`, but could be stored in a `T exact*t` that preserves the fact tha=
t it is exactly what it says. Performing `&` on a variable of type `T` =
(unless it overrides it) will return a `T exact*` as well. Variables of typ=
e `T` will preferentially bind to `T exact&` before `T&`, through o=
verload resolution mechanics. Something similar goes for prvalues. `any_cas=
t`, by virtue of how it works, should always return `exact` pointers (it do=
esn't return references at all).<br><br>It would also be good to have `=
dynamic_cast` be able to safely convert a pointer/reference to an `exact` p=
ointer/reference, returning nullptr/throwing if the specified `T exact*/&am=
p;` is not the dynamic type of the object.<br></div></blockquote><div><br>W=
on't this break existing code by messing with type deduction?<br><br>Is=
this really a problem that needs solving? Good class hierarchy design and =
appropriate use of `final` should be sufficient to avoid unnecessary virtua=
l function calls.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2bb44c09-3de3-4efd-baa4-b5cec200be8f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2bb44c09-3de3-4efd-baa4-b5cec200be8f=
%40isocpp.org</a>.<br />
------=_Part_8416_1722571570.1488299124462--
------=_Part_8415_1923231801.1488299124461--
.
Author: =?UTF-8?Q?Jonathan_M=c3=bcller?= <jonathanmueller.dev@gmail.com>
Date: Tue, 28 Feb 2017 17:27:44 +0100
Raw View
On 28.02.2017 14:53, Victor Dyachenko wrote:
>
> *Possible solution.*
>
> Add new qualifier for references:
>
> |
> C &finalcref
> |
>
> Binds only to objects of exactly type C (but not to references).
>
> |
> voidf(C &finalc)
> {
> c.f();// the call can be devirtualized again
> }
>
> C c;
> f(c);// OK
>
> classD :publicC {};
> D d;
> f(d);// ERROR
> |
>
Note that this part of the problem can easily be solved with a library=20
feature:
|
template <typename T>
class final_ref
{
public:
final_ref(T& ref);
template <typename U>
final_ref(U&) =3D delete;
=E2=80=A6
};
|
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/95f1af2b-7947-37dd-fef9-4cc4c09a8472%40gmail.com=
..
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Tue, 28 Feb 2017 16:33:04 +0000
Raw View
--f403045e6484af33a7054999c0ba
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Feb 28, 2017 at 5:27 PM Jonathan M=C3=BCller <
jonathanmueller.dev@gmail.com> wrote:
> On 28.02.2017 14:53, Victor Dyachenko wrote:
> >
> > *Possible solution.*
> >
> > Add new qualifier for references:
> >
> > |
> > C &finalcref
> > |
> >
> > Binds only to objects of exactly type C (but not to references).
> >
> > |
> > voidf(C &finalc)
> > {
> > c.f();// the call can be devirtualized again
> > }
> >
> > C c;
> > f(c);// OK
> >
> > classD :publicC {};
> > D d;
> > f(d);// ERROR
> > |
> >
>
> Note that this part of the problem can easily be solved with a library
> feature:
>
> |
> template <typename T>
> class final_ref
> {
> public:
> final_ref(T& ref);
>
> template <typename U>
> final_ref(U&) =3D delete;
>
> =E2=80=A6
> };
> |
>
This also doesn't work for the case of `f(*pointer_to_foo)`.
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/95f1af2b-794=
7-37dd-fef9-4cc4c09a8472%40gmail.com
> .
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAPCFJdRLrgTZudkaw-vaDET7BOvvfUq2Sa-jjyoRi7NUxLg=
ADQ%40mail.gmail.com.
--f403045e6484af33a7054999c0ba
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Feb 28=
, 2017 at 5:27 PM Jonathan M=C3=BCller <<a href=3D"mailto:jonathanmuelle=
r.dev@gmail.com">jonathanmueller.dev@gmail.com</a>> wrote:<br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">On 28.02.2017 14:53, Victor Dyachenko wrote:<br =
class=3D"gmail_msg">
><br class=3D"gmail_msg">
> *Possible solution.*<br class=3D"gmail_msg">
><br class=3D"gmail_msg">
> Add new qualifier for references:<br class=3D"gmail_msg">
><br class=3D"gmail_msg">
> |<br class=3D"gmail_msg">
> C &finalcref<br class=3D"gmail_msg">
> |<br class=3D"gmail_msg">
><br class=3D"gmail_msg">
> Binds only to objects of exactly type C (but not to references).<br cl=
ass=3D"gmail_msg">
><br class=3D"gmail_msg">
> |<br class=3D"gmail_msg">
> voidf(C &finalc)<br class=3D"gmail_msg">
> {<br class=3D"gmail_msg">
>=C2=A0 =C2=A0 =C2=A0c.f();// the call can be devirtualized again<br cla=
ss=3D"gmail_msg">
> }<br class=3D"gmail_msg">
><br class=3D"gmail_msg">
> C c;<br class=3D"gmail_msg">
> f(c);// OK<br class=3D"gmail_msg">
><br class=3D"gmail_msg">
> classD :publicC {};<br class=3D"gmail_msg">
> D d;<br class=3D"gmail_msg">
> f(d);// ERROR<br class=3D"gmail_msg">
> |<br class=3D"gmail_msg">
><br class=3D"gmail_msg">
<br class=3D"gmail_msg">
Note that this part of the problem can easily be solved with a library<br c=
lass=3D"gmail_msg">
feature:<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
|<br class=3D"gmail_msg">
template <typename T><br class=3D"gmail_msg">
class final_ref<br class=3D"gmail_msg">
{<br class=3D"gmail_msg">
public:<br class=3D"gmail_msg">
=C2=A0 =C2=A0 =C2=A0final_ref(T& ref);<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
=C2=A0 =C2=A0 =C2=A0template <typename U><br class=3D"gmail_msg">
=C2=A0 =C2=A0 =C2=A0final_ref(U&) =3D delete;<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
=C2=A0 =C2=A0 =C2=A0=E2=80=A6<br class=3D"gmail_msg">
};<br class=3D"gmail_msg">
|<br class=3D"gmail_msg"></blockquote><div><br></div><div>This also doesn&#=
39;t work for the case of `f(*pointer_to_foo)`.</div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">
--<br class=3D"gmail_msg">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br class=3D"gmail_msg=
">
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" class=3D"=
gmail_msg" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br c=
lass=3D"gmail_msg">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"gmail_msg" target=3D"_blank">std-proposals@isocpp.org</a>.<b=
r class=3D"gmail_msg">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/95f1af2b-7947-37dd-fef9-4cc4c09a8472%=
40gmail.com" rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https=
://groups.google.com/a/isocpp.org/d/msgid/std-proposals/95f1af2b-7947-37dd-=
fef9-4cc4c09a8472%40gmail.com</a>.<br class=3D"gmail_msg">
</blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdRLrgTZudkaw-vaDET7BOvvfUq2Sa-j=
jyoRi7NUxLgADQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdRLrgTZudka=
w-vaDET7BOvvfUq2Sa-jjyoRi7NUxLgADQ%40mail.gmail.com</a>.<br />
--f403045e6484af33a7054999c0ba--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 28 Feb 2017 08:34:18 -0800 (PST)
Raw View
------=_Part_8890_77199204.1488299658531
Content-Type: multipart/alternative;
boundary="----=_Part_8891_1149865188.1488299658531"
------=_Part_8891_1149865188.1488299658531
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 28, 2017 at 11:25:24 AM UTC-5, joseph....@gmail.com
wrote:
>
> `new` expressions would return `T exact*`, which would naturally decay to
>> a `T*`, but could be stored in a `T exact*t` that preserves the fact that
>> it is exactly what it says. Performing `&` on a variable of type `T`
>> (unless it overrides it) will return a `T exact*` as well. Variables of
>> type `T` will preferentially bind to `T exact&` before `T&`, through
>> overload resolution mechanics. Something similar goes for prvalues.
>> `any_cast`, by virtue of how it works, should always return `exact`
>> pointers (it doesn't return references at all).
>>
>> It would also be good to have `dynamic_cast` be able to safely convert a
>> pointer/reference to an `exact` pointer/reference, returning
>> nullptr/throwing if the specified `T exact*/&` is not the dynamic type of
>> the object.
>>
>
> Won't this break existing code by messing with type deduction?
>
I don't know; would it?
It seems to me that, so long as `T exact */&` can be used in exactly the
same places as `T */&`, what would it matter if a template deduces
something as a `T exact &` instead of a `T&`?
Is this really a problem that needs solving? Good class hierarchy design
> and appropriate use of `final` should be sufficient to avoid unnecessary
> virtual function calls.
>
I'm just going along with the OP's idea. I'm not really sure what the use
cases are for this sort of thing. I mean yes, the OP showed an example, but
does it happen often enough that it really needs a language feature?
Also, the complexity I'm suggesting that gets added to the OP's simple idea
is actually rather necessary. Not just to handle pointers, but to handle
things like forwarding. After all, if I pass an exact reference to a
function that takes a `T&&`, then clearly the exact-ness of that reference
needs to be preserved. And it can only do that if it's a first-class part
of the type system, such that templates deduce an exact reference when you
provide one. Just as templates deduce a `const` reference when you provide
one.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5954effd-4c8d-4473-bb0a-1f4abb8d2d1b%40isocpp.org.
------=_Part_8891_1149865188.1488299658531
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 28, 2017 at 11:25:24 AM UTC-5, joseph=
.....@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">`new` exp=
ressions would return `T exact*`, which would naturally decay to a `T*`, bu=
t could be stored in a `T exact*t` that preserves the fact that it is exact=
ly what it says. Performing `&` on a variable of type `T` (unless it ov=
errides it) will return a `T exact*` as well. Variables of type `T` will pr=
eferentially bind to `T exact&` before `T&`, through overload resol=
ution mechanics. Something similar goes for prvalues. `any_cast`, by virtue=
of how it works, should always return `exact` pointers (it doesn't ret=
urn references at all).<br><br>It would also be good to have `dynamic_cast`=
be able to safely convert a pointer/reference to an `exact` pointer/refere=
nce, returning nullptr/throwing if the specified `T exact*/&` is not th=
e dynamic type of the object.<br></div></blockquote><div><br>Won't this=
break existing code by messing with type deduction?<br></div></div></block=
quote><div><br>I don't know; would it?<br><br>It seems to me that, so l=
ong as `T exact */&` can be used in exactly the same places as `T */&am=
p;`, what would it matter if a template deduces something as a `T exact &am=
p;` instead of a `T&`?<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div>Is this really a problem that needs solving=
? Good class hierarchy design and appropriate use of `final` should be suff=
icient to avoid unnecessary virtual function calls.<br></div></div></blockq=
uote><div><br>I'm just going along with the OP's idea. I'm not =
really sure what the use cases are for this sort of thing. I mean yes, the =
OP showed an example, but does it happen often enough that it really needs =
a language feature?<br><br>Also, the complexity I'm suggesting that get=
s added to the OP's simple idea is actually rather necessary. Not just =
to handle pointers, but to handle things like forwarding. After all, if I p=
ass an exact reference to a function that takes a `T&&`, then clear=
ly the exact-ness of that reference needs to be preserved. And it can only =
do that if it's a first-class part of the type system, such that templa=
tes deduce an exact reference when you provide one. Just as templates deduc=
e a `const` reference when you provide one.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5954effd-4c8d-4473-bb0a-1f4abb8d2d1b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5954effd-4c8d-4473-bb0a-1f4abb8d2d1b=
%40isocpp.org</a>.<br />
------=_Part_8891_1149865188.1488299658531--
------=_Part_8890_77199204.1488299658531--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 28 Feb 2017 08:42:00 -0800 (PST)
Raw View
------=_Part_6842_1370199443.1488300120429
Content-Type: multipart/alternative;
boundary="----=_Part_6843_1572441839.1488300120429"
------=_Part_6843_1572441839.1488300120429
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, February 28, 2017 at 11:27:50 AM UTC-5, Jonathan M=C3=BCller wr=
ote:
>
> On 28.02.2017 14:53, Victor Dyachenko wrote:=20
> >=20
> > *Possible solution.*=20
> >=20
> > Add new qualifier for references:=20
> >=20
> > |=20
> > C &finalcref=20
> > |=20
> >=20
> > Binds only to objects of exactly type C (but not to references).=20
> >=20
> > |=20
> > voidf(C &finalc)=20
> > {=20
> > c.f();// the call can be devirtualized again=20
> > }=20
> >=20
> > C c;=20
> > f(c);// OK=20
> >=20
> > classD :publicC {};=20
> > D d;=20
> > f(d);// ERROR=20
> > |=20
> >=20
>
> Note that this part of the problem can easily be solved with a library=20
> feature:=20
>
The goal of this idea is to enforce devirtualization, and adding a=20
user-defined type (or even a standard library type) won't *enforce*=20
devirtualization. Even if you make it a standard library type, it cannot=20
enforce anything, because this is still legal C++:
D d;
final_ref<C> rt(static_cast<C&>(d));
The compiler cannot assume that the pointer/reference stored in `final_ref`=
=20
is of the dynamic type `T`. And without that assumption, the compiler=20
cannot devirtualize anything.
I suppose, as a standard library type, you could declare by fiat that the=
=20
compiler shall assume that its `operator->` and `operator*` overloads shall=
=20
return a pointer/reference to an object who's dynamic type is `T`. And that=
=20
if the dynamic type of the `T&` you provide to the constructor is not `T`=
=20
itself, then UB results. But that would be exceedingly strange behavior for=
=20
a standard library type.
It also puts everything into runtime checks, rather than compile-time=20
assurances.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/29a71583-0100-41d5-823d-3aa9f753b5fe%40isocpp.or=
g.
------=_Part_6843_1572441839.1488300120429
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 28, 2017 at 11:27:50 AM UTC-5, Jonath=
an M=C3=BCller wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 28.02.=
2017 14:53, Victor Dyachenko wrote:
<br>>
<br>> *Possible solution.*
<br>>
<br>> Add new qualifier for references:
<br>>
<br>> |
<br>> C &finalcref
<br>> |
<br>>
<br>> Binds only to objects of exactly type C (but not to references).
<br>>
<br>> |
<br>> voidf(C &finalc)
<br>> {
<br>> =C2=A0 =C2=A0 c.f();// the call can be devirtualized again
<br>> }
<br>>
<br>> C c;
<br>> f(c);// OK
<br>>
<br>> classD :publicC {};
<br>> D d;
<br>> f(d);// ERROR
<br>> |
<br>>
<br>
<br>Note that this part of the problem can easily be solved with a library=
=20
<br>feature:
<br></blockquote><div><br>The goal of this idea is to enforce devirtualizat=
ion, and adding a user-defined type (or even a standard library type) won&#=
39;t <i>enforce</i> devirtualization. Even if you make it a standard librar=
y type, it cannot enforce anything, because this is still legal C++:<br><br=
><div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187,=
187, 187); border-style: solid; border-width: 1px; overflow-wrap: break-wo=
rd;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subpre=
ttyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">D d</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>final_ref</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">C</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> rt</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">static_cast</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify">C</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&>(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">));</=
span></div></code></div><br>The compiler cannot assume that the pointer/ref=
erence stored in `final_ref` is of the dynamic type `T`. And without that a=
ssumption, the compiler cannot devirtualize anything.<br><br>I suppose, as =
a standard library type, you could declare by fiat that the compiler shall =
assume that its `operator->` and `operator*` overloads shall return a po=
inter/reference to an object who's dynamic type is `T`. And that if the=
dynamic type of the `T&` you provide to the constructor is not `T` its=
elf, then UB results. But that would be exceedingly strange behavior for a =
standard library type.<br><br>It also puts everything into runtime checks, =
rather than compile-time assurances.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/29a71583-0100-41d5-823d-3aa9f753b5fe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/29a71583-0100-41d5-823d-3aa9f753b5fe=
%40isocpp.org</a>.<br />
------=_Part_6843_1572441839.1488300120429--
------=_Part_6842_1370199443.1488300120429--
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Tue, 28 Feb 2017 11:04:47 -0800 (PST)
Raw View
------=_Part_1542_1945264792.1488308687589
Content-Type: multipart/alternative;
boundary="----=_Part_1543_1131157915.1488308687589"
------=_Part_1543_1131157915.1488308687589
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, February 28, 2017 at 7:27:50 PM UTC+3, Jonathan M=C3=BCller wro=
te:
>
> On 28.02.2017 14:53, Victor Dyachenko wrote:=20
> >=20
> > *Possible solution.*=20
> >=20
> > Add new qualifier for references:=20
> >=20
> > |=20
> > C &finalcref=20
> > |=20
> >=20
> > Binds only to objects of exactly type C (but not to references).=20
> >=20
> > |=20
> > voidf(C &finalc)=20
> > {=20
> > c.f();// the call can be devirtualized again=20
> > }=20
> >=20
> > C c;=20
> > f(c);// OK=20
> >=20
> > classD :publicC {};=20
> > D d;=20
> > f(d);// ERROR=20
> > |=20
> >=20
>
> Note that this part of the problem can easily be solved with a library=20
> feature:=20
>
> |=20
> template <typename T>=20
> class final_ref=20
> {=20
> public:=20
> final_ref(T& ref);=20
>
> template <typename U>=20
> final_ref(U&) =3D delete;=20
>
> =E2=80=A6=20
> };=20
> |=20
>
And how does it solve the problem with virtual calls?
C c;
final_ref<C> r(c);
r.f(); // can virtual call be avoided here? how?
It even doesn't solve slicing problem (in non-trivial scenario):
D d;
C &cr =3D d; // OK
final_ref<C> r(cr); // Ooops
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/04352c8a-a55e-410a-812a-7dc35044d3d9%40isocpp.or=
g.
------=_Part_1543_1131157915.1488308687589
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 28, 2017 at 7:27:50 PM UTC+3, Jonatha=
n M=C3=BCller wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 28.02.2=
017 14:53, Victor Dyachenko wrote:
<br>>
<br>> *Possible solution.*
<br>>
<br>> Add new qualifier for references:
<br>>
<br>> |
<br>> C &finalcref
<br>> |
<br>>
<br>> Binds only to objects of exactly type C (but not to references).
<br>>
<br>> |
<br>> voidf(C &finalc)
<br>> {
<br>> =C2=A0 =C2=A0 c.f();// the call can be devirtualized again
<br>> }
<br>>
<br>> C c;
<br>> f(c);// OK
<br>>
<br>> classD :publicC {};
<br>> D d;
<br>> f(d);// ERROR
<br>> |
<br>>
<br>
<br>Note that this part of the problem can easily be solved with a library=
=20
<br>feature:
<br>
<br>|
<br>template <typename T>
<br>class final_ref
<br>{
<br>public:
<br>=C2=A0 =C2=A0 =C2=A0final_ref(T& ref);
<br>
<br>=C2=A0 =C2=A0 =C2=A0template <typename U>
<br>=C2=A0 =C2=A0 =C2=A0final_ref(U&) =3D delete;
<br>
<br>=C2=A0 =C2=A0 =C2=A0=E2=80=A6
<br>};
<br>|
<br></blockquote><div><br>And how does it solve the problem with virtual ca=
lls?<br><br><div style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wra=
p: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">C c</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>final_re=
f</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">C</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> r</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify">c</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br>r</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">f=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #800;" class=3D"styled-by-prettify">// can virtual call be avo=
ided here? how?</span></div></code></div><br>It even doesn't solve slic=
ing problem (in non-trivial scenario):<br><br><div style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #000;" class=3D"styled-by-prettify">D d</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>C </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">cr </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">// OK</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>final_ref</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">C</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">></span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> r</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">cr</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: #800;" class=3D"styled-by-prettify">// Ooops</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></di=
v></code></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/04352c8a-a55e-410a-812a-7dc35044d3d9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/04352c8a-a55e-410a-812a-7dc35044d3d9=
%40isocpp.org</a>.<br />
------=_Part_1543_1131157915.1488308687589--
------=_Part_1542_1945264792.1488308687589--
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Tue, 28 Feb 2017 11:17:47 -0800 (PST)
Raw View
------=_Part_1378_1300666020.1488309467365
Content-Type: multipart/alternative;
boundary="----=_Part_1379_116155888.1488309467365"
------=_Part_1379_116155888.1488309467365
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 28, 2017 at 7:00:07 PM UTC+3, Nicol Bolas wrote:
To deal with all of these cases, we need something stronger. We need to
> recognize that pointers and references *equally* want to participate in
> this sort of thing, which I will refer to as `exact` rather than `final`.
>
Agree, it may be more precise terminology. But C++ tries hard to avoid
introducing new keywords. The notation may be changed (may be even without
introducing any words). I want to discuss the behaviour in the first place.
> An `exact` pointer/reference can be converted into a non-`exact`
> pointer/reference, but the reverse is not true. And in cases where the
> compiler cannot statically detect the `exact`ness of a pointer/reference,
> users need the equivalent of a `const_cast` for it.
>
Sure, some mechanism like const_cast is required to be able to tell the
compiler "I promise, this can be done safely".
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0e67af41-5d1c-4ec1-83e3-615758919f4b%40isocpp.org.
------=_Part_1379_116155888.1488309467365
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 28, 2017 at 7:00:07 PM UTC+3, Nicol B=
olas wrote:<br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">To deal with all of these cases, we need something stronger. We need =
to recognize that pointers and references <i>equally</i> want to participat=
e in this sort of thing, which I will refer to as `exact` rather than `fina=
l`.</div></blockquote><div><br>Agree, it may be more precise terminology. B=
ut C++ tries hard to avoid introducing new keywords. The notation may be ch=
anged (may be even without introducing any words). I want to discuss the be=
haviour=C2=A0 in the first place.<br>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"> An `exact` pointer/reference can be co=
nverted into a non-`exact` pointer/reference, but the reverse is not true. =
And in cases where the compiler cannot statically detect the `exact`ness of=
a pointer/reference, users need the equivalent of a `const_cast` for it.<b=
r></div></blockquote><div><br>Sure, some mechanism like const_cast is requi=
red to be able to tell the compiler "I promise, this can be done safel=
y".<br><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0e67af41-5d1c-4ec1-83e3-615758919f4b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0e67af41-5d1c-4ec1-83e3-615758919f4b=
%40isocpp.org</a>.<br />
------=_Part_1379_116155888.1488309467365--
------=_Part_1378_1300666020.1488309467365--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 28 Feb 2017 11:57:40 -0800
Raw View
Em ter=C3=A7a-feira, 28 de fevereiro de 2017, =C3=A0s 05:53:02 PST, Victor =
Dyachenko=20
escreveu:
> I'd like to discuss the following problem. In C++ reference of type T can
> refer to any type derived from T as well as to T itself. It creates some
> issues.
In my opinion, non-issues.
> 1) Suppression of devirtualization.
>=20
> struct C
> {
> virtual void f();
> };
>=20
> C c;
> c.f(); // the call likely will be devirtualized
> f(c);
>=20
> void f(C &c)
> {
> c.f(); // the call unlikely will be devirtualized
> }
>=20
> Sometimes we don't need polymorphic behavior, just want to pass the
> reference to concrete object (function decomposition).
If this function f *knows* beyond the shadow of a doubt that it doesn't nee=
d=20
the virtual call, you can write;
c.C::f();
This work with templates too:
template <typename T>
void f(const T &t)
{
t.T::f();
}
> 2) Object slicing.
>=20
> void f(C &c);
>=20
> Want only objects of exactly class C to be accepted (no derived) but don'=
t
> want to copy the object.
Why? Can you give a use-case that doesn't involve copying?
Even for copying, I'd consider it a non-issue since a polymorphic class not=
be=20
sliced should have deleted its copy operators.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2462499.QvxHIfltpP%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 28 Feb 2017 12:21:47 -0800 (PST)
Raw View
------=_Part_8778_762163078.1488313307155
Content-Type: multipart/alternative;
boundary="----=_Part_8779_1907537659.1488313307155"
------=_Part_8779_1907537659.1488313307155
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, February 28, 2017 at 2:57:46 PM UTC-5, Thiago Macieira wrote:
>
> Em ter=C3=A7a-feira, 28 de fevereiro de 2017, =C3=A0s 05:53:02 PST, Victo=
r Dyachenko=20
> escreveu:=20
> > I'd like to discuss the following problem. In C++ reference of type T=
=20
> can=20
> > refer to any type derived from T as well as to T itself. It creates som=
e=20
> > issues.=20
>
> In my opinion, non-issues.=20
>
> > 1) Suppression of devirtualization.=20
> >=20
> > struct C=20
> > {=20
> > virtual void f();=20
> > };=20
> >=20
> > C c;=20
> > c.f(); // the call likely will be devirtualized=20
> > f(c);=20
> >=20
> > void f(C &c)=20
> > {=20
> > c.f(); // the call unlikely will be devirtualized=20
> > }=20
> >=20
> > Sometimes we don't need polymorphic behavior, just want to pass the=20
> > reference to concrete object (function decomposition).=20
>
> If this function f *knows* beyond the shadow of a doubt that it doesn't=
=20
> need=20
> the virtual call, you can write;=20
>
> c.C::f();=20
>
>
I think a big part of the point of the feature is to explicitly *prevent*=
=20
you from calling it with the wrong type. Admittedly, I'm not sure precisely=
=20
why that's necessary, but it does have the side benefit of making it so=20
that you don't have to write a lot of redundant `Typename::` before all of=
=20
your function calls if you want to devirtualize them.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/92a40e8d-a2b1-482a-9a91-ec18804ebb94%40isocpp.or=
g.
------=_Part_8779_1907537659.1488313307155
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 28, 2017 at 2:57:46 PM UTC-5, Thiago =
Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em ter=C3=A7a-f=
eira, 28 de fevereiro de 2017, =C3=A0s 05:53:02 PST, Victor Dyachenko=20
<br>escreveu:
<br>> I'd like to discuss the following problem. In C++ reference of=
type T can
<br>> refer to any type derived from T as well as to T itself. It create=
s some
<br>> issues.
<br>
<br>In my opinion, non-issues.
<br>
<br>> 1) Suppression of devirtualization.
<br>>=20
<br>> struct C
<br>> {
<br>> =C2=A0 =C2=A0 virtual void f();
<br>> };
<br>>=20
<br>> C c;
<br>> c.f(); // the call likely will be devirtualized
<br>> f(c);
<br>>=20
<br>> void f(C &c)
<br>> {
<br>> =C2=A0 =C2=A0 c.f(); // the call unlikely will be devirtualized
<br>> }
<br>>=20
<br>> Sometimes we don't need polymorphic behavior, just want to pas=
s the
<br>> reference to concrete object (function decomposition).
<br>
<br>If this function f *knows* beyond the shadow of a doubt that it doesn&#=
39;t need=20
<br>the virtual call, you can write;
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0c.C::f();
<br>
<br></blockquote><div><br>I think a big part of the point of the feature is=
to explicitly <i>prevent</i> you from calling it with the wrong type. Admi=
ttedly, I'm not sure precisely why that's necessary, but it does ha=
ve the side benefit of making it so that you don't have to write a lot =
of redundant `Typename::` before all of your function calls if you want to =
devirtualize them.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/92a40e8d-a2b1-482a-9a91-ec18804ebb94%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/92a40e8d-a2b1-482a-9a91-ec18804ebb94=
%40isocpp.org</a>.<br />
------=_Part_8779_1907537659.1488313307155--
------=_Part_8778_762163078.1488313307155--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Tue, 28 Feb 2017 16:38:27 -0800 (PST)
Raw View
------=_Part_7689_1908467636.1488328707910
Content-Type: multipart/alternative;
boundary="----=_Part_7690_428266847.1488328707911"
------=_Part_7690_428266847.1488328707911
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, February 28, 2017 at 5:53:02 AM UTC-8, Victor Dyachenko wrote:
>
> I'd like to discuss the following problem. In C++ reference of type T can=
=20
> refer to any type derived from T as well as to T itself. It creates some=
=20
> issues.
>
> 1) Suppression of devirtualization.
>
> struct C
> {
> virtual void f();
> };
>
> C c;
> c.f(); // the call likely will be devirtualized
> f(c);
>
> void f(C &c)
> {
> c.f(); // the call unlikely will be devirtualized
> }
>
> Sometimes we don't need polymorphic behavior, just want to pass the=20
> reference to concrete object (function decomposition).
>
> 2) Object slicing.
>
> void f(C &c);
>
> Want only objects of exactly class C to be accepted (no derived) but don'=
t=20
> want to copy the object.
>
I imagine solving this via a tag template similar to not_null<T>; let's=20
call it not_polymorphic<C>.
The idea is that you're willing to take the hit of a runtime check the=20
first time you put a value into the "not_null" or "not_polymorphic" system;=
=20
but then once it's in there, you can pass it around and access its value=20
without needing to repeat the runtime check, because you're guaranteed that=
=20
in order for one of these objects to exist, the original creator *must*=20
have checked for "nullness" or "polymorphicness" already.
#include <typeinfo>
#define ASSUME(condition) do { if (!(condition)) __builtin_unreachable(); }=
=20
while (0)
#define ASSUME_DYNAMIC_TYPE(obj, type) ASSUME(typeid(obj) =3D=3D typeid(typ=
e))
template<class C>
class not_polymorphic {
C *ptr;
public:
explicit not_polymorphic(C& c) : ptr(&c) { assert(typeid(c) =3D=3D=20
typeid(C)); }
C& get() const { ASSUME_DYNAMIC_TYPE(*ptr, C); return *ptr; }
operator C& () const { ASSUME_DYNAMIC_TYPE(*ptr, C); return *ptr; }
};
Then all that is required is that your compiler of choice be smart enough=
=20
to devirtualize calls when the typeid of the object is known ahead of time.
It appears to me that Clang is not yet this smart, and I assume GCC isn't=
=20
either; but if this idiom became common, they might start supporting it.
This is basically Nicol's "exact type qualifier" idea from a few posts=20
down, except that I'm doing it within the existing type system. The=20
explicit constructor above is the equivalent of Nicol's "something like=20
const_cast", and the implicit conversion operator is the equivalent of=20
Nicol's implicit conversion from T exact& to T&.
Personally, I just don't use polymorphism. Unhelpful, I know. ;)
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a0c75108-dbb4-4b33-a718-19c98ef500ec%40isocpp.or=
g.
------=_Part_7690_428266847.1488328707911
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 28, 2017 at 5:53:02 AM UTC-8, Victor =
Dyachenko wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">I'd like to discuss the following problem. In C++ reference of type =
T can refer to any type derived from T as well as to T itself. It creates s=
ome issues.<br><br>1) Suppression of devirtualization.<br><br><div style=3D=
"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-sty=
le:solid;border-width:1px"><code><div><span style=3D"color:#008">struct</sp=
an><span style=3D"color:#000"> C<br></span><span style=3D"color:#660">{</sp=
an><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color=
:#008">virtual</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#008">void</span><span style=3D"color:#000"> f</span><span style=3D"color=
:#660">();</span><span style=3D"color:#000"><br></span><span style=3D"color=
:#660">};</span><span style=3D"color:#000"><br><br>C c</span><span style=3D=
"color:#660">;</span><span style=3D"color:#000"><br>c</span><span style=3D"=
color:#660">.</span><span style=3D"color:#000">f</span><span style=3D"color=
:#660">();</span><span style=3D"color:#000"> </span><span style=3D"color:#8=
00">// the call likely will be devirtualized</span><span style=3D"color:#00=
0"><br>f</span><span style=3D"color:#660">(</span><span style=3D"color:#000=
">c</span><span style=3D"color:#660">);</span><span style=3D"color:#000"><b=
r><br></span><span style=3D"color:#008">void</span><span style=3D"color:#00=
0"> f</span><span style=3D"color:#660">(</span><span style=3D"color:#000">C=
</span><span style=3D"color:#660">&</span><span style=3D"color:#000">c=
</span><span style=3D"color:#660">)</span><span style=3D"color:#000"><br></=
span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=
=A0 =C2=A0 c</span><span style=3D"color:#660">.</span><span style=3D"color:=
#000">f</span><span style=3D"color:#660">();</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#800">// the call unlikely will be devirtua=
lized</span><span style=3D"color:#000"><br></span><span style=3D"color:#660=
">}</span><span style=3D"color:#000"><br></span></div></code></div><br>Some=
times we don't need polymorphic behavior, just want to pass the referen=
ce to concrete object (function decomposition).<br><br>2) Object slicing.<b=
r><br><code><div style=3D"background-color:rgb(250,250,250);border-color:rg=
b(187,187,187);border-style:solid;border-width:1px"><code><div><span style=
=3D"color:#008">void</span><span style=3D"color:#000"> f</span><span style=
=3D"color:#660">(</span><span style=3D"color:#000">C </span><span style=3D"=
color:#660">&</span><span style=3D"color:#000">c</span><span style=3D"c=
olor:#660">);</span><span style=3D"color:#000"><br></span></div></code></di=
v><span style=3D"color:#000"></span></code><br>Want only objects of exactly=
class C to be accepted (no derived) but don't want to copy the object.=
<br></div></blockquote><div><br></div><div>I imagine solving this via a tag=
template similar to not_null<T>; let's call it not_polymorphic&l=
t;C>.</div><div>The idea is that you're willing to take the hit of a=
runtime check the first time you put a value into the "not_null"=
or "not_polymorphic" system; but then once it's in there, yo=
u can pass it around and access its value without needing to repeat the run=
time check, because you're guaranteed that in order for one of these ob=
jects to exist, the original creator <i>must</i> have checked for "nul=
lness" or "polymorphicness" already.</div><div><br></div><di=
v><font face=3D"courier new, monospace">#include <typeinfo></font></d=
iv><div><font face=3D"courier new, monospace"><br></font></div><div><font f=
ace=3D"courier new, monospace">#define ASSUME(condition) do { if (!(conditi=
on)) __builtin_unreachable(); } while (0)</font></div><div><font face=3D"co=
urier new, monospace">#define ASSUME_DYNAMIC_TYPE(obj, type) ASSUME(typeid(=
obj) =3D=3D typeid(type))</font></div><div><font face=3D"courier new, monos=
pace"><br></font></div><div><font face=3D"courier new, monospace">template&=
lt;class C></font></div><div><font face=3D"courier new, monospace">class=
not_polymorphic {</font></div><div><font face=3D"courier new, monospace">=
=C2=A0 =C2=A0 C *ptr;</font></div><div><font face=3D"courier new, monospace=
">=C2=A0 public:</font></div><div><font face=3D"courier new, monospace">=C2=
=A0 =C2=A0 explicit not_polymorphic(C& c) : ptr(&c) { assert(typeid=
(c) =3D=3D typeid(C)); }</font></div><div><font face=3D"courier new, monosp=
ace">=C2=A0 =C2=A0 C& get() const { ASSUME_DYNAMIC_TYPE(*ptr, C); retur=
n *ptr; }</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=
=A0 operator C& () const { ASSUME_DYNAMIC_TYPE(*ptr, C); return *ptr; }=
</font></div><div><font face=3D"courier new, monospace">};<br></font></div>=
<div><br></div><div>Then all that is required is that your compiler of choi=
ce be smart enough to devirtualize calls when the typeid of the object is k=
nown ahead of time.</div><div>It appears to me that Clang is not yet this s=
mart, and I assume GCC isn't either; but if this idiom became common, t=
hey might start supporting it.</div><div><br></div><div>This is basically N=
icol's "<font face=3D"courier new, monospace">exact</font> type qu=
alifier" idea from a few posts down, except that I'm doing it with=
in the existing type system. The explicit constructor above is the equivale=
nt of Nicol's "something like <font face=3D"courier new, monospace=
">const_cast</font>", and the implicit conversion operator is the equi=
valent of Nicol's implicit conversion from <font face=3D"courier new, m=
onospace">T exact&</font> to <font face=3D"courier new, monospace">T&am=
p;</font>.</div><div><br></div><div>Personally, I just don't use polymo=
rphism. Unhelpful, I know. ;)</div><div><br></div><div>=E2=80=93Arthur</div=
></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a0c75108-dbb4-4b33-a718-19c98ef500ec%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a0c75108-dbb4-4b33-a718-19c98ef500ec=
%40isocpp.org</a>.<br />
------=_Part_7690_428266847.1488328707911--
------=_Part_7689_1908467636.1488328707910--
.
Author: Joseph Thomson <joseph.thomson@gmail.com>
Date: Wed, 1 Mar 2017 09:37:55 +0800
Raw View
--001a11c159dca3a29c0549a15c2b
Content-Type: text/plain; charset=UTF-8
On Wed, Mar 1, 2017 at 12:34 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> On Tuesday, February 28, 2017 at 11:25:24 AM UTC-5, joseph....@gmail.com
> wrote:
>>
>> `new` expressions would return `T exact*`, which would naturally decay to
>>> a `T*`, but could be stored in a `T exact*t` that preserves the fact that
>>> it is exactly what it says. Performing `&` on a variable of type `T`
>>> (unless it overrides it) will return a `T exact*` as well. Variables of
>>> type `T` will preferentially bind to `T exact&` before `T&`, through
>>> overload resolution mechanics. Something similar goes for prvalues.
>>> `any_cast`, by virtue of how it works, should always return `exact`
>>> pointers (it doesn't return references at all).
>>>
>>> It would also be good to have `dynamic_cast` be able to safely convert a
>>> pointer/reference to an `exact` pointer/reference, returning
>>> nullptr/throwing if the specified `T exact*/&` is not the dynamic type of
>>> the object.
>>>
>>
>> Won't this break existing code by messing with type deduction?
>>
>
> I don't know; would it?
>
> It seems to me that, so long as `T exact */&` can be used in exactly the
> same places as `T */&`, what would it matter if a template deduces
> something as a `T exact &` instead of a `T&`?
>
Well, `is_same_v<decltype(new T), T*>` will become false, unless `is_same`
were to recursively ignore the `exact` qualifier, in which case in what
sense is it a part of the type system?
Actually, that raises a question. What does it mean to be of type `T
exact`? Does the `exact` qualifier only apply to references and pointers?
p.s. Sorry Nicol, I originally forgot to "Reply to all".
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHocnE8CotNV7rtKNe9Ugfy7niJBmgF_vCA4d4a%3DgeNHE933_Q%40mail.gmail.com.
--001a11c159dca3a29c0549a15c2b
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 1, 2017 at 12:34 AM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div d=
ir=3D"ltr"><span class=3D"gmail-">On Tuesday, February 28, 2017 at 11:25:24=
AM UTC-5, <a href=3D"mailto:joseph....@gmail.com" target=3D"_blank">joseph=
.....@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr">`new` expressions would return `T exact*`, which would naturally d=
ecay to a `T*`, but could be stored in a `T exact*t` that preserves the fac=
t that it is exactly what it says. Performing `&` on a variable of type=
`T` (unless it overrides it) will return a `T exact*` as well. Variables o=
f type `T` will preferentially bind to `T exact&` before `T&`, thro=
ugh overload resolution mechanics. Something similar goes for prvalues. `an=
y_cast`, by virtue of how it works, should always return `exact` pointers (=
it doesn't return references at all).<br><br>It would also be good to h=
ave `dynamic_cast` be able to safely convert a pointer/reference to an `exa=
ct` pointer/reference, returning nullptr/throwing if the specified `T exact=
*/&` is not the dynamic type of the object.<br></div></blockquote><div>=
<br>Won't this break existing code by messing with type deduction?<br><=
/div></div></blockquote></span><div><br>I don't know; would it?<br><br>=
It seems to me that, so long as `T exact */&` can be used in exactly th=
e same places as `T */&`, what would it matter if a template deduces so=
mething as a `T exact &` instead of a `T&`?<br></div></div></blockq=
uote><div><br><div dir=3D"auto">Well, `is_same_v<decltype(new T), T*>=
` will become
false, unless `is_same` were to recursively ignore the `exact`=20
qualifier, in which case in what sense is it a part of the type system?</di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">Actually,
that raises a question. What does it mean to be of type `T exact`? Does
the `exact` qualifier only apply to references and pointers?<br><br></div>=
<div>p.s. Sorry Nicol, I originally forgot to "Reply to all".<br>=
</div></div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHocnE8CotNV7rtKNe9Ugfy7niJBmgF_vCA4=
d4a%3DgeNHE933_Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHocnE8CotNV7r=
tKNe9Ugfy7niJBmgF_vCA4d4a%3DgeNHE933_Q%40mail.gmail.com</a>.<br />
--001a11c159dca3a29c0549a15c2b--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Wed, 1 Mar 2017 07:25:35 +0100
Raw View
On Tue, Feb 28, 2017 at 08:34:18AM -0800, Nicol Bolas wrote:
> On Tuesday, February 28, 2017 at 11:25:24 AM UTC-5, joseph....@gmail.com
> wrote:
> >
> > `new` expressions would return `T exact*`, which would naturally decay to
> >> a `T*`, but could be stored in a `T exact*t` that preserves the fact that
> >> it is exactly what it says. Performing `&` on a variable of type `T`
> >> (unless it overrides it) will return a `T exact*` as well. Variables of
> >> type `T` will preferentially bind to `T exact&` before `T&`, through
> >> overload resolution mechanics. Something similar goes for prvalues.
> >> `any_cast`, by virtue of how it works, should always return `exact`
> >> pointers (it doesn't return references at all).
> >>
> >> It would also be good to have `dynamic_cast` be able to safely convert a
> >> pointer/reference to an `exact` pointer/reference, returning
> >> nullptr/throwing if the specified `T exact*/&` is not the dynamic type of
> >> the object.
> >>
> >
> > Won't this break existing code by messing with type deduction?
> >
>
> I don't know; would it?
>
> It seems to me that, so long as `T exact */&` can be used in exactly the
> same places as `T */&`, what would it matter if a template deduces
> something as a `T exact &` instead of a `T&`?
What would happen if there is a (partial) specialization for T&?
/MF
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20170301062535.GA2212%40noemi.
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Wed, 1 Mar 2017 00:00:49 -0800 (PST)
Raw View
------=_Part_1486_315344153.1488355249178
Content-Type: multipart/alternative;
boundary="----=_Part_1487_833515048.1488355249178"
------=_Part_1487_833515048.1488355249178
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 28, 2017 at 10:57:46 PM UTC+3, Thiago Macieira wrote:
>
> Why? Can you give a use-case that doesn't involve copying?
>
When I need to decompose my function ("Extract Function"). I don't want to
copy all my big complex objects every time.
And see P0221R0: Proposed wording for default comparisons, revision 2
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0221r0.html>
about slicing problems.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/275a5de3-567c-4895-9a7f-00774039bc9c%40isocpp.org.
------=_Part_1487_833515048.1488355249178
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 28, 2017 at 10:57:46 PM UTC+3, Thiago=
Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Why? Can you g=
ive a use-case that doesn't involve copying?
<br></blockquote><div>=C2=A0<br>When I need to decompose my function ("=
;<span style=3D"color: rgb(37, 37, 37); font-family: sans-serif; font-size:=
14px; font-style: normal; font-variant-ligatures: normal; font-variant-cap=
s: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-al=
ign: left; text-indent: 0px; text-transform: none; white-space: normal; wid=
ows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color=
: rgb(255, 255, 255); display: inline !important; float: none;">Extract Fun=
ction</span>"). I don't want to copy all my big complex objects ev=
ery time.<br><br>And see <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/=
docs/papers/2016/p0221r0.html">P0221R0: Proposed wording for default compar=
isons, revision 2</a> about slicing problems.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/275a5de3-567c-4895-9a7f-00774039bc9c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/275a5de3-567c-4895-9a7f-00774039bc9c=
%40isocpp.org</a>.<br />
------=_Part_1487_833515048.1488355249178--
------=_Part_1486_315344153.1488355249178--
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Wed, 1 Mar 2017 00:07:46 -0800 (PST)
Raw View
------=_Part_1429_586011001.1488355666129
Content-Type: multipart/alternative;
boundary="----=_Part_1430_1944204097.1488355666129"
------=_Part_1430_1944204097.1488355666129
Content-Type: text/plain; charset=UTF-8
On Wednesday, March 1, 2017 at 11:00:49 AM UTC+3, Victor Dyachenko wrote:
>
> On Tuesday, February 28, 2017 at 10:57:46 PM UTC+3, Thiago Macieira wrote:
>>
>> Why? Can you give a use-case that doesn't involve copying?
>>
>
> When I need to decompose my function ("Extract Function"). I don't want
> to copy all my big complex objects every time.
>
JavaLikeTreeMap map; // derived from AbstractMap
size_t n = 0;
for(auto &en : map) n++; // working with concrete class
size_t count(const JavaLikeTreeMap &map)
{
size_t n = 0;
for(auto &en : map) n++; // looks same but it can be any derived class
also
return n;
}
And I cannot use copy at all if my object needs to be modified by the
function (non-const reference)
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/914f6e21-d47f-4c7b-87d2-a751b6cf5093%40isocpp.org.
------=_Part_1430_1944204097.1488355666129
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, March 1, 2017 at 11:00:49 AM UTC+3, Victor D=
yachenko wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">On Tuesday, February 28, 2017 at 10:57:46 PM UTC+3, Thiago Macieira wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">Why? Can you give a use-case that =
doesn't involve copying?
<br></blockquote><div>=C2=A0<br>When I need to decompose my function ("=
;<span style=3D"color:rgb(37,37,37);font-family:sans-serif;font-size:14px;f=
ont-style:normal;font-weight:normal;letter-spacing:normal;text-align:left;t=
ext-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;back=
ground-color:rgb(255,255,255);display:inline!important;float:none">Extract =
Function</span>"). I don't want to copy all my big complex objects=
every time.<br></div></div></blockquote><div><br><div style=3D"background-=
color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: =
solid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"=
><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">JavaLikeTreeMap</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> map</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// derived from AbstractMap</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br><br>size_t n </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </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"style=
d-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">for</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</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 styl=
e=3D"color: #000;" class=3D"styled-by-prettify">en </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> map</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> n</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">++;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// work=
ing with concrete class</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br><br>size_t count</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">const</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>JavaLikeTreeMap</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&am=
p;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">map</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span s=
tyle=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>=C2=A0 =C2=A0 size_t n </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #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>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">for</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&</span><span style=3D"color: #000;" class=3D"styled-by-prettify">en </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> map</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> n</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: #800;" class=3D"style=
d-by-prettify">// looks same but it can be any derived class also</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> n</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span></div></code></div><br>And I cannot use =
copy at all if my object needs to be modified by the function (non-const re=
ference)<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/914f6e21-d47f-4c7b-87d2-a751b6cf5093%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/914f6e21-d47f-4c7b-87d2-a751b6cf5093=
%40isocpp.org</a>.<br />
------=_Part_1430_1944204097.1488355666129--
------=_Part_1429_586011001.1488355666129--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Wed, 1 Mar 2017 11:49:07 -0800
Raw View
--94eb2c05f4561633b30549b09b81
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Mar 1, 2017 at 12:07 AM, Victor Dyachenko <
victor.dyachenko@gmail.com> wrote:
> JavaLikeTreeMap map; // derived from AbstractMap
>
> size_t n =3D 0;
> for(auto &en : map) n++; // working with concrete class
>
> size_t count(const JavaLikeTreeMap &map)
> {
> size_t n =3D 0;
> for(auto &en : map) n++; // looks same but it can be any derived
> class also
> return n;
> }
>
I think the problem here is that you're working against the type system.
Since JavaLikeTreeMap is polymorphic, this function obeys all the usual OOP
principles, such as the Liskov Substitution Principle; so the signature of
this function expresses the idea that you can "count" the elements of any
object that *IS-A* JavaLikeTreeMap.
I suppose this is a decent argument for the "final" qualifier on methods
(if you use a lot of polymorphism in speed-critical sections, which I still
think is a bad idea, honestly). Qualifying JavaLikeTreeMap::begin() and
JavaLikeTreeMap::end() as "final" will solve your problem while remaining
within the type system.
The way "final" affects things is by saying: "I, Victor, promise to you,
the compiler, that if some object O *IS-A* JavaLikeTreeMap, then its
begin() method acts 100% like *this*, and its end() method acts 100% like
*this*." So the compiler becomes free to inline those methods.
Now, you might still claim there's a problem. What if
JavaLikeTreeMap::begin() cannot be made "final", because you actually *do*
want to create a child class
class JavaLikeTreeMapWithKnobsOn : JavaLikeTreeMap
{
auto begin() const override;
auto end() const override;
};
JavaLikeTreeMapWithKnobsOn jltmwko;
? Well, in that case, you've just created an object jltmwko which *IS-A*
JavaLikeTreeMap according to the type system, but whose elements cannot be
counted using your (devirtualized, inlined, non-polymorphic) "count"
function. So you've broken the Liskov substitution rule, so IMO you
shouldn't expect the compiler to help you out at all.
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0%2BrEr62XsYu1mp0vBdODUYsEXS8aLYrrjaGOP64i=
tZzmg%40mail.gmail.com.
--94eb2c05f4561633b30549b09b81
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Mar 1, 2017 at 12:07 AM, Victor Dyachenko <span di=
r=3D"ltr"><<a href=3D"mailto:victor.dyachenko@gmail.com" target=3D"_blan=
k">victor.dyachenko@gmail.com</a>></span> wrote:<div class=3D"gmail_extr=
a"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div s=
tyle=3D"background-color:rgb(250,250,250);border:1px solid rgb(187,187,187)=
" class=3D"gmail-m_-7987822998875410142prettyprint"><code class=3D"gmail-m_=
-7987822998875410142prettyprint"><div class=3D"gmail-m_-7987822998875410142=
subprettyprint"><span style=3D"color:rgb(102,0,102)" class=3D"gmail-m_-7987=
822998875410142styled-by-prettify">JavaLikeTreeMap</span><span style=3D"col=
or:rgb(0,0,0)" class=3D"gmail-m_-7987822998875410142styled-by-prettify"> ma=
p</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-798782299887=
5410142styled-by-prettify">;</span><span style=3D"color:rgb(0,0,0)" class=
=3D"gmail-m_-7987822998875410142styled-by-prettify"> </span><span style=3D"=
color:rgb(136,0,0)" class=3D"gmail-m_-7987822998875410142styled-by-prettify=
">// derived from AbstractMap</span><span style=3D"color:rgb(0,0,0)" class=
=3D"gmail-m_-7987822998875410142styled-by-prettify"><br><br>size_t n </span=
><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7987822998875410142=
styled-by-prettify">=3D</span><span style=3D"color:rgb(0,0,0)" class=3D"gma=
il-m_-7987822998875410142styled-by-prettify"> </span><span style=3D"color:r=
gb(0,102,102)" class=3D"gmail-m_-7987822998875410142styled-by-prettify">0</=
span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-798782299887541=
0142styled-by-prettify">;</span><span style=3D"color:rgb(0,0,0)" class=3D"g=
mail-m_-7987822998875410142styled-by-prettify"><br></span><span style=3D"co=
lor:rgb(0,0,136)" class=3D"gmail-m_-7987822998875410142styled-by-prettify">=
for</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7987822998=
875410142styled-by-prettify">(</span><span style=3D"color:rgb(0,0,136)" cla=
ss=3D"gmail-m_-7987822998875410142styled-by-prettify">auto</span><span styl=
e=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7987822998875410142styled-by-prett=
ify"> </span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7987822=
998875410142styled-by-prettify">&</span><span style=3D"color:rgb(0,0,0)=
" class=3D"gmail-m_-7987822998875410142styled-by-prettify">en </span><span =
style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7987822998875410142styled-=
by-prettify">:</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-798=
7822998875410142styled-by-prettify"> map</span><span style=3D"color:rgb(102=
,102,0)" class=3D"gmail-m_-7987822998875410142styled-by-prettify">)</span><=
span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7987822998875410142styled=
-by-prettify"> n</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-=
m_-7987822998875410142styled-by-prettify">++;</span><span style=3D"color:rg=
b(0,0,0)" class=3D"gmail-m_-7987822998875410142styled-by-prettify"> </span>=
<span style=3D"color:rgb(136,0,0)" class=3D"gmail-m_-7987822998875410142sty=
led-by-prettify">// working with concrete class</span><span style=3D"color:=
rgb(0,0,0)" class=3D"gmail-m_-7987822998875410142styled-by-prettify"><br><b=
r>size_t count</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_=
-7987822998875410142styled-by-prettify">(</span><span style=3D"color:rgb(0,=
0,136)" class=3D"gmail-m_-7987822998875410142styled-by-prettify">const</spa=
n><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7987822998875410142sty=
led-by-prettify"> </span><span style=3D"color:rgb(102,0,102)" class=3D"gmai=
l-m_-7987822998875410142styled-by-prettify">JavaLikeTreeMap</span><span sty=
le=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7987822998875410142styled-by-pret=
tify"> </span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-798782=
2998875410142styled-by-prettify">&</span><span style=3D"color:rgb(0,0,0=
)" class=3D"gmail-m_-7987822998875410142styled-by-prettify">map</span><span=
style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7987822998875410142styled=
-by-prettify">)</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-79=
87822998875410142styled-by-prettify"><br></span><span style=3D"color:rgb(10=
2,102,0)" class=3D"gmail-m_-7987822998875410142styled-by-prettify">{</span>=
<span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7987822998875410142style=
d-by-prettify"><br>=C2=A0 =C2=A0 size_t n </span><span style=3D"color:rgb(1=
02,102,0)" class=3D"gmail-m_-7987822998875410142styled-by-prettify">=3D</sp=
an><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7987822998875410142st=
yled-by-prettify"> </span><span style=3D"color:rgb(0,102,102)" class=3D"gma=
il-m_-7987822998875410142styled-by-prettify">0</span><span style=3D"color:r=
gb(102,102,0)" class=3D"gmail-m_-7987822998875410142styled-by-prettify">;</=
span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7987822998875410142=
styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,1=
36)" class=3D"gmail-m_-7987822998875410142styled-by-prettify">for</span><sp=
an style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7987822998875410142styl=
ed-by-prettify">(</span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m=
_-7987822998875410142styled-by-prettify">auto</span><span style=3D"color:rg=
b(0,0,0)" class=3D"gmail-m_-7987822998875410142styled-by-prettify"> </span>=
<span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7987822998875410142s=
tyled-by-prettify">&</span><span style=3D"color:rgb(0,0,0)" class=3D"gm=
ail-m_-7987822998875410142styled-by-prettify">en </span><span style=3D"colo=
r:rgb(102,102,0)" class=3D"gmail-m_-7987822998875410142styled-by-prettify">=
:</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7987822998875410=
142styled-by-prettify"> map</span><span style=3D"color:rgb(102,102,0)" clas=
s=3D"gmail-m_-7987822998875410142styled-by-prettify">)</span><span style=3D=
"color:rgb(0,0,0)" class=3D"gmail-m_-7987822998875410142styled-by-prettify"=
> n</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7987822998=
875410142styled-by-prettify">++;</span><span style=3D"color:rgb(0,0,0)" cla=
ss=3D"gmail-m_-7987822998875410142styled-by-prettify"> </span><span style=
=3D"color:rgb(136,0,0)" class=3D"gmail-m_-7987822998875410142styled-by-pret=
tify">// looks same but it can be any derived class also</span><span style=
=3D"color:rgb(0,0,0)" class=3D"gmail-m_-7987822998875410142styled-by-pretti=
fy"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)" class=3D"gm=
ail-m_-7987822998875410142styled-by-prettify">return</span><span style=3D"c=
olor:rgb(0,0,0)" class=3D"gmail-m_-7987822998875410142styled-by-prettify"> =
n</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-798782299887=
5410142styled-by-prettify">;</span><span style=3D"color:rgb(0,0,0)" class=
=3D"gmail-m_-7987822998875410142styled-by-prettify"><br></span><span style=
=3D"color:rgb(102,102,0)" class=3D"gmail-m_-7987822998875410142styled-by-pr=
ettify">}</span></div></code></div></div></div></blockquote><div><br></div>=
<div>I think the problem here is that you're working against the type s=
ystem. Since JavaLikeTreeMap is polymorphic, this function obeys all the us=
ual OOP principles, such as the Liskov Substitution Principle; so the signa=
ture of this function expresses the idea that you can "count" the=
elements of any object that <b>IS-A</b> JavaLikeTreeMap.</div><div><br></d=
iv><div>I suppose this is a decent argument for the "final" quali=
fier on methods (if you use a lot of polymorphism in speed-critical section=
s, which I still think is a bad idea, honestly). Qualifying JavaLikeTreeMap=
::begin() and JavaLikeTreeMap::end() as "final" will solve your p=
roblem while remaining within the type system.</div><div><br></div><div>The=
way "final" affects things is by saying: "I, Victor, promis=
e to you, the compiler, that if some object O <b>IS-A</b> JavaLikeTreeMap, =
then its begin() method acts 100% like <i>this</i>, and its end() method ac=
ts 100% like <i>this</i>." So the compiler becomes free to inline thos=
e methods.</div><div><br></div><div>Now, you might still claim there's =
a problem. What if JavaLikeTreeMap::begin() cannot be made "final"=
;, because you actually <i>do</i> want to create a child class</div><div><b=
r></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 class JavaLi=
keTreeMapWithKnobsOn : JavaLikeTreeMap</font></div><div><font face=3D"monos=
pace, monospace">=C2=A0 =C2=A0 {</font></div><div><font face=3D"monospace, =
monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 auto begin() const override;</font><=
/div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 a=
uto end() const override;</font></div><div><font face=3D"monospace, monospa=
ce">=C2=A0 =C2=A0 };</font></div><div><font face=3D"monospace, monospace">=
=C2=A0 =C2=A0 JavaLikeTreeMapWithKnobsOn jltmwko;</font></div><div><br></di=
v><div>? Well, in that case, you've just created an object <font face=
=3D"monospace, monospace">jltmwko</font>=C2=A0which <b>IS-A</b> JavaLikeTre=
eMap according to the type system, but whose elements cannot be counted usi=
ng your (devirtualized, inlined, non-polymorphic) "count" functio=
n. So you've broken the Liskov substitution rule, so IMO you shouldn=
9;t expect the compiler to help you out at all.</div><div><br></div><div>=
=E2=80=93Arthur</div></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BrEr62XsYu1mp0vBdODUYsEXS8aL=
YrrjaGOP64itZzmg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BrEr62=
XsYu1mp0vBdODUYsEXS8aLYrrjaGOP64itZzmg%40mail.gmail.com</a>.<br />
--94eb2c05f4561633b30549b09b81--
.
Author: Anthony Hall <anthrond@gmail.com>
Date: Wed, 1 Mar 2017 13:13:45 -0800 (PST)
Raw View
------=_Part_3451_911860342.1488402825385
Content-Type: multipart/alternative;
boundary="----=_Part_3452_138263722.1488402825385"
------=_Part_3452_138263722.1488402825385
Content-Type: text/plain; charset=UTF-8
In a similar spirit to Arthur's not_polymorphic<> tag type idea: at least
as far as the efficiency goals of enabling de-virtualization in more
contexts than compilers would ordinarily be able to, this sounds like one
of the poster child use cases for custom attributes: an optimization hint
to the compiler, where otherwise identical functionality would result.
Part of the contract with the compiler could be that, given the right
flags, the compiler would agree to return warnings or errors, so that the
desirable compile-time checks could be given. The syntax of attributes
might be a little bit ugly or unwieldy, in the position of cv-qualifiers
(and I'm not sure off-hand: do the current positioning rules for custom
attributes allow for cv-qualifier-like use?). But I wonder if it could
afford all the benefits desired, without having to bikeshed a new keyword
or syntax for it, and without having to wait for standardization, so long
as compilers are willing to recognize it.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/05c474b6-b2e6-4b4f-817b-e3e0bf376a75%40isocpp.org.
------=_Part_3452_138263722.1488402825385
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">In a similar spirit to Arthur's not_polymorphic<>=
; tag type idea: at least as far as the efficiency goals of enabling de-vir=
tualization in more contexts than compilers would ordinarily be able to, th=
is sounds like one of the poster child use cases for custom attributes: an =
optimization hint to the compiler, where otherwise identical functionality =
would result. =C2=A0Part of the contract with the compiler could be that, g=
iven the right flags, the compiler would agree to return warnings or errors=
, so that the desirable compile-time checks could be given. =C2=A0The synta=
x of attributes might be a little bit ugly or unwieldy, in the position of =
cv-qualifiers (and I'm not sure off-hand: do the current positioning ru=
les for custom attributes allow for cv-qualifier-like use?). =C2=A0But I wo=
nder if it could afford all the benefits desired, without having to bikeshe=
d a new keyword or syntax for it, and without having to wait for standardiz=
ation, so long as compilers are willing to recognize it.</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/05c474b6-b2e6-4b4f-817b-e3e0bf376a75%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/05c474b6-b2e6-4b4f-817b-e3e0bf376a75=
%40isocpp.org</a>.<br />
------=_Part_3452_138263722.1488402825385--
------=_Part_3451_911860342.1488402825385--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 01 Mar 2017 22:51:09 -0800
Raw View
Em quarta-feira, 1 de mar=C3=A7o de 2017, =C3=A0s 00:07:46 PST, Victor Dyac=
henko=20
escreveu:
> JavaLikeTreeMap map; // derived from AbstractMap
>=20
> size_t n =3D 0;
> for(auto &en : map) n++; // working with concrete class
>=20
> size_t count(const JavaLikeTreeMap &map)
> {
> size_t n =3D 0;
> for(auto &en : map) n++; // looks same but it can be any derived clas=
s
> also
> return n;
> }
I know what it does. I am asking why you would want such a function *not* t=
o=20
work for derived classes. That is not explained.
> And I cannot use copy at all if my object needs to be modified by the
> function (non-const reference)
If your object is copyable (not virtual-clone()able) , it shouldn't be=20
polymorphic. That's an API design problem, so in my opinion, a non-issue.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1670901.uVbOiP7HMe%40tjmaciei-mobl1.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 01 Mar 2017 22:52:11 -0800
Raw View
Em quarta-feira, 1 de mar=C3=A7o de 2017, =C3=A0s 00:00:49 PST, Victor Dyac=
henko=20
escreveu:
> When I need to decompose my function ("Extract Function"). I don't want t=
o
> copy all my big complex objects every time.
Explain what you mean by that. The only thing that comes to mind in "extrac=
t=20
function" is reading the virtual table to get the actual function pointer, =
as=20
opposed to a PMF that goes again through the virtual table. That is not=20
permitted in C++.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1678418.S6FTfJ8TCE%40tjmaciei-mobl1.
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Wed, 1 Mar 2017 23:04:50 -0800 (PST)
Raw View
------=_Part_39_2011252982.1488438291002
Content-Type: multipart/alternative;
boundary="----=_Part_40_1283513208.1488438291002"
------=_Part_40_1283513208.1488438291002
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, March 2, 2017 at 9:52:15 AM UTC+3, Thiago Macieira wrote:
>
> Em quarta-feira, 1 de mar=C3=A7o de 2017, =C3=A0s 00:00:49 PST, Victor Dy=
achenko=20
> escreveu:=20
> > When I need to decompose my function ("Extract Function"). I don't want=
=20
> to=20
> > copy all my big complex objects every time.=20
>
> Explain what you mean by that. The only thing that comes to mind in=20
> "extract=20
> function" is reading the virtual table to get the actual function pointer=
,=20
> as=20
> opposed to a PMF that goes again through the virtual table. That is not=
=20
> permitted in C++.=20
>
I mean function decomposition. Parts of a big function (chunks of code)=20
become functions itself.
I know what it does. I am asking why you would want such a function *not*=
=20
> to=20
> work for derived classes. That is not explained.=20
>
Generated code. It will be more efficient.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/dc477e71-0aa3-401f-b9d4-f3c7dfb86f5f%40isocpp.or=
g.
------=_Part_40_1283513208.1488438291002
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, March 2, 2017 at 9:52:15 AM UTC+3, Thiago Mac=
ieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Em quarta-feira, 1=
de mar=C3=A7o de 2017, =C3=A0s 00:00:49 PST, Victor Dyachenko=20
<br>escreveu:
<br>> When I need to decompose my function ("Extract Function"=
). I don't want to
<br>> copy all my big complex objects every time.
<br>
<br>Explain what you mean by that. The only thing that comes to mind in &qu=
ot;extract=20
<br>function" is reading the virtual table to get the actual function =
pointer, as=20
<br>opposed to a PMF that goes again through the virtual table. That is not=
=20
<br>permitted in C++.
<br></blockquote><div>I mean function decomposition. Parts of a big functio=
n (chunks of code) become functions itself.<br><br><blockquote class=3D"gma=
il_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(20=
4, 204, 204); padding-left: 1ex;">I know what it does. I am asking why you =
would want such a function *not* to=20
<br>work for derived classes. That is not explained.
<br></blockquote>Generated code. It will be more efficient.<br>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dc477e71-0aa3-401f-b9d4-f3c7dfb86f5f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dc477e71-0aa3-401f-b9d4-f3c7dfb86f5f=
%40isocpp.org</a>.<br />
------=_Part_40_1283513208.1488438291002--
------=_Part_39_2011252982.1488438291002--
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Wed, 1 Mar 2017 23:16:23 -0800 (PST)
Raw View
------=_Part_60_2134817565.1488438983591
Content-Type: multipart/alternative;
boundary="----=_Part_61_842912744.1488438983591"
------=_Part_61_842912744.1488438983591
Content-Type: text/plain; charset=UTF-8
On Wednesday, March 1, 2017 at 10:49:11 PM UTC+3, Arthur O'Dwyer wrote:
>
> On Wed, Mar 1, 2017 at 12:07 AM, Victor Dyachenko <victor.d...@gmail.com
> <javascript:>> wrote:
>
>> JavaLikeTreeMap map; // derived from AbstractMap
>>
>> size_t n = 0;
>> for(auto &en : map) n++; // working with concrete class
>>
>> size_t count(const JavaLikeTreeMap &map)
>> {
>> size_t n = 0;
>> for(auto &en : map) n++; // looks same but it can be any derived
>> class also
>> return n;
>> }
>>
>
> I think the problem here is that you're working against the type system.
> Since JavaLikeTreeMap is polymorphic, this function obeys all the usual OOP
> principles, such as the Liskov Substitution Principle; so the signature of
> this function expresses the idea that you can "count" the elements of any
> object that *IS-A* JavaLikeTreeMap.
>
> Am I working against type system in the first case? When I create concrete
object and call virtual function directly w/o reference. Really? Don't
think so. And I want just to wrap *the same* code into function without
changing the way that virtual function is called. When I'm writing the code
I have a choice: write such code inline or create a function and slightly
pessimize performance.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b686e329-934f-44af-9fe1-5f13f27609e0%40isocpp.org.
------=_Part_61_842912744.1488438983591
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, March 1, 2017 at 10:49:11 PM UTC+3, Arthur O=
'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Wed, Mar 1, 2017 at 12:07 AM, Victor Dyachenko <span dir=3D"ltr"><=
;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"pjtdqmD=
BCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';re=
turn true;" onclick=3D"this.href=3D'javascript:';return true;">vict=
or.d...@gmail.com</a>></span> wrote:<div><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div><div style=3D"background-color:rgb(250,2=
50,250);border:1px solid rgb(187,187,187)"><code><div><span style=3D"color:=
rgb(102,0,102)">JavaLikeTreeMap</span><span style=3D"color:rgb(0,0,0)"> map=
</span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rg=
b(0,0,0)"> </span><span style=3D"color:rgb(136,0,0)">// derived from Abstra=
ctMap</span><span style=3D"color:rgb(0,0,0)"><br><br>size_t n </span><span =
style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> =
</span><span style=3D"color:rgb(0,102,102)">0</span><span style=3D"color:rg=
b(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br></span><span sty=
le=3D"color:rgb(0,0,136)">for</span><span style=3D"color:rgb(102,102,0)">(<=
/span><span style=3D"color:rgb(0,0,136)">auto</span><span style=3D"color:rg=
b(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">&</span><span st=
yle=3D"color:rgb(0,0,0)">en </span><span style=3D"color:rgb(102,102,0)">:</=
span><span style=3D"color:rgb(0,0,0)"> map</span><span style=3D"color:rgb(1=
02,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> n</span><span style=3D=
"color:rgb(102,102,0)">++;</span><span style=3D"color:rgb(0,0,0)"> </span><=
span style=3D"color:rgb(136,0,0)">// working with concrete class</span><spa=
n style=3D"color:rgb(0,0,0)"><br><br>size_t count</span><span style=3D"colo=
r:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,136)">const</span><s=
pan style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)"=
>JavaLikeTreeMap</span><span style=3D"color:rgb(0,0,0)"> </span><span style=
=3D"color:rgb(102,102,0)">&</span><span style=3D"color:rgb(0,0,0)">map<=
/span><span style=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb=
(0,0,0)"><br></span><span style=3D"color:rgb(102,102,0)">{</span><span styl=
e=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 size_t n </span><span style=3D"col=
or:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span=
style=3D"color:rgb(0,102,102)">0</span><span style=3D"color:rgb(102,102,0)=
">;</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span s=
tyle=3D"color:rgb(0,0,136)">for</span><span style=3D"color:rgb(102,102,0)">=
(</span><span style=3D"color:rgb(0,0,136)">auto</span><span style=3D"color:=
rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">&</span><span =
style=3D"color:rgb(0,0,0)">en </span><span style=3D"color:rgb(102,102,0)">:=
</span><span style=3D"color:rgb(0,0,0)"> map</span><span style=3D"color:rgb=
(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> n</span><span style=
=3D"color:rgb(102,102,0)">++;</span><span style=3D"color:rgb(0,0,0)"> </spa=
n><span style=3D"color:rgb(136,0,0)">// looks same but it can be any derive=
d class also</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </spa=
n><span style=3D"color:rgb(0,0,136)">return</span><span style=3D"color:rgb(=
0,0,0)"> n</span><span style=3D"color:rgb(102,102,0)">;</span><span style=
=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(102,102,0)">}</sp=
an></div></code></div></div></div></blockquote><div><br></div><div>I think =
the problem here is that you're working against the type system. Since =
JavaLikeTreeMap is polymorphic, this function obeys all the usual OOP princ=
iples, such as the Liskov Substitution Principle; so the signature of this =
function expresses the idea that you can "count" the elements of =
any object that <b>IS-A</b> JavaLikeTreeMap.<br></div><br></div></div></div=
></blockquote><div>Am I working against type system in the first case? When=
I create concrete object and call virtual function directly w/o reference.=
Really? Don't think so. And I want just to wrap <b>the same</b> code i=
nto function without changing the way that virtual function is called. When=
I'm writing the code I have a choice: write such code inline or create=
a function and slightly pessimize performance.<br><br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b686e329-934f-44af-9fe1-5f13f27609e0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b686e329-934f-44af-9fe1-5f13f27609e0=
%40isocpp.org</a>.<br />
------=_Part_61_842912744.1488438983591--
------=_Part_60_2134817565.1488438983591--
.
Author: "Arthur O'Dwyer" <arthur.j.odwyer@gmail.com>
Date: Wed, 1 Mar 2017 23:38:38 -0800
Raw View
--f403045f585e816dbe0549ba841a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Mar 1, 2017 at 11:16 PM, Victor Dyachenko <
victor.dyachenko@gmail.com> wrote:
> On Wednesday, March 1, 2017 at 10:49:11 PM UTC+3, Arthur O'Dwyer wrote:
>>
>> On Wed, Mar 1, 2017 at 12:07 AM, Victor Dyachenko <victor.d...@gmail.com=
>
>> wrote:
>>
>>> JavaLikeTreeMap map; // derived from AbstractMap
>>>
>>> size_t n =3D 0;
>>> for(auto &en : map) n++; // working with concrete class
>>>
>>> size_t count(const JavaLikeTreeMap &map)
>>> {
>>> size_t n =3D 0;
>>> for(auto &en : map) n++; // looks same but it can be any derived
>>> class also
>>> return n;
>>> }
>>>
>>
>> I think the problem here is that you're working against the type system.
>> Since JavaLikeTreeMap is polymorphic, this function obeys all the usual =
OOP
>> principles, such as the Liskov Substitution Principle; so the signature =
of
>> this function expresses the idea that you can "count" the elements of an=
y
>> object that *IS-A* JavaLikeTreeMap.
>>
>> Am I working against type system in the first case? When I create
> concrete object and call virtual function directly w/o reference. Really?
> Don't think so. And I want just to wrap *the same* code into function
> without changing the way that virtual function is called.
>
In classical-OOP-land, creating a function (an addition to the public
interface) is not a trivial refactor, because it fundamentally *creates a
new operation* that you can do with certain kinds of objects (and not do
with other kinds of objects). In classical OOP, the only means we have for
describing "kinds of objects" is the class hierarchy, which brings with it
all the classical rules such as the Liskov Substitution Principle.
Now, if you can introduce that new function without increasing the surface
area of your interface, then you'll do fine. For example, in C++ you could
make your helper function file-scope-static, so that nobody would be
allowed to call it from any other translation unit, and the compiler might
notice that you only ever call it from one place or with objects of one
dynamic type, and do the inlining and devirtualization for you.
But if you create a new externally visible method (or, in C++, a new
externally visible free function), then you are expanding the surface area
of your class type, and it makes sense that substitutability is preserved.
> When I'm writing the code I have a choice: write such code inline or
> create a function and slightly pessimize performance.
>
....Or mark the troublesome methods final, or write the code with explicit
obj.C::method() qualification to turn off virtual dispatch, or not make the
troublesome methods virtual in the first place, or use a more aggressive
devirtualizer if you can find one, or probably some other things.
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0JdjR-bhpJH32qNevjHfzEX%3D1TEuHnnMCdnWRgnS=
UFFsQ%40mail.gmail.com.
--f403045f585e816dbe0549ba841a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Mar 1, 2017 at 11:16 PM, Victor Dyachenko <span di=
r=3D"ltr"><<a href=3D"mailto:victor.dyachenko@gmail.com" target=3D"_blan=
k">victor.dyachenko@gmail.com</a>></span> wrote:<br><div class=3D"gmail_=
extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">On Wednesday, March 1, 2017 at 10:49:11 PM UTC+3, Arthur O'Dwy=
er wrote:<span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">On Wed, Mar 1, 2017 at 12:07 AM, Victor Dyachenko <span dir=3D"ltr=
"><<a rel=3D"nofollow">victor.d...@gmail.com</a>></span> wrote:<div><=
div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div style=
=3D"background-color:rgb(250,250,250);border:1px solid rgb(187,187,187)"><c=
ode><div><span style=3D"color:rgb(102,0,102)">JavaLikeTreeMap</span><span s=
tyle=3D"color:rgb(0,0,0)"> map</span><span style=3D"color:rgb(102,102,0)">;=
</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(13=
6,0,0)">// derived from AbstractMap</span><span style=3D"color:rgb(0,0,0)">=
<br><br>size_t n </span><span style=3D"color:rgb(102,102,0)">=3D</span><spa=
n style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,102,102)">0=
</span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rg=
b(0,0,0)"><br></span><span style=3D"color:rgb(0,0,136)">for</span><span sty=
le=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,136)">auto=
</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(10=
2,102,0)">&</span><span style=3D"color:rgb(0,0,0)">en </span><span styl=
e=3D"color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"> map</s=
pan><span style=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0=
,0,0)"> n</span><span style=3D"color:rgb(102,102,0)">++;</span><span style=
=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(136,0,0)">// working=
with concrete class</span><span style=3D"color:rgb(0,0,0)"><br><br>size_t =
count</span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"col=
or:rgb(0,0,136)">const</span><span style=3D"color:rgb(0,0,0)"> </span><span=
style=3D"color:rgb(102,0,102)">JavaLikeTreeMap</span><span style=3D"color:=
rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">&</span><span =
style=3D"color:rgb(0,0,0)">map</span><span style=3D"color:rgb(102,102,0)">)=
</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb=
(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 siz=
e_t n </span><span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"=
color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,102,102)">0</span><spa=
n style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><=
br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">for</span><span =
style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,136)">a=
uto</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb=
(102,102,0)">&</span><span style=3D"color:rgb(0,0,0)">en </span><span s=
tyle=3D"color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"> map=
</span><span style=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rg=
b(0,0,0)"> n</span><span style=3D"color:rgb(102,102,0)">++;</span><span sty=
le=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(136,0,0)">// looks=
same but it can be any derived class also</span><span style=3D"color:rgb(0=
,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)">return</=
span><span style=3D"color:rgb(0,0,0)"> n</span><span style=3D"color:rgb(102=
,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D=
"color:rgb(102,102,0)">}</span></div></code></div></div></div></blockquote>=
<div><br></div><div>I think the problem here is that you're working aga=
inst the type system. Since JavaLikeTreeMap is polymorphic, this function o=
beys all the usual OOP principles, such as the Liskov Substitution Principl=
e; so the signature of this function expresses the idea that you can "=
count" the elements of any object that <b>IS-A</b> JavaLikeTreeMap.<br=
></div><br></div></div></div></blockquote></span><div>Am I working against =
type system in the first case? When I create concrete object and call virtu=
al function directly w/o reference. Really? Don't think so. And I want =
just to wrap <b>the same</b> code into function without changing the way th=
at virtual function is called.</div></div></blockquote><div><br></div><div>=
In classical-OOP-land, creating a function (an addition to the public inter=
face) is not a trivial refactor, because it fundamentally <i>creates a new =
operation</i> that you can do with certain kinds of objects (and not do wit=
h other kinds of objects). In classical OOP, the only means we have for des=
cribing "kinds of objects" is the class hierarchy, which brings w=
ith it all the classical rules such as the Liskov Substitution Principle.</=
div><div><br></div><div>Now, if you can introduce that new function without=
increasing the surface area of your interface, then you'll do fine. Fo=
r example, in C++ you could make your helper function file-scope-<font face=
=3D"monospace, monospace">static</font>, so that nobody would be allowed to=
call it from any other translation unit, and the compiler might notice tha=
t you only ever call it from one place or with objects of one dynamic type,=
and do the inlining and devirtualization for you.</div><div><br></div><div=
>But if you create a new externally visible method (or, in C++, a new exter=
nally visible free function), then you are expanding the surface area of yo=
ur class type, and it makes sense that substitutability is preserved.</div>=
<div><br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div> When I'm writing the code I have a choice: write such co=
de inline or create a function and slightly pessimize performance.<br></div=
></div></blockquote><div><br></div><div>...Or mark the troublesome methods=
=C2=A0<font face=3D"monospace, monospace">final</font>, or write the code w=
ith explicit <font face=3D"monospace, monospace">obj.C::method()</font> qua=
lification to turn off virtual dispatch, or not make the troublesome method=
s <font face=3D"monospace, monospace">virtual</font> in the first place, or=
use a more aggressive devirtualizer if you can find one, or probably some =
other things.</div><div><br></div><div>=E2=80=93Arthur</div></div></div></d=
iv>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0JdjR-bhpJH32qNevjHfzEX%3D1TEuH=
nnMCdnWRgnSUFFsQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0JdjR-bhp=
JH32qNevjHfzEX%3D1TEuHnnMCdnWRgnSUFFsQ%40mail.gmail.com</a>.<br />
--f403045f585e816dbe0549ba841a--
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Wed, 1 Mar 2017 23:51:18 -0800 (PST)
Raw View
------=_Part_39_317313901.1488441078262
Content-Type: multipart/alternative;
boundary="----=_Part_40_1389291529.1488441078262"
------=_Part_40_1389291529.1488441078262
Content-Type: text/plain; charset=UTF-8
On Thursday, March 2, 2017 at 10:38:41 AM UTC+3, Arthur O'Dwyer wrote:
>
>
> ...Or mark the troublesome methods final, or write the code with explicit
> obj.C::method() qualification to turn off virtual dispatch, or not make
> the troublesome methods virtual in the first place, or use a more
> aggressive devirtualizer if you can find one, or probably some other things.
>
> final is not a solution. It requires an ability to modify used class. Not
all classes I use are written by me, I use libraries too ;-)
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9c866287-7772-4ad4-91b9-cdce61a5a745%40isocpp.org.
------=_Part_40_1389291529.1488441078262
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, March 2, 2017 at 10:38:41 AM UTC+3, Arthur O&=
#39;Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div><div class=3D"gmail_quote"><br><div>...Or mark the troublesome meth=
ods=C2=A0<font face=3D"monospace, monospace">final</font>, or write the cod=
e with explicit <font face=3D"monospace, monospace">obj.C::method()</font> =
qualification to turn off virtual dispatch, or not make the troublesome met=
hods <font face=3D"monospace, monospace">virtual</font> in the first place,=
or use a more aggressive devirtualizer if you can find one, or probably so=
me other things.</div><br></div></div></div></blockquote><div>final is not =
a solution. It requires an ability to modify used class. Not all classes I =
use are written by me, I use libraries too ;-)<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9c866287-7772-4ad4-91b9-cdce61a5a745%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9c866287-7772-4ad4-91b9-cdce61a5a745=
%40isocpp.org</a>.<br />
------=_Part_40_1389291529.1488441078262--
------=_Part_39_317313901.1488441078262--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 02 Mar 2017 00:02:11 -0800
Raw View
Em quarta-feira, 1 de mar=C3=A7o de 2017, =C3=A0s 23:04:50 PST, Victor Dyac=
henko=20
escreveu:
> I mean function decomposition. Parts of a big function (chunks of code)
> become functions itself.
>=20
> I know what it does. I am asking why you would want such a function *not*
>=20
> > to
> > work for derived classes. That is not explained.
>=20
> Generated code. It will be more efficient.
Sorry, you're still not explaining. You're handwaving.
Please give a concrete use-case.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2537925.vfXDUYAmrD%40tjmaciei-mobl1.
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Thu, 2 Mar 2017 00:22:45 -0800 (PST)
Raw View
------=_Part_97_186437460.1488442965625
Content-Type: multipart/alternative;
boundary="----=_Part_98_1231485668.1488442965626"
------=_Part_98_1231485668.1488442965626
Content-Type: text/plain; charset=UTF-8
On Thursday, March 2, 2017 at 10:51:18 AM UTC+3, Victor Dyachenko wrote:
>
> On Thursday, March 2, 2017 at 10:38:41 AM UTC+3, Arthur O'Dwyer wrote:
>>
>>
>> ...Or mark the troublesome methods final, or write the code with
>> explicit obj.C::method() qualification to turn off virtual dispatch, or
>> not make the troublesome methods virtual in the first place, or use a
>> more aggressive devirtualizer if you can find one, or probably some other
>> things.
>>
>> final is not a solution. It requires an ability to modify used class. Not
> all classes I use are written by me, I use libraries too ;-)
>
Hm... Actually we can create a wrapper for polymorphic class:
struct ConcreteMap final : public JavaLikeTreeMap
{
using JavaLikeTreeMap::JavaLikeTreeMap
};
size_t count(const ConcreteMap &map)
{
...
}
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6f400497-7136-4868-80a6-0c4c3d94bb5c%40isocpp.org.
------=_Part_98_1231485668.1488442965626
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, March 2, 2017 at 10:51:18 AM UTC+3, Victor Dy=
achenko wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On Thursday, March 2, 2017 at 10:38:41 AM UTC+3, Arthur O'Dwyer wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D=
"gmail_quote"><br><div>...Or mark the troublesome methods=C2=A0<font face=
=3D"monospace, monospace">final</font>, or write the code with explicit <fo=
nt face=3D"monospace, monospace">obj.C::method()</font> qualification to tu=
rn off virtual dispatch, or not make the troublesome methods <font face=3D"=
monospace, monospace">virtual</font> in the first place, or use a more aggr=
essive devirtualizer if you can find one, or probably some other things.</d=
iv><br></div></div></div></blockquote><div>final is not a solution. It requ=
ires an ability to modify used class. Not all classes I use are written by =
me, I use libraries too ;-)<br></div></div></blockquote><div><br>Hm... Actu=
ally we can create a wrapper for polymorphic class:<br><br><div style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"pre=
ttyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">ConcreteMap</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">final</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">pu=
blic</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #606;" class=3D"styled-by-prettify">JavaLikeTreeMap=
</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 st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">using</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">JavaLikeTreeMap</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">JavaLikeTreeMap</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: #00=
0;" class=3D"styled-by-prettify"><br><br>size_t count</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">ConcreteMap</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">map</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </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></span></div></code></div><span><=
code><span style=3D"color:rgb(102,102,0)"><br></span></code></span></div></=
div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6f400497-7136-4868-80a6-0c4c3d94bb5c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6f400497-7136-4868-80a6-0c4c3d94bb5c=
%40isocpp.org</a>.<br />
------=_Part_98_1231485668.1488442965626--
------=_Part_97_186437460.1488442965625--
.