Topic: virtual class
Author: wei zhang <lala.willzhang@gmail.com>
Date: Tue, 20 Jun 2017 01:48:40 -0700 (PDT)
Raw View
------=_Part_3912_297233450.1497948520735
Content-Type: multipart/alternative;
boundary="----=_Part_3913_965048324.1497948520735"
------=_Part_3913_965048324.1497948520735
Content-Type: text/plain; charset="UTF-8"
I suggest a virtual class declaration that it can only be inherited with
virtual keyword.
Sample
virtual class BaseObject{
public:
void * GetBasePtr(){return this;};
protected:
int my_value;
};
You must virtual inherits this class otherwise compile will report error.
Sample:
class MyClass:public virtual BaseObject
{
...
}
The MyClass will compile error without the virtual keyword.
With this restriction, architecture programmer can restrict that his Base
Class won't have poly-inherit problem.
You can also combine virtual with abstract. So like
virtual abstract class BaseObject{
....
};
--
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/24b0f800-5cea-47fe-b0ac-13333003b959%40isocpp.org.
------=_Part_3913_965048324.1497948520735
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I suggest a virtual class declaration that it can only be =
inherited with virtual keyword.<div><br></div><div>Sample</div><div><br></d=
iv><div><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"><div class=3D"sub=
prettyprint"><span style=3D"background-color: rgb(255, 255, 255); font-fami=
ly: Arial, Helvetica, sans-serif;"><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">virtual</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">BaseObje=
ct</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: #008;" class=3D"styled-by-prettify">public</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">GetBasePtr</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(){</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">this<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">;};</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">protected</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>=C2=A0 =C2=A0 </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> my_value</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">};</span></span></div></code><div style=3D"backgr=
ound-color: rgb(255, 255, 255);">=C2=A0 =C2=A0=C2=A0</div></div><br></div><=
div><br><div>You must virtual inherits this class otherwise compile will re=
port error. =C2=A0</div></div><div>Sample:</div><div><div class=3D"prettypr=
int" 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"><div class=3D"subprettyprint"><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">class</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">MyClass</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">:</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">public</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">virtual</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #606;" class=3D"styled-by-prettify">BaseObject=
</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 </span><span s=
tyle=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><br>The MyClass =
will compile error without the virtual keyword.</div><div><br></div><div>Wi=
th this restriction, architecture programmer can restrict that his Base Cla=
ss won't have poly-inherit problem.</div><div><br></div><div><br></div>=
<div>You can also combine virtual with abstract. =C2=A0So like</div><div>vi=
rtual abstract class BaseObject{</div><div>...</div><div>};</div><div><br><=
/div><div><br></div><div><br></div><div><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/24b0f800-5cea-47fe-b0ac-13333003b959%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/24b0f800-5cea-47fe-b0ac-13333003b959=
%40isocpp.org</a>.<br />
------=_Part_3913_965048324.1497948520735--
------=_Part_3912_297233450.1497948520735--
.
Author: =?UTF-8?Q?Daniel_Kr=C3=BCgler?= <daniel.kruegler@gmail.com>
Date: Tue, 20 Jun 2017 11:03:06 +0200
Raw View
2017-06-20 10:48 GMT+02:00 wei zhang <lala.willzhang@gmail.com>:
> I suggest a virtual class declaration that it can only be inherited with
> virtual keyword.
>
> Sample
>
> virtual class BaseObject{
> public:
> void * GetBasePtr(){return this;};
> protected:
> int my_value;
> };
>
>
>
> You must virtual inherits this class otherwise compile will report error.
>
> Sample:
> class MyClass:public virtual BaseObject
> {
> ...
> }
>
> The MyClass will compile error without the virtual keyword.
So you intend to break *all* existing C++ code in the world that
currently uses virtual inheritance?
I guess the chances for the acceptance of such a proposal is close to zero.
- Daniel
--
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/CAGNvRgB8aJU%3Dx42whgOc0guic-UKWWf9%3Dh%3Dxic31cT8R1Eg5hQ%40mail.gmail.com.
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Tue, 20 Jun 2017 09:07:33 +0000
Raw View
--94eb2c145bd6a8d5720552609554
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
No, he doesn't want to change virtual inheritance, he wants to introduce a
new thing that can only be inherited virtually. I don't think this would be
a breaking change in any way, but that doesn't change the fact that virtual
inheritance is funky enough to be avoided in almost all cases (unless
you're an expert, but an expert knows when to break the rule); this would
only lead to virtual inheritance and spaghetti class hierarchies spreading.
On Tue, Jun 20, 2017 at 11:03 AM Daniel Kr=C3=BCgler <daniel.kruegler@gmail=
..com>
wrote:
> 2017-06-20 10:48 GMT+02:00 wei zhang <lala.willzhang@gmail.com>:
> > I suggest a virtual class declaration that it can only be inherited wit=
h
> > virtual keyword.
> >
> > Sample
> >
> > virtual class BaseObject{
> > public:
> > void * GetBasePtr(){return this;};
> > protected:
> > int my_value;
> > };
> >
> >
> >
> > You must virtual inherits this class otherwise compile will report erro=
r.
> >
> > Sample:
> > class MyClass:public virtual BaseObject
> > {
> > ...
> > }
> >
> > The MyClass will compile error without the virtual keyword.
>
> So you intend to break *all* existing C++ code in the world that
> currently uses virtual inheritance?
>
> I guess the chances for the acceptance of such a proposal is close to zer=
o.
>
> - Daniel
>
> --
> 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/CAGNvRgB8aJU=
%3Dx42whgOc0guic-UKWWf9%3Dh%3Dxic31cT8R1Eg5hQ%40mail.gmail.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/CAPCFJdR8TgkE6J%3DaKh1mTsgmDgA-P0rxXAwOXP_C71uQ3=
hvw%2Bw%40mail.gmail.com.
--94eb2c145bd6a8d5720552609554
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">No, he doesn't want to change virtual inheritance, he =
wants to introduce a new thing that can only be inherited virtually. I don&=
#39;t think this would be a breaking change in any way, but that doesn'=
t change the fact that virtual inheritance is funky enough to be avoided in=
almost all cases (unless you're an expert, but an expert knows when to=
break the rule); this would only lead to virtual inheritance and spaghetti=
class hierarchies spreading.</div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr">On Tue, Jun 20, 2017 at 11:03 AM Daniel Kr=C3=BCgler <<a href=
=3D"mailto:daniel.kruegler@gmail.com">daniel.kruegler@gmail.com</a>> wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">2017-06-20 10:48 GMT+02:00 wei =
zhang <<a href=3D"mailto:lala.willzhang@gmail.com" target=3D"_blank">lal=
a.willzhang@gmail.com</a>>:<br>
> I suggest a virtual class declaration that it can only be inherited wi=
th<br>
> virtual keyword.<br>
><br>
> Sample<br>
><br>
> virtual class BaseObject{<br>
> public:<br>
>=C2=A0 =C2=A0 =C2=A0void * GetBasePtr(){return this;};<br>
> protected:<br>
>=C2=A0 =C2=A0 =C2=A0int my_value;<br>
> };<br>
><br>
><br>
><br>
> You must virtual inherits this class otherwise compile will report err=
or.<br>
><br>
> Sample:<br>
> class MyClass:public virtual BaseObject<br>
> {<br>
>=C2=A0 =C2=A0...<br>
> }<br>
><br>
> The MyClass will compile error without the virtual keyword.<br>
<br>
So you intend to break *all* existing C++ code in the world that<br>
currently uses virtual inheritance?<br>
<br>
I guess the chances for the acceptance of such a proposal is close to zero.=
<br>
<br>
- Daniel<br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGNvRgB8aJU%3Dx42whgOc0guic-UKWWf9%3=
Dh%3Dxic31cT8R1Eg5hQ%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGNvRgB8aJU%=
3Dx42whgOc0guic-UKWWf9%3Dh%3Dxic31cT8R1Eg5hQ%40mail.gmail.com</a>.<br>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdR8TgkE6J%3DaKh1mTsgmDgA-P0rxXA=
wOXP_C71uQ3hvw%2Bw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdR8TgkE=
6J%3DaKh1mTsgmDgA-P0rxXAwOXP_C71uQ3hvw%2Bw%40mail.gmail.com</a>.<br />
--94eb2c145bd6a8d5720552609554--
.
Author: Ricardo Fabiano de Andrade <ricardofabianodeandrade@gmail.com>
Date: Tue, 20 Jun 2017 10:36:54 -0500
Raw View
--94eb2c18f8787098620552660560
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
What to say about final and override then?
Do they lead to more use of bad dynamic polymorphism or just make it less
error prone?
Any idea that prevents mistakes should be welcome.
On Tue, Jun 20, 2017 at 4:07 AM, Micha=C5=82 Dominiak <griwes@griwes.info> =
wrote:
> No, he doesn't want to change virtual inheritance, he wants to introduce =
a
> new thing that can only be inherited virtually. I don't think this would =
be
> a breaking change in any way, but that doesn't change the fact that virtu=
al
> inheritance is funky enough to be avoided in almost all cases (unless
> you're an expert, but an expert knows when to break the rule); this would
> only lead to virtual inheritance and spaghetti class hierarchies spreadin=
g.
>
> On Tue, Jun 20, 2017 at 11:03 AM Daniel Kr=C3=BCgler <daniel.kruegler@gma=
il.com>
> wrote:
>
>> 2017-06-20 10:48 GMT+02:00 wei zhang <lala.willzhang@gmail.com>:
>> > I suggest a virtual class declaration that it can only be inherited wi=
th
>> > virtual keyword.
>> >
>> > Sample
>> >
>> > virtual class BaseObject{
>> > public:
>> > void * GetBasePtr(){return this;};
>> > protected:
>> > int my_value;
>> > };
>> >
>> >
>> >
>> > You must virtual inherits this class otherwise compile will report
>> error.
>> >
>> > Sample:
>> > class MyClass:public virtual BaseObject
>> > {
>> > ...
>> > }
>> >
>> > The MyClass will compile error without the virtual keyword.
>>
>> So you intend to break *all* existing C++ code in the world that
>> currently uses virtual inheritance?
>>
>> I guess the chances for the acceptance of such a proposal is close to
>> zero.
>>
>> - Daniel
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/CAGNvRgB8aJU%3Dx42whgOc0guic-UKWWf9%3Dh=
%
>> 3Dxic31cT8R1Eg5hQ%40mail.gmail.com.
>>
> --
> 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/CAPCFJdR8TgkE6J%
> 3DaKh1mTsgmDgA-P0rxXAwOXP_C71uQ3hvw%2Bw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdR8Tg=
kE6J%3DaKh1mTsgmDgA-P0rxXAwOXP_C71uQ3hvw%2Bw%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
> .
>
--=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/CA%2BfGSbNXzZ9vkXEKyoOUYrocimVz3FyT8FfVL9J5HLXAE=
2zqVw%40mail.gmail.com.
--94eb2c18f8787098620552660560
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">What to say about final and override then?<div>Do they lea=
d to more use of bad dynamic polymorphism or just make it less error prone?=
</div><div>Any idea that prevents mistakes should be welcome.<br></div></di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jun 20,=
2017 at 4:07 AM, Micha=C5=82 Dominiak <span dir=3D"ltr"><<a href=3D"mai=
lto:griwes@griwes.info" target=3D"_blank">griwes@griwes.info</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">No, he doesn'=
;t want to change virtual inheritance, he wants to introduce a new thing th=
at can only be inherited virtually. I don't think this would be a break=
ing change in any way, but that doesn't change the fact that virtual in=
heritance is funky enough to be avoided in almost all cases (unless you'=
;re an expert, but an expert knows when to break the rule); this would only=
lead to virtual inheritance and spaghetti class hierarchies spreading.</di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Jun 20, 2017 at 1=
1:03 AM Daniel Kr=C3=BCgler <<a href=3D"mailto:daniel.kruegler@gmail.com=
" target=3D"_blank">daniel.kruegler@gmail.com</a>> wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">2017-06-20 10:48 GMT+02:00 wei zhang <<a href=
=3D"mailto:lala.willzhang@gmail.com" target=3D"_blank">lala.willzhang@gmail=
..com</a>>:<br>
> I suggest a virtual class declaration that it can only be inherited wi=
th<br>
> virtual keyword.<br>
><br>
> Sample<br>
><br>
> virtual class BaseObject{<br>
> public:<br>
>=C2=A0 =C2=A0 =C2=A0void * GetBasePtr(){return this;};<br>
> protected:<br>
>=C2=A0 =C2=A0 =C2=A0int my_value;<br>
> };<br>
><br>
><br>
><br>
> You must virtual inherits this class otherwise compile will report err=
or.<br>
><br>
> Sample:<br>
> class MyClass:public virtual BaseObject<br>
> {<br>
>=C2=A0 =C2=A0...<br>
> }<br>
><br>
> The MyClass will compile error without the virtual keyword.<br>
<br>
So you intend to break *all* existing C++ code in the world that<br>
currently uses virtual inheritance?<br>
<br>
I guess the chances for the acceptance of such a proposal is close to zero.=
<br>
<br>
- Daniel<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
--<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGNvRgB8aJU%3Dx42whgOc0guic-UKWWf9%3=
Dh%3Dxic31cT8R1Eg5hQ%40mail.gmail.com" rel=3D"noreferrer" target=3D"_blank"=
>https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/CAG=
NvRgB8aJU%<wbr>3Dx42whgOc0guic-UKWWf9%3Dh%<wbr>3Dxic31cT8R1Eg5hQ%40mail.<wb=
r>gmail.com</a>.<br>
</font></span></blockquote></div><span class=3D"HOEnZb"><font color=3D"#888=
888">
<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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAPCFJdR8TgkE6J%3DaKh1mTsgmDgA-P0rxXA=
wOXP_C71uQ3hvw%2Bw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/CAPCFJdR8TgkE6J%<wbr>3DaKh1mTsgmDgA-P0rxXAwOXP_<wbr>C71u=
Q3hvw%2Bw%40mail.gmail.com</a><wbr>.<br>
</font></span></blockquote></div><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/CA%2BfGSbNXzZ9vkXEKyoOUYrocimVz3FyT8F=
fVL9J5HLXAE2zqVw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbNXzZ9v=
kXEKyoOUYrocimVz3FyT8FfVL9J5HLXAE2zqVw%40mail.gmail.com</a>.<br />
--94eb2c18f8787098620552660560--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 20 Jun 2017 08:54:07 -0700 (PDT)
Raw View
------=_Part_2133_1985377505.1497974047951
Content-Type: multipart/alternative;
boundary="----=_Part_2134_210507740.1497974047951"
------=_Part_2134_210507740.1497974047951
Content-Type: text/plain; charset="UTF-8"
On Tuesday, June 20, 2017 at 11:36:57 AM UTC-4, Ricardo Andrade wrote:
>
> What to say about final and override then?
> Do they lead to more use of bad dynamic polymorphism or just make it less
> error prone?
> Any idea that prevents mistakes should be welcome.
>
`override` merely prevents mistakes. The cases where `override` would cause
a compile error are cases where the user's declared intent does not match
the function signature they have written. You intend to override a
function, but there is no matching signature to be override. That's clearly
a mistake.
This notion of `virtual` "prevents mistakes" only if you start from the
belief that all non-virtual inheritance is a mistake. But this belief is
decidedly nonsensical.
Please provide a demonstration of a class that *must* be virtually
inherited in all places where it gets used as a base class. Where *all*
non-virtual inheritance of such a class would be as clear a mistake as
those caught by `override`.
You could suggest a "lighter" version of this `virtual class` notion, where
you only get a compile error if there are multiple, non-virtual
inheritances of the same base class. However, I would again like to see a
base class where, by the nature of that base class, this would *always* be
a problem.
--
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/05407ce7-891e-4355-a5de-d58a7f8f947e%40isocpp.org.
------=_Part_2134_210507740.1497974047951
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, June 20, 2017 at 11:36:57 AM UTC-4, Ricardo An=
drade wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">W=
hat to say about final and override then?<div>Do they lead to more use of b=
ad dynamic polymorphism or just make it less error prone?</div><div>Any ide=
a that prevents mistakes should be welcome.<br></div></div></blockquote><di=
v><br>`override` merely prevents mistakes. The cases where `override` would=
cause a compile error are cases where the user's declared intent does =
not match the function signature they have written. You intend to override =
a function, but there is no matching signature to be override. That's c=
learly a mistake.<br><br>This notion of `virtual` "prevents mistakes&q=
uot; only if you start from the belief that all non-virtual inheritance is =
a mistake. But this belief is decidedly nonsensical.<br><br>Please provide =
a demonstration of a class that <i>must</i> be virtually inherited in all p=
laces where it gets used as a base class. Where <i>all</i> non-virtual inhe=
ritance of such a class would be as clear a mistake as those caught by `ove=
rride`.<br><br>You could suggest a "lighter" version of this `vir=
tual class` notion, where you only get a compile error if there are multipl=
e, non-virtual inheritances of the same base class. However, I would again =
like to see a base class where, by the nature of that base class, this woul=
d <i>always</i> be a problem.<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/05407ce7-891e-4355-a5de-d58a7f8f947e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/05407ce7-891e-4355-a5de-d58a7f8f947e=
%40isocpp.org</a>.<br />
------=_Part_2134_210507740.1497974047951--
------=_Part_2133_1985377505.1497974047951--
.
Author: Ricardo Fabiano de Andrade <ricardofabianodeandrade@gmail.com>
Date: Tue, 20 Jun 2017 13:12:41 -0500
Raw View
--f403045e3e368c5e5f055268329a
Content-Type: text/plain; charset="UTF-8"
I found interesting that you focused on `override` and mentioned nothing
about `final` which would much closer to the suggested `virtual` since it
applies to classes.
If I understood the OP correctly, `virtual` would be used for base classes
that due some design decision it's known ahead of time that it will fall
into the diamond problem of multiple inheritance and virtual inheritance
must be used on the derived classes.
The annotation as `virtual` triggering a compiler error in this case could
be beneficial to the users of such base class.
In the same line, someone only uses `final` when the class should never be
used as a base class due some design decision.
So I can't provide such the demonstration you're requesting for `virtual`
as one would not be able to provide one `final` for all its uses.
It's a design decision based on the problem at hand.
And if the design decision around multiple inheritance is bad or good,
that's besides the point.
On Tue, Jun 20, 2017 at 10:54 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, June 20, 2017 at 11:36:57 AM UTC-4, Ricardo Andrade wrote:
>>
>> What to say about final and override then?
>> Do they lead to more use of bad dynamic polymorphism or just make it less
>> error prone?
>> Any idea that prevents mistakes should be welcome.
>>
>
> `override` merely prevents mistakes. The cases where `override` would
> cause a compile error are cases where the user's declared intent does not
> match the function signature they have written. You intend to override a
> function, but there is no matching signature to be override. That's clearly
> a mistake.
>
> This notion of `virtual` "prevents mistakes" only if you start from the
> belief that all non-virtual inheritance is a mistake. But this belief is
> decidedly nonsensical.
>
> Please provide a demonstration of a class that *must* be virtually
> inherited in all places where it gets used as a base class. Where *all*
> non-virtual inheritance of such a class would be as clear a mistake as
> those caught by `override`.
>
> You could suggest a "lighter" version of this `virtual class` notion,
> where you only get a compile error if there are multiple, non-virtual
> inheritances of the same base class. However, I would again like to see a
> base class where, by the nature of that base class, this would *always*
> be a problem.
>
> --
> 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/05407ce7-891e-4355-
> a5de-d58a7f8f947e%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/05407ce7-891e-4355-a5de-d58a7f8f947e%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CA%2BfGSbP8Og_on3a%3D06Y18C7-VgwqHhOqMkxrUeYeuEJuq5n3Qg%40mail.gmail.com.
--f403045e3e368c5e5f055268329a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I found interesting that you focused on `override` and men=
tioned nothing about `final` which would much closer to the suggested `virt=
ual` since it applies to classes.<div>If I understood the OP correctly, `vi=
rtual` would be used for base classes that due some design decision it'=
s known ahead of time that it will fall into the diamond problem of multipl=
e inheritance and virtual inheritance must be used on the derived classes.<=
/div><div>The annotation as `virtual` triggering a compiler error in this c=
ase could be beneficial to the users of such base class.</div><div><br></di=
v><div>In the same line, someone only uses `final` when the class should ne=
ver be used as a base class due some design decision.</div><div>So I can=
9;t provide such the demonstration you're requesting for `virtual` as o=
ne would not be able to provide one `final` for all its uses.<br></div><div=
><br></div><div>It's a design decision based on the problem at hand.</d=
iv><div>And if the design decision around multiple inheritance is bad or go=
od, that's besides the point.<br></div><div><br></div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Jun 20, 2017 at 10:=
54 AM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.=
com" target=3D"_blank">jmckesson@gmail.com</a>></span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, June 20, 2017 at 11:36=
:57 AM UTC-4, Ricardo Andrade 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">What to say about final and override then?<div>Do they le=
ad to more use of bad dynamic polymorphism or just make it less error prone=
?</div><div>Any idea that prevents mistakes should be welcome.<br></div></d=
iv></blockquote><div><br>`override` merely prevents mistakes. The cases whe=
re `override` would cause a compile error are cases where the user's de=
clared intent does not match the function signature they have written. You =
intend to override a function, but there is no matching signature to be ove=
rride. That's clearly a mistake.<br><br>This notion of `virtual` "=
prevents mistakes" only if you start from the belief that all non-virt=
ual inheritance is a mistake. But this belief is decidedly nonsensical.<br>=
<br>Please provide a demonstration of a class that <i>must</i> be virtually=
inherited in all places where it gets used as a base class. Where <i>all</=
i> non-virtual inheritance of such a class would be as clear a mistake as t=
hose caught by `override`.<br><br>You could suggest a "lighter" v=
ersion of this `virtual class` notion, where you only get a compile error i=
f there are multiple, non-virtual inheritances of the same base class. Howe=
ver, I would again like to see a base class where, by the nature of that ba=
se class, this would <i>always</i> be a problem.<span class=3D"HOEnZb"><fon=
t color=3D"#888888"><br></font></span></div></div><span class=3D"HOEnZb"><f=
ont color=3D"#888888">
<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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/05407ce7-891e-4355-a5de-d58a7f8f947e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/0540=
7ce7-891e-4355-<wbr>a5de-d58a7f8f947e%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><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/CA%2BfGSbP8Og_on3a%3D06Y18C7-VgwqHhOq=
MkxrUeYeuEJuq5n3Qg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSbP8Og=
_on3a%3D06Y18C7-VgwqHhOqMkxrUeYeuEJuq5n3Qg%40mail.gmail.com</a>.<br />
--f403045e3e368c5e5f055268329a--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Tue, 20 Jun 2017 14:19:36 -0400
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">So, for final, there were motivating examples of classes that s=
houldn't be derived from. </div><div style=3D"width: 100%; font-size: =
initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: =
rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255)=
;"><br></div><div style=3D"width: 100%; font-size: initial; font-family: Ca=
libri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-a=
lign: initial; background-color: rgb(255, 255, 255);">What are the motivati=
ng examples of classes that should only be virtually derived from?</div><di=
v style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pr=
o', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; b=
ackground-color: rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; =
font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-ser=
if; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255=
, 255, 255);">I think they exist, I may have even written some, but they ne=
ed to be shown. As 'real world' as possible. Not theoretical. </div> =
=
<div style=3D"width: 100=
%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-=
serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(=
255, 255, 255);"><br style=3D"display:initial"></div> =
=
=
<div style=3D"font-size: initial; font-family: Calib=
ri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-alig=
n: initial; background-color: rgb(255, 255, 255);">Sent from my&n=
bsp;BlackBerry portable Babbage Device</div> =
=
=
<table width=3D"100%" style=3D"background-color:white;border-sp=
acing:0px;"> <tbody><tr><td colspan=3D"2" style=3D"font-size: initial; text=
-align: initial; background-color: rgb(255, 255, 255);"> =
<div style=3D"border-style: solid none none; border-top-color: rgb(=
181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: T=
ahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>=
Ricardo Fabiano de Andrade</div><div><b>Sent: </b>Tuesday, June 20, 2017 2:=
12 PM</div><div><b>To: </b>std-proposals@isocpp.org</div><div><b>Reply To: =
</b>std-proposals@isocpp.org</div><div><b>Subject: </b>Re: [std-proposals] =
virtual class</div></div></td></tr></tbody></table><div style=3D"border-sty=
le: solid none none; border-top-color: rgb(186, 188, 209); border-top-width=
: 1pt; font-size: initial; text-align: initial; background-color: rgb(255, =
255, 255);"></div><br><div id=3D"_originalContent" style=3D""><div dir=3D"l=
tr">I found interesting that you focused on `override` and mentioned nothin=
g about `final` which would much closer to the suggested `virtual` since it=
applies to classes.<div>If I understood the OP correctly, `virtual` would =
be used for base classes that due some design decision it's known ahead of =
time that it will fall into the diamond problem of multiple inheritance and=
virtual inheritance must be used on the derived classes.</div><div>The ann=
otation as `virtual` triggering a compiler error in this case could be bene=
ficial to the users of such base class.</div><div><br></div><div>In the sam=
e line, someone only uses `final` when the class should never be used as a =
base class due some design decision.</div><div>So I can't provide such the =
demonstration you're requesting for `virtual` as one would not be able to p=
rovide one `final` for all its uses.<br></div><div><br></div><div>It's a de=
sign decision based on the problem at hand.</div><div>And if the design dec=
ision around multiple inheritance is bad or good, that's besides the point.=
<br></div><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D=
"gmail_quote">On Tue, Jun 20, 2017 at 10:54 AM, Nicol Bolas <span dir=3D"lt=
r"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@g=
mail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">On Tuesday, June 20, 2017 at 11:36:57 AM UTC-4, Ricardo Andrade wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">What to say ab=
out final and override then?<div>Do they lead to more use of bad dynamic po=
lymorphism or just make it less error prone?</div><div>Any idea that preven=
ts mistakes should be welcome.<br></div></div></blockquote><div><br>`overri=
de` merely prevents mistakes. The cases where `override` would cause a comp=
ile error are cases where the user's declared intent does not match the fun=
ction signature they have written. You intend to override a function, but t=
here is no matching signature to be override. That's clearly a mistake.<br>=
<br>This notion of `virtual` "prevents mistakes" only if you start from the=
belief that all non-virtual inheritance is a mistake. But this belief is d=
ecidedly nonsensical.<br><br>Please provide a demonstration of a class that=
<i>must</i> be virtually inherited in all places where it gets used as a b=
ase class. Where <i>all</i> non-virtual inheritance of such a class would b=
e as clear a mistake as those caught by `override`.<br><br>You could sugges=
t a "lighter" version of this `virtual class` notion, where you only get a =
compile error if there are multiple, non-virtual inheritances of the same b=
ase class. However, I would again like to see a base class where, by the na=
ture of that base class, this would <i>always</i> be a problem.<span class=
=3D"HOEnZb"><font color=3D"#888888"><br></font></span></div></div><span cla=
ss=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/05407ce7-891e-4355-a5de-d58a7f8f947e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/0540=
7ce7-891e-4355-<wbr>a5de-d58a7f8f947e%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an 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/CA%2BfGSbP8Og_on3a%3D06Y18C7-VgwqHhOq=
MkxrUeYeuEJuq5n3Qg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BfGSb=
P8Og_on3a%3D06Y18C7-VgwqHhOqMkxrUeYeuEJuq5n3Qg%40mail.gmail.com</a>.<br>
<br><!--end of _originalContent --></div></body></html>
<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/20170620181936.5132345.50796.31419%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20170620181936.5132345.50796.31419%40gm=
ail.com</a>.<br />
.
Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 20 Jun 2017 14:27:29 -0400
Raw View
--94eb2c18975a7debd905526867bd
Content-Type: text/plain; charset="UTF-8"
On Tue, Jun 20, 2017 at 11:54 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> Please provide a demonstration of a class that *must* be virtually
> inherited in all places where it gets used as a base class. Where *all*
> non-virtual inheritance of such a class would be as clear a mistake as
> those caught by `override`.
>
I'm not voicing whether I think this feature is useful or not, but the
common example types that are often argued "should" always use virtual
inheritance are tag-dispatch types and exception base classes, and the
rationale is solid (dispatching in the tag-dispatch case and catching in
the exception case shouldn't be ambiguous via duplicate bases). That said,
not all people buy into with that rationale and also if you know your whole
program and all concepts/exceptions involved, you can avoid the virtual
inheritance.
--
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/CANh8DEkPNJvoQsy6oqmDVBWg41TUN8SQktcKd1rETE1MCXqHJg%40mail.gmail.com.
--94eb2c18975a7debd905526867bd
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 T=
ue, Jun 20, 2017 at 11:54 AM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></=
span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Please pro=
vide a demonstration of a class that <i>must</i> be virtually inherited in =
all places where it gets used as a base class. Where <i>all</i> non-virtual=
inheritance of such a class would be as clear a mistake as those caught by=
`override`.<br></div></div></blockquote><div><br></div><div>I'm not vo=
icing whether I think this feature is useful or not, but the common example=
types that are often argued "should" always use virtual inherita=
nce are tag-dispatch types and exception base classes, and the rationale is=
solid (dispatching in the tag-dispatch case and catching in the exception =
case shouldn't be ambiguous via duplicate bases). That said, not all pe=
ople buy into with that rationale and also if you know your whole program a=
nd all concepts/exceptions involved, you can avoid the virtual inheritance.=
</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/CANh8DEkPNJvoQsy6oqmDVBWg41TUN8SQktcK=
d1rETE1MCXqHJg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEkPNJvoQsy6=
oqmDVBWg41TUN8SQktcKd1rETE1MCXqHJg%40mail.gmail.com</a>.<br />
--94eb2c18975a7debd905526867bd--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 20 Jun 2017 13:21:36 -0700 (PDT)
Raw View
------=_Part_1605_1341545879.1497990096794
Content-Type: multipart/alternative;
boundary="----=_Part_1606_1749838768.1497990096795"
------=_Part_1606_1749838768.1497990096795
Content-Type: text/plain; charset="UTF-8"
On Tuesday, June 20, 2017 at 2:12:43 PM UTC-4, Ricardo Andrade wrote:
>
> I found interesting that you focused on `override` and mentioned nothing
> about `final` which would much closer to the suggested `virtual` since it
> applies to classes.
>
If I understood the OP correctly, `virtual` would be used for base classes
> that due some design decision it's known ahead of time that it will fall
> into the diamond problem of multiple inheritance and virtual inheritance
> must be used on the derived classes.
> The annotation as `virtual` triggering a compiler error in this case could
> be beneficial to the users of such base class.
>
> In the same line, someone only uses `final` when the class should never be
> used as a base class due some design decision.
> So I can't provide such the demonstration you're requesting for `virtual`
> as one would not be able to provide one `final` for all its uses.
>
Which is exactly why I didn't mention class `final`: because I don't think
that we really needed that one *either*.
Function `final` means something: that any attempt to override that
function should fail. But class `final` represents the class writer trying
to demand something of the user that a user shouldn't have to accept: how
to use that class as a base class (or rather, that you can't).
Deriving from a class in C++ means something different from other
languages; that's why multiple inheritance is not a bug in C++. It is a
perfectly legitimate mechanism for performing various actions, not all of
which involve overriding functions.
There's a reason why `vector` is not `final`. Nor is any other standard
library type; indeed, the standard expressly says that all types are
non-`final` unless otherwise noted. It is a pointless restriction on the
user's ability to use a type.
The same goes for this `virtual` keyword. If you cannot write a class for
which `virtual` inheritance is *essential* in all base class instances,
then you have no right to declare that a user must virtually inherit from
it in all base class instances.
If there is going to be a restriction, then the restriction ought to be
that, if a type inherits from this type more than once in the same
inheritance graph, then it must be declared `virtual` at all cites of
inheritance.
It's a design decision based on the problem at hand.
>
And if the design decision around multiple inheritance is bad or good,
> that's besides the point.
>
Matt Calabrese mentioned a possible example: exception base class types.
And this example, to me, shows exactly why this is wrong-headed. It's all a
matter of what the syntax is saying.
To declare that a class requires virtual inheritance as a base class is to
make a strong statement about that class. You're saying that the class is
non-functional if you don't virtually inherit from it. If the idea is
merely that you *might* use it wrong, then it shouldn't be there.
`override` is OK because it expresses the user's intent more directly.
`virtual` alone isn't enough to make sure the compiler understands the
difference between "I'm declaring a new `virtual` function" and "I'm
overriding an existing `virtual` function."
What you're talking about is entirely different. It's not about the user of
a class declaring their intent more fully. It's about the writer of a class
preemptively stopping you from doing something that *might* cause a problem.
I don't like the idea of adding syntax to the language that forces people
to use a non-optimal construct just because they *might* misuse it.
Remember: virtual inheritance isn't free. It's like making a construct that
forces all derived classes to declare all their functions `virtual`, just
because they *might* not do so in the cases that need 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/45393a62-aada-4778-a8d8-5025a6327d7b%40isocpp.org.
------=_Part_1606_1749838768.1497990096795
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, June 20, 2017 at 2:12:43 PM UTC-4, Ricardo And=
rade 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 =
found interesting that you focused on `override` and mentioned nothing abou=
t `final` which would much closer to the suggested `virtual` since it appli=
es to classes.</div></blockquote><div></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div>If I understood the OP correctly, `virt=
ual` would be used for base classes that due some design decision it's =
known ahead of time that it will fall into the diamond problem of multiple =
inheritance and virtual inheritance must be used on the derived classes.</d=
iv><div>The annotation as `virtual` triggering a compiler error in this cas=
e could be beneficial to the users of such base class.</div><div><br></div>=
<div>In the same line, someone only uses `final` when the class should neve=
r be used as a base class due some design decision.</div><div>So I can'=
t provide such the demonstration you're requesting for `virtual` as one=
would not be able to provide one `final` for all its uses.<br></div></div>=
</blockquote><div><br>Which is exactly why I didn't mention class `fina=
l`: because I don't think that we really needed that one <i>either</i>.=
<br><br>Function `final` means something: that any attempt to override that=
function should fail. But class `final` represents the class writer trying=
to demand something of the user that a user shouldn't have to accept: =
how to use that class as a base class (or rather, that you can't).<br><=
br>Deriving from a class in C++ means something different from other langua=
ges; that's why multiple inheritance is not a bug in C++. It is a perfe=
ctly legitimate mechanism for performing various actions, not all of which =
involve overriding functions.<br><br>There's a reason why `vector` is n=
ot `final`. Nor is any other standard library type; indeed, the standard ex=
pressly says that all types are non-`final` unless otherwise noted. It is a=
pointless restriction on the user's ability to use a type.<br><br>The =
same goes for this `virtual` keyword. If you cannot write a class for which=
`virtual` inheritance is <i>essential</i> in all base class instances, the=
n you have no right to declare that a user must virtually inherit from it i=
n all base class instances.<br><br>If there is going to be a restriction, t=
hen the restriction ought to be that, if a type inherits from this type mor=
e than once in the same inheritance graph, then it must be declared `virtua=
l` at all cites of inheritance.<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div></div><div></div><div>It's a desig=
n decision based on the problem at hand. <br></div></div></blockquote><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>And if the de=
sign decision around multiple inheritance is bad or good, that's beside=
s the point.<br></div></div></blockquote><div><br>Matt Calabrese mentioned =
a possible example: exception base class types. And this example, to me, sh=
ows exactly why this is wrong-headed. It's all a matter of what the syn=
tax is saying.<br><br>To declare that a class requires virtual inheritance =
as a base class is to make a strong statement about that class. You're =
saying that the class is non-functional if you don't virtually inherit =
from it. If the idea is merely that you <i>might</i> use it wrong, then it =
shouldn't be there.<br><br>`override` is OK because it expresses the us=
er's intent more directly. `virtual` alone isn't enough to make sur=
e the compiler understands the difference between "I'm declaring a=
new `virtual` function" and "I'm overriding an existing `vir=
tual` function."<br><br>What you're talking about is entirely diff=
erent. It's not about the user of a class declaring their intent more f=
ully. It's about the writer of a class preemptively stopping you from d=
oing something that <i>might</i> cause a problem.<br><br>I don't like t=
he idea of adding syntax to the language that forces people to use a non-op=
timal construct just because they <i>might</i> misuse it. Remember: virtual=
inheritance isn't free. It's like making a construct that forces a=
ll derived classes to declare all their functions `virtual`, just because t=
hey <i>might</i> not do so in the cases that need it.<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/45393a62-aada-4778-a8d8-5025a6327d7b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/45393a62-aada-4778-a8d8-5025a6327d7b=
%40isocpp.org</a>.<br />
------=_Part_1606_1749838768.1497990096795--
------=_Part_1605_1341545879.1497990096794--
.
Author: wei zhang <lala.willzhang@gmail.com>
Date: Tue, 20 Jun 2017 20:46:06 -0700 (PDT)
Raw View
------=_Part_3448_1866948552.1498016766876
Content-Type: multipart/alternative;
boundary="----=_Part_3449_1098717052.1498016766876"
------=_Part_3449_1098717052.1498016766876
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2017=E5=B9=B46=E6=9C=8820=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8B=E5=8D=884:48:40=EF=BC=8Cwei zhang=E5=86=99=E9=81=93=EF=BC=9A
>
> I suggest a virtual class declaration that it can only be inherited with=
=20
> virtual keyword.
>
> Sample
>
> virtual class BaseObject{
> public:
> void * GetBasePtr(){return this;};
> protected:
> int my_value;
> };
> =20
>
>
> You must virtual inherits this class otherwise compile will report error.=
=20
> Sample:
> class MyClass:public virtual BaseObject
> {
> ...
> }
>
> The MyClass will compile error without the virtual keyword.
>
> With this restriction, architecture programmer can restrict that his Base=
=20
> Class won't have poly-inherit problem.
>
>
> You can also combine virtual with abstract. So like
> virtual abstract class BaseObject{
> ...
> };
>
>
>
>
>
--=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/61842e82-36c8-45ec-b8a6-68b52f4b9060%40isocpp.or=
g.
------=_Part_3449_1098717052.1498016766876
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B46=E6=9C=8820=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=884:48:40=EF=BC=8Cwei zhang=E5=
=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">I suggest a virtual class declaration that it can only be inheri=
ted with virtual keyword.<div><br></div><div>Sample</div><div><br></div><di=
v><div 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><div><=
span style=3D"background-color:rgb(255,255,255);font-family:Arial,Helvetica=
,sans-serif"><span style=3D"color:#008">virtual</span><span style=3D"color:=
#000"> </span><span style=3D"color:#008">class</span><span style=3D"color:#=
000"> </span><span style=3D"color:#606">BaseObject</span><span style=3D"col=
or:#660">{</span><span style=3D"color:#000"><br></span><span style=3D"color=
:#008">public</span><span style=3D"color:#660">:</span><span style=3D"color=
:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">void</span><span=
style=3D"color:#000"> </span><span style=3D"color:#660">*</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#606">GetBasePtr</span><span =
style=3D"color:#660">(){</span><span style=3D"color:#008">return</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#008">this</span><span =
style=3D"color:#660">;};</span><span style=3D"color:#000"><br></span><span =
style=3D"color:#008">protected</span><span style=3D"color:#660">:</span><sp=
an style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008"=
>int</span><span style=3D"color:#000"> my_value</span><span style=3D"color:=
#660">;</span><span style=3D"color:#000"><br></span><span style=3D"color:#6=
60">};</span></span></div></code><div style=3D"background-color:rgb(255,255=
,255)">=C2=A0 =C2=A0=C2=A0</div></div><br></div><div><br><div>You must virt=
ual inherits this class otherwise compile will report error. =C2=A0</div></=
div><div>Sample:</div><div><div 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><div><span style=3D"color:#008">class</span><span style=
=3D"color:#000"> </span><span style=3D"color:#606">MyClass</span><span styl=
e=3D"color:#660">:</span><span style=3D"color:#008">public</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#008">virtual</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#606">BaseObject</span><span=
style=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span s=
tyle=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#660">...</span>=
<span style=3D"color:#000"><br></span><span style=3D"color:#660">}</span><s=
pan style=3D"color:#000"><br></span></div></code></div><br>The MyClass will=
compile error without the virtual keyword.</div><div><br></div><div>With t=
his restriction, architecture programmer can restrict that his Base Class w=
on't have poly-inherit problem.</div><div><br></div><div><br></div><div=
>You can also combine virtual with abstract. =C2=A0So like</div><div>virtua=
l abstract class BaseObject{</div><div>...</div><div>};</div><div><br></div=
><div><br></div><div><br></div><div><br></div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/61842e82-36c8-45ec-b8a6-68b52f4b9060%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/61842e82-36c8-45ec-b8a6-68b52f4b9060=
%40isocpp.org</a>.<br />
------=_Part_3449_1098717052.1498016766876--
------=_Part_3448_1866948552.1498016766876--
.
Author: wei zhang <lala.willzhang@gmail.com>
Date: Tue, 20 Jun 2017 21:05:50 -0700 (PDT)
Raw View
------=_Part_4848_1604887947.1498017950689
Content-Type: multipart/alternative;
boundary="----=_Part_4849_391434953.1498017950690"
------=_Part_4849_391434953.1498017950690
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
The reason we must force programmer to virtual inherits a base class is tha=
t
The object system (or alike) requires that. In game programming, we need=
=20
to manage a lot of objects. Normally we would provide a BaseObject class=
=20
that would record basic informations like objId or other things. However,=
=20
if a user inherit the BaseObject accidently like polymorph style, the=20
object manager will goes faulty. So that the system requires the=20
BaseObject be virtual for anyone want to register the newed object into it.
Without the virtual keyword. We still can require the same thing. it would=
=20
be like
class VirtualObject {
int objid;=20
...
}
class BaseObject:public virtual VirtualObject
{
// normally there's nothing
}
But first, it forces virtual without a noticeable thing when user inherits=
=20
BaseObject.
Second, the functional class is VirtualObject, but user need to inherits=20
BaseObject. =20
Third, you cannot forbid user inheirting VirtualObject directly.
=E5=9C=A8 2017=E5=B9=B46=E6=9C=8820=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC=
+8=E4=B8=8B=E5=8D=884:48:40=EF=BC=8Cwei zhang=E5=86=99=E9=81=93=EF=BC=9A
>
> I suggest a virtual class declaration that it can only be inherited with=
=20
> virtual keyword.
>
> Sample
>
> virtual class BaseObject{
> public:
> void * GetBasePtr(){return this;};
> protected:
> int my_value;
> };
> =20
>
>
> You must virtual inherits this class otherwise compile will report error.=
=20
> Sample:
> class MyClass:public virtual BaseObject
> {
> ...
> }
>
> The MyClass will compile error without the virtual keyword.
>
> With this restriction, architecture programmer can restrict that his Base=
=20
> Class won't have poly-inherit problem.
>
>
> You can also combine virtual with abstract. So like
> virtual abstract class BaseObject{
> ...
> };
>
>
>
>
>
--=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/7f2700d4-3d9a-4f08-b1c5-f04a2d4c5c9c%40isocpp.or=
g.
------=_Part_4849_391434953.1498017950690
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The reason we must force programmer to virtual inherits a =
base class is that<div>The object system (or alike) requires that. =C2=A0In=
game programming, we need to manage a lot of objects. =C2=A0Normally we wo=
uld provide a BaseObject class that would record basic informations like ob=
jId or other things. =C2=A0However, =C2=A0if a user inherit the BaseObject =
accidently like polymorph style, =C2=A0the object manager will goes faulty.=
=C2=A0So that the system requires the BaseObject be virtual for anyone wan=
t to register the newed object into it.</div><div>Without the virtual keywo=
rd. =C2=A0We still can require the same thing. it would be like</div><div><=
br></div><div><div style=3D"border-width: 1px; border-style: solid; border-=
color: rgb(187, 187, 187); background-color: rgb(250, 250, 250); word-wrap:=
break-word;"><code><span style=3D"color: rgb(0, 0, 136);">class</span><spa=
n style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(102=
, 0, 102);">VirtualObject</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0=
</span><span style=3D"color: rgb(102, 102, 0);">{</span><span style=3D"colo=
r: rgb(0, 0, 0);"><br>=C2=A0 =C2=A0</span><span style=3D"color: rgb(0, 0, 1=
36);">int</span><span style=3D"color: rgb(0, 0, 0);">=C2=A0objid</span><spa=
n style=3D"color: rgb(102, 102, 0);">;</span><span style=3D"color: rgb(0, 0=
, 0);">=C2=A0<br>=C2=A0 =C2=A0</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=
></span><span style=3D"color: rgb(0, 0, 136);">class</span><span style=3D"c=
olor: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(102, 0, 102);">=
BaseObject</span><span style=3D"color: rgb(102, 102, 0);">:</span><span sty=
le=3D"color: rgb(0, 0, 136);">public</span><span style=3D"color: rgb(0, 0, =
0);">=C2=A0</span><span style=3D"color: rgb(0, 0, 136);">virtual</span><spa=
n style=3D"color: rgb(0, 0, 0);">=C2=A0</span><span style=3D"color: rgb(102=
, 0, 102);">VirtualObject</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</span><span style=3D"color: rgb(136, 0, 0=
);">// normally there's nothing</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><br></span></code></div>But first, it forces =
virtual without a noticeable thing when user inherits BaseObject.</div><div=
>Second, the functional class is VirtualObject, but user need to inherits B=
aseObject. =C2=A0</div><div>Third, you cannot forbid user =C2=A0inheirting =
VirtualObject directly.</div><br>=E5=9C=A8 2017=E5=B9=B46=E6=9C=8820=E6=97=
=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=884:48:40=EF=BC=8Cwei z=
hang=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr">I suggest a virtual class declaration that it can only be=
inherited with virtual keyword.<div><br></div><div>Sample</div><div><br></=
div><div><div style=3D"background-color:rgb(250,250,250);border-color:rgb(1=
87,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code=
><div><span style=3D"background-color:rgb(255,255,255);font-family:Arial,He=
lvetica,sans-serif"><span style=3D"color:#008">virtual</span><span style=3D=
"color:#000"> </span><span style=3D"color:#008">class</span><span style=3D"=
color:#000"> </span><span style=3D"color:#606">BaseObject</span><span style=
=3D"color:#660">{</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#008">public</span><span style=3D"color:#660">:</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">void</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#660">*</span><=
span style=3D"color:#000"> </span><span style=3D"color:#606">GetBasePtr</sp=
an><span style=3D"color:#660">(){</span><span style=3D"color:#008">return</=
span><span style=3D"color:#000"> </span><span style=3D"color:#008">this</sp=
an><span style=3D"color:#660">;};</span><span style=3D"color:#000"><br></sp=
an><span style=3D"color:#008">protected</span><span style=3D"color:#660">:<=
/span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"co=
lor:#008">int</span><span style=3D"color:#000"> my_value</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#660">};</span></span></div></code><div style=3D"background-color=
:rgb(255,255,255)">=C2=A0 =C2=A0=C2=A0</div></div><br></div><div><br><div>Y=
ou must virtual inherits this class otherwise compile will report error. =
=C2=A0</div></div><div>Sample:</div><div><div 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><div><span style=3D"color:#008">class</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#606">MyClass</sp=
an><span style=3D"color:#660">:</span><span style=3D"color:#008">public</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#008">virtual</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#606">BaseObjec=
t</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">{<=
/span><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#66=
0">...</span><span style=3D"color:#000"><br></span><span style=3D"color:#66=
0">}</span><span style=3D"color:#000"><br></span></div></code></div><br>The=
MyClass will compile error without the virtual keyword.</div><div><br></di=
v><div>With this restriction, architecture programmer can restrict that his=
Base Class won't have poly-inherit problem.</div><div><br></div><div><=
br></div><div>You can also combine virtual with abstract. =C2=A0So like</di=
v><div>virtual abstract class BaseObject{</div><div>...</div><div>};</div><=
div><br></div><div><br></div><div><br></div><div><br></div></div></blockquo=
te></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/7f2700d4-3d9a-4f08-b1c5-f04a2d4c5c9c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7f2700d4-3d9a-4f08-b1c5-f04a2d4c5c9c=
%40isocpp.org</a>.<br />
------=_Part_4849_391434953.1498017950690--
------=_Part_4848_1604887947.1498017950689--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 21 Jun 2017 06:40:52 -0700 (PDT)
Raw View
------=_Part_5012_1439017340.1498052452733
Content-Type: multipart/alternative;
boundary="----=_Part_5013_1382241760.1498052452733"
------=_Part_5013_1382241760.1498052452733
Content-Type: text/plain; charset="UTF-8"
On Wednesday, June 21, 2017 at 12:05:50 AM UTC-4, wei zhang wrote:
>
> The reason we must force programmer to virtual inherits a base class is
> that
> The object system (or alike) requires that. In game programming, we need
> to manage a lot of objects.
>
And in game programming, you would normally avoid virtual inheritance *like
the plague*. At least, you'd avoid it for any object that's going to be
used in a hot loop.
> Normally we would provide a BaseObject class that would record basic
> informations like objId or other things. However, if a user inherit the
> BaseObject accidently like polymorph style, the object manager will goes
> faulty. So that the system requires the BaseObject be virtual for anyone
> want to register the newed object into it.
>
From what you said, it doesn't *require* that it use virtual inheritance at
all. It merely requires that virtual inheritance be used *if and only if*
you include the same base class from two different sources. There's a
difference between forcing someone to use a technique when not using it
would be broken, and forcing someone to use a technique even when not using
it *wouldn't* be broken.
Why should a user be prevented from deriving non-virtually from BaseObject,
when they know it will be completely safe for them? Why do you want to
prevent users from writing perfectly valid, reasonable, functional, and
*performant* code?
C++ is not Java; we do not *preemptively* make people's code slower just
because they *might* misuse something.
That's why I say the feature should be `unique`: if this class appears in a
class's list of base classes, it shall either appear exactly once or it
shall be virtually inherited in all places where it does appear. It
therefore ensures unambiguous conversion of `T` into `BaseClass`.
It would also fit better syntactically with class `final`, since it could
just be another special identifier:
class BaseObject unique
{
};
--
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/887454a9-f3d3-4d46-9a30-c0d50c47f902%40isocpp.org.
------=_Part_5013_1382241760.1498052452733
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, June 21, 2017 at 12:05:50 AM UTC-4, wei zhan=
g 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">The r=
eason we must force programmer to virtual inherits a base class is that<div=
>The object system (or alike) requires that. =C2=A0In game programming, we =
need to manage a lot of objects.</div></div></blockquote><div><br>And in ga=
me programming, you would normally avoid virtual inheritance <i>like the pl=
ague</i>. At least, you'd avoid it for any object that's going to b=
e used in a hot loop.<br>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;"><div dir=3D"ltr"><div>Normally we would provide a BaseObject class t=
hat would record basic informations like objId or other things. =C2=A0Howev=
er, =C2=A0if a user inherit the BaseObject accidently like polymorph style,=
=C2=A0the object manager will goes faulty. =C2=A0So that the system requir=
es the BaseObject be virtual for anyone want to register the newed object i=
nto it.</div></div></blockquote><div><br>From what you said, it doesn't=
<i>require</i> that it use virtual inheritance at all. It merely requires =
that virtual inheritance be used <i>if and only if</i> you include the same=
base class from two different sources. There's a difference between fo=
rcing someone to use a technique when not using it would be broken, and for=
cing someone to use a technique even when not using it <i>wouldn't</i> =
be broken.<br><br>Why should a user be prevented from deriving non-virtuall=
y from BaseObject, when they know it will be completely safe for them? Why =
do you want to prevent users from writing perfectly valid, reasonable, func=
tional, and <i>performant</i> code?<br><br>C++ is not Java; we do not <i>pr=
eemptively</i> make people's code slower just because they <i>might</i>=
misuse something.<br><br>That's why I say the feature should be `uniqu=
e`: if this class appears in a class's list of base classes, it shall e=
ither appear exactly once or it shall be virtually inherited in all places =
where it does appear. It therefore ensures unambiguous conversion of `T` in=
to `BaseClass`.<br><br>It would also fit better syntactically with class `f=
inal`, since it could just be another special identifier:<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-word;" class=
=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">BaseObject</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> unique<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><span style=3D"color: #660=
;" class=3D"styled-by-prettify">};</span></div></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/887454a9-f3d3-4d46-9a30-c0d50c47f902%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/887454a9-f3d3-4d46-9a30-c0d50c47f902=
%40isocpp.org</a>.<br />
------=_Part_5013_1382241760.1498052452733--
------=_Part_5012_1439017340.1498052452733--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Thu, 29 Jun 2017 19:26:08 -0700 (PDT)
Raw View
------=_Part_119_589743139.1498789568312
Content-Type: multipart/alternative;
boundary="----=_Part_120_536153063.1498789568312"
------=_Part_120_536153063.1498789568312
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2017=E5=B9=B46=E6=9C=8821=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8A=E5=8D=884:21:36=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Tuesday, June 20, 2017 at 2:12:43 PM UTC-4, Ricardo Andrade wrote:
>>
>> I found interesting that you focused on `override` and mentioned nothing=
=20
>> about `final` which would much closer to the suggested `virtual` since i=
t=20
>> applies to classes.
>>
> If I understood the OP correctly, `virtual` would be used for base classe=
s=20
>> that due some design decision it's known ahead of time that it will fall=
=20
>> into the diamond problem of multiple inheritance and virtual inheritance=
=20
>> must be used on the derived classes.
>> The annotation as `virtual` triggering a compiler error in this case=20
>> could be beneficial to the users of such base class.
>>
>> In the same line, someone only uses `final` when the class should never=
=20
>> be used as a base class due some design decision.
>> So I can't provide such the demonstration you're requesting for `virtual=
`=20
>> as one would not be able to provide one `final` for all its uses.
>>
>
> Which is exactly why I didn't mention class `final`: because I don't thin=
k=20
> that we really needed that one *either*.
>
> Function `final` means something: that any attempt to override that=20
> function should fail. But class `final` represents the class writer tryin=
g=20
> to demand something of the user that a user shouldn't have to accept: how=
=20
> to use that class as a base class (or rather, that you can't).
>
> Then you'd reject qualifiers and `constexpr`, similarly. They do introduc=
e=20
restrictions to allow some code patterns hardly existed in a language lack=
=20
of them.
For example, if you don't have explicit `final` annotation in the class=20
definitions, you have to rely on automatic devirtualization to achieve same=
=20
effect. Similarly, if you don't have qualifiers in the type system, you=20
have to rely on qualifier inference to achieve parts of the same effect. If=
=20
you don't have explicit `constexpr` to inform the implementation of=20
constant expressions in general, you have to rely on general partial=20
evaluation. The point is, at least for C++, all of are *very *difficult to=
=20
implement (if not impossible) with enough availability in reality, without=
=20
aid of explicit annotation in the core language; and explicit notation also=
=20
lead to saner interface and more readable code (hopefully). So if not=20
standardized, users' may never have possibilities to use them in real=20
world, with any dialects provided, even they have quite clear and=20
reasonable needs. Note there are differences among these features (e.g.=20
whether they have effects only on observable behavior of the programs), but=
=20
they don't invalidate the point.
On the other hand, `final` is perfectly appropriate in cases where the=20
classes in the hierarchy are all internal implementation details, rather=20
than as parts of *public *interface. (This should be at least already=20
popular in contemporary standard library implementations.) For the reasons=
=20
you mentioned, I'm not sure current `final` is *only *appropriate for such=
=20
cases, but if the `final` is specified only having effect on *public=20
inheritance*, it would be more acceptable, though adding `final` in the=20
standard library massively can break currently well-defined program (e.g.=
=20
my code has used inheritance of `u16string`, as a hack for mixin).
Deriving from a class in C++ means something different from other=20
> languages; that's why multiple inheritance is not a bug in C++. It is a=
=20
> perfectly legitimate mechanism for performing various actions, not all of=
=20
> which involve overriding functions.
>
> There's a reason why `vector` is not `final`. Nor is any other standard=
=20
> library type; indeed, the standard expressly says that all types are=20
> non-`final` unless otherwise noted. It is a pointless restriction on the=
=20
> user's ability to use a type.
>
> The same goes for this `virtual` keyword. If you cannot write a class for=
=20
> which `virtual` inheritance is *essential* in all base class instances,=
=20
> then you have no right to declare that a user must virtually inherit from=
=20
> it in all base class instances.
>
> If there is going to be a restriction, then the restriction ought to be=
=20
> that, if a type inherits from this type more than once in the same=20
> inheritance graph, then it must be declared `virtual` at all cites of=20
> inheritance.
>
> What if this is violated? UB? Or something other that cannot be *possibly=
=20
*implemented in general?
It's a design decision based on the problem at hand.=20
>>
> And if the design decision around multiple inheritance is bad or good,=20
>> that's besides the point.
>>
>
> Matt Calabrese mentioned a possible example: exception base class types.=
=20
> And this example, to me, shows exactly why this is wrong-headed. It's all=
a=20
> matter of what the syntax is saying.
>
> To declare that a class requires virtual inheritance as a base class is t=
o=20
> make a strong statement about that class. You're saying that the class is=
=20
> non-functional if you don't virtually inherit from it. If the idea is=20
> merely that you *might* use it wrong, then it shouldn't be there.
>
> No.
It is true that the restrictions should only be right in quite limited=20
cases. But also importantly, lack of them would cause real problems.
For exception base classes as parts of *public *interface (esp. for which=
=20
are intended as base classes), missing `virtual` before the *base-specifier=
*=20
is almost certainly a mistake, not only "might". It is regrettable that=20
std::exception is inherited non-virtually in the standard library, which=20
have already cause problems on NIH/ABI compatibility vs. overhead, etc.=20
(Why boost::exception?)
For tag dispatching types, mandatory `virtual` reduces mistakes, and can be=
=20
the only intentional way for some bases. However there is one more problem:=
=20
I have no luck about bloated code without hacking on the implementation=20
(and this=20
<https://stackoverflow.com/questions/33852593/tag-dispatching-based-special=
ization-for-platform-identification-and-emulation-i>is=20
still not resolved). Note all the inheritance is known during translation=
=20
and no RTTI is expected, so no runtime metadata (vtable-like stuff) is=20
needed. So I want some more attributes here, not only the proposed=20
`virtual`. Note that, even if with only this `virtual`, the implementation=
=20
would be already able to optimize (theoretically), with expense of altering=
=20
to new ABI in generated code, which is totally insane (breaking=20
compatiblity) if something like `virtual` here is not exist.
`override` is OK because it expresses the user's intent more directly.=20
> `virtual` alone isn't enough to make sure the compiler understands the=20
> difference between "I'm declaring a new `virtual` function" and "I'm=20
> overriding an existing `virtual` function."
>
> What you're talking about is entirely different. It's not about the user=
=20
> of a class declaring their intent more fully. It's about the writer of a=
=20
> class preemptively stopping you from doing something that *might* cause a=
=20
> problem.
>
> I don't like the idea of adding syntax to the language that forces people=
=20
> to use a non-optimal construct just because they *might* misuse it.=20
> Remember: virtual inheritance isn't free. It's like making a construct th=
at=20
> forces all derived classes to declare all their functions `virtual`, just=
=20
> because they *might* not do so in the cases that need it.
>
--=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/7a900c49-97ec-4625-8e22-27b9cd2f97e4%40isocpp.or=
g.
------=_Part_120_536153063.1498789568312
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2017=E5=B9=B46=E6=9C=8821=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=884:21:36=EF=BC=8CNicol Bolas=E5=
=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">On Tuesday, June 20, 2017 at 2:12:43 PM UTC-4, Ricardo Andrade w=
rote:<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 found inter=
esting that you focused on `override` and mentioned nothing about `final` w=
hich would much closer to the suggested `virtual` since it applies to class=
es.</div></blockquote><div></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div>If I understood the OP correctly, `virtual` would be us=
ed for base classes that due some design decision it's known ahead of t=
ime that it will fall into the diamond problem of multiple inheritance and =
virtual inheritance must be used on the derived classes.</div><div>The anno=
tation as `virtual` triggering a compiler error in this case could be benef=
icial to the users of such base class.</div><div><br></div><div>In the same=
line, someone only uses `final` when the class should never be used as a b=
ase class due some design decision.</div><div>So I can't provide such t=
he demonstration you're requesting for `virtual` as one would not be ab=
le to provide one `final` for all its uses.<br></div></div></blockquote><di=
v><br>Which is exactly why I didn't mention class `final`: because I do=
n't think that we really needed that one <i>either</i>.<br><br>Function=
`final` means something: that any attempt to override that function should=
fail. But class `final` represents the class writer trying to demand somet=
hing of the user that a user shouldn't have to accept: how to use that =
class as a base class (or rather, that you can't).<br><br></div></div><=
/blockquote><div>Then you'd reject qualifiers and `constexpr`, similarl=
y. They do introduce restrictions to allow some code patterns hardly existe=
d in a language lack of them.</div><div><br></div><div>For example, if you =
don't have explicit `final` annotation in the class definitions, you ha=
ve to rely on automatic devirtualization to achieve same effect. Similarly,=
if you don't have qualifiers in the type system, you have to rely on q=
ualifier inference to achieve parts of the same effect. If you don't ha=
ve explicit `constexpr` to inform the implementation of constant expression=
s in general, you have to rely on general partial evaluation. The point is,=
at least for C++, all of are <i>very </i>difficult to implement (if not im=
possible) with enough availability in reality, without aid of explicit anno=
tation in the core language; and explicit notation also lead to saner inter=
face and more readable code (hopefully). So if not standardized, users'=
may never have possibilities to use them in real world, with any dialects =
provided, even they have quite clear and reasonable needs. Note there are d=
ifferences among these features (e.g. whether they have effects only on obs=
ervable behavior of the programs), but they don't invalidate the point.=
<br></div><div><br></div><div><div>On the other hand,=C2=A0 `final` is perf=
ectly appropriate in cases where the classes in the hierarchy are all inter=
nal implementation details, rather than as parts of <i>public </i>interface=
.. (This should be at least already popular in contemporary standard library=
implementations.) For the reasons you mentioned, I'm not sure current =
`final` is <i>only </i>appropriate for such cases, but if the `final` is=20
specified only having effect on <i>public inheritance</i>, it would be=20
more acceptable, though adding `final` in the=20
standard library massively can break currently well-defined program=20
(e.g. my code has used inheritance of `u16string`, as a hack for mixin).<br=
></div> </div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div>Deriving from a class in C++ means something different=
from other languages; that's why multiple inheritance is not a bug in =
C++. It is a perfectly legitimate mechanism for performing various actions,=
not all of which involve overriding functions.<br><br>There's a reason=
why `vector` is not `final`. Nor is any other standard library type; indee=
d, the standard expressly says that all types are non-`final` unless otherw=
ise noted. It is a pointless restriction on the user's ability to use a=
type.<br><br>The same goes for this `virtual` keyword. If you cannot write=
a class for which `virtual` inheritance is <i>essential</i> in all base cl=
ass instances, then you have no right to declare that a user must virtually=
inherit from it in all base class instances.<br><br>If there is going to b=
e a restriction, then the restriction ought to be that, if a type inherits =
from this type more than once in the same inheritance graph, then it must b=
e declared `virtual` at all cites of inheritance.<br><br></div></div></bloc=
kquote><div>What if this is violated? UB? Or something other that cannot be=
<i>possibly </i>implemented in general?<br></div><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div></div><div>It&=
#39;s a design decision based on the problem at hand. <br></div></div></blo=
ckquote><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>And i=
f the design decision around multiple inheritance is bad or good, that'=
s besides the point.<br></div></div></blockquote><div><br>Matt Calabrese me=
ntioned a possible example: exception base class types. And this example, t=
o me, shows exactly why this is wrong-headed. It's all a matter of what=
the syntax is saying.<br><br>To declare that a class requires virtual inhe=
ritance as a base class is to make a strong statement about that class. You=
're saying that the class is non-functional if you don't virtually =
inherit from it. If the idea is merely that you <i>might</i> use it wrong, =
then it shouldn't be there.<br><br></div></div></blockquote><div>No.<br=
></div><div><br></div><div>It is true that the restrictions should only be =
right in quite limited cases. But also importantly, lack of them would caus=
e real problems.</div><div><br></div><div>For exception base classes as par=
ts of <i>public </i>interface (esp. for which are intended as base classes)=
, missing `virtual` before the <i>base-specifier</i> is almost certainly a =
mistake, not only "might". It=20
is regrettable that std::exception is inherited non-virtually in the=20
standard library, which have already cause problems on NIH/ABI compatibilit=
y vs. overhead, etc. (Why boost::exception?)</div><div><br></div><div>For t=
ag dispatching types, mandatory `virtual` reduces mistakes, and can be the =
only intentional way for some bases. However there is one more problem: I h=
ave no luck about bloated code without hacking on the implementation (and <=
a href=3D"https://stackoverflow.com/questions/33852593/tag-dispatching-base=
d-specialization-for-platform-identification-and-emulation-i">this </a>is s=
till not resolved). Note all the inheritance is known during translation an=
d no RTTI is expected, so no runtime metadata (vtable-like stuff) is needed=
.. So I want some more attributes here, not only the proposed `virtual`. Not=
e that, even if with only this `virtual`, the implementation would be alrea=
dy able to optimize (theoretically), with expense of altering to new ABI in=
generated code, which is totally insane (breaking compatiblity) if somethi=
ng like `virtual` here is not exist.<br></div><br><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div>`override` is OK because it expre=
sses the user's intent more directly. `virtual` alone isn't enough =
to make sure the compiler understands the difference between "I'm =
declaring a new `virtual` function" and "I'm overriding an ex=
isting `virtual` function."<br><br>What you're talking about is en=
tirely different. It's not about the user of a class declaring their in=
tent more fully. It's about the writer of a class preemptively stopping=
you from doing something that <i>might</i> cause a problem.<br><br>I don&#=
39;t like the idea of adding syntax to the language that forces people to u=
se a non-optimal construct just because they <i>might</i> misuse it. Rememb=
er: virtual inheritance isn't free. It's like making a construct th=
at forces all derived classes to declare all their functions `virtual`, jus=
t because they <i>might</i> not do so in the cases that need it.<br></div><=
/div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7a900c49-97ec-4625-8e22-27b9cd2f97e4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7a900c49-97ec-4625-8e22-27b9cd2f97e4=
%40isocpp.org</a>.<br />
------=_Part_120_536153063.1498789568312--
------=_Part_119_589743139.1498789568312--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 30 Jun 2017 08:13:40 -0700 (PDT)
Raw View
------=_Part_383_408944322.1498835620148
Content-Type: multipart/alternative;
boundary="----=_Part_384_1337631529.1498835620149"
------=_Part_384_1337631529.1498835620149
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Thursday, June 29, 2017 at 10:26:08 PM UTC-4, FrankHB1989 wrote:
>
> =E5=9C=A8 2017=E5=B9=B46=E6=9C=8821=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 U=
TC+8=E4=B8=8A=E5=8D=884:21:36=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=
=9A
>>
>> On Tuesday, June 20, 2017 at 2:12:43 PM UTC-4, Ricardo Andrade wrote:
>>>
>>> I found interesting that you focused on `override` and mentioned nothin=
g=20
>>> about `final` which would much closer to the suggested `virtual` since =
it=20
>>> applies to classes.
>>>
>> If I understood the OP correctly, `virtual` would be used for base=20
>>> classes that due some design decision it's known ahead of time that it =
will=20
>>> fall into the diamond problem of multiple inheritance and virtual=20
>>> inheritance must be used on the derived classes.
>>> The annotation as `virtual` triggering a compiler error in this case=20
>>> could be beneficial to the users of such base class.
>>>
>>> In the same line, someone only uses `final` when the class should never=
=20
>>> be used as a base class due some design decision.
>>> So I can't provide such the demonstration you're requesting for=20
>>> `virtual` as one would not be able to provide one `final` for all its u=
ses.
>>>
>>
>> Which is exactly why I didn't mention class `final`: because I don't=20
>> think that we really needed that one *either*.
>>
>> Function `final` means something: that any attempt to override that=20
>> function should fail. But class `final` represents the class writer tryi=
ng=20
>> to demand something of the user that a user shouldn't have to accept: ho=
w=20
>> to use that class as a base class (or rather, that you can't).
>>
>> Then you'd reject qualifiers and `constexpr`, similarly. They do=20
> introduce restrictions to allow some code patterns hardly existed in a=20
> language lack of them.
>
Where's this strawman coming from?
`constexpr` has a purpose: it makes it possible to call a function in a=20
constant-expression context. It's functionality that comes with=20
restrictions, not a pure-restriction.
Class-scoped `final` does not make the class better; it makes it less=20
useful.
For example, if you don't have explicit `final` annotation in the class=20
> definitions, you have to rely on automatic devirtualization to achieve sa=
me=20
> effect.
>
Nonsense. If you annotate every virtual function with `final`, then you=20
achieve the same devirtualization effect. That's why I say that=20
class-`final` ought to do only that; it shouldn't stop you from deriving=20
from the class.
Similarly, if you don't have qualifiers in the type system, you have to=20
> rely on qualifier inference to achieve parts of the same effect. If you=
=20
> don't have explicit `constexpr` to inform the implementation of constant=
=20
> expressions in general, you have to rely on general partial evaluation. T=
he=20
> point is, at least for C++, all of are *very *difficult to implement (if=
=20
> not impossible) with enough availability in reality, without aid of=20
> explicit annotation in the core language; and explicit notation also lead=
=20
> to saner interface and more readable code (hopefully). So if not=20
> standardized, users' may never have possibilities to use them in real=20
> world, with any dialects provided, even they have quite clear and=20
> reasonable needs. Note there are differences among these features (e.g.=
=20
> whether they have effects only on observable behavior of the programs), b=
ut=20
> they don't invalidate the point.
>
> On the other hand, `final` is perfectly appropriate in cases where the=
=20
> classes in the hierarchy are all internal implementation details, rather=
=20
> than as parts of *public *interface.
>
If a class is not part of the public interface, then the user using it *at=
=20
all* is a problem; it's a violation of the interface contract.=20
Class-`final` doesn't prevent people from using it; it only stops them from=
=20
using it in one very specific way. So it's hardly a solution.
But this is an issue that will become increasingly less important. With=20
modules, users won't even have access to the names (unless they use=20
reflection to access them).
(This should be at least already popular in contemporary standard library=
=20
> implementations.) For the reasons you mentioned, I'm not sure current=20
> `final` is *only *appropriate for such cases, but if the `final` is=20
> specified only having effect on *public inheritance*, it would be more=20
> acceptable, though adding `final` in the standard library massively can=
=20
> break currently well-defined program (e.g. my code has used inheritance o=
f=20
> `u16string`, as a hack for mixin).
>
> Deriving from a class in C++ means something different from other=20
>> languages; that's why multiple inheritance is not a bug in C++. It is a=
=20
>> perfectly legitimate mechanism for performing various actions, not all o=
f=20
>> which involve overriding functions.
>>
>> There's a reason why `vector` is not `final`. Nor is any other standard=
=20
>> library type; indeed, the standard expressly says that all types are=20
>> non-`final` unless otherwise noted. It is a pointless restriction on the=
=20
>> user's ability to use a type.
>>
>> The same goes for this `virtual` keyword. If you cannot write a class fo=
r=20
>> which `virtual` inheritance is *essential* in all base class instances,=
=20
>> then you have no right to declare that a user must virtually inherit fro=
m=20
>> it in all base class instances.
>>
>> If there is going to be a restriction, then the restriction ought to be=
=20
>> that, if a type inherits from this type more than once in the same=20
>> inheritance graph, then it must be declared `virtual` at all cites of=20
>> inheritance.
>>
>> What if this is violated? UB? Or something other that cannot be *possibl=
y=20
> *implemented in general?
>
"must" in spec-speak, when applied to what users can do, usually means=20
"ill-formed if you don't do it". This is something the compiler is=20
perfectly capable of detecting.
It's a design decision based on the problem at hand.=20
>>>
>> And if the design decision around multiple inheritance is bad or good,=
=20
>>> that's besides the point.
>>>
>>
>> Matt Calabrese mentioned a possible example: exception base class types.=
=20
>> And this example, to me, shows exactly why this is wrong-headed. It's al=
l a=20
>> matter of what the syntax is saying.
>>
>> To declare that a class requires virtual inheritance as a base class is=
=20
>> to make a strong statement about that class. You're saying that the clas=
s=20
>> is non-functional if you don't virtually inherit from it. If the idea is=
=20
>> merely that you *might* use it wrong, then it shouldn't be there.
>>
>> No.
>
> It is true that the restrictions should only be right in quite limited=20
> cases. But also importantly, lack of them would cause real problems.
>
> For exception base classes as parts of *public *interface (esp. for which=
=20
> are intended as base classes), missing `virtual` before the=20
> *base-specifier* is almost certainly a mistake, not only "might". It is=
=20
> regrettable that std::exception is inherited non-virtually in the standar=
d=20
> library, which have already cause problems on NIH/ABI compatibility vs.=
=20
> overhead, etc. (Why boost::exception?)
>
For tag dispatching types, mandatory `virtual` reduces mistakes, and can be=
=20
> the only intentional way for some bases. However there is one more proble=
m:=20
> I have no luck about bloated code without hacking on the implementation=
=20
> (and this=20
> <https://stackoverflow.com/questions/33852593/tag-dispatching-based-speci=
alization-for-platform-identification-and-emulation-i>is=20
> still not resolved). Note all the inheritance is known during translation=
=20
> and no RTTI is expected, so no runtime metadata (vtable-like stuff) is=20
> needed. So I want some more attributes here, not only the proposed=20
> `virtual`. Note that, even if with only this `virtual`, the implementatio=
n=20
> would be already able to optimize (theoretically), with expense of alteri=
ng=20
> to new ABI in generated code, which is totally insane (breaking=20
> compatiblity) if something like `virtual` here is not exist.
>
Alternatively, you can just use type-lists and metaprogramming techniques=
=20
based on such things. Type-lists can be concatenated (even with=20
duplicates), so you can create "hierarchies" of such things. You can=20
constexpr query whether a type-list contains a member of a certain type,=20
and use SFINAE based on that. Or Concepts/`if constexpr`; whichever works=
=20
for you.
--=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/0d83cdb1-4529-4a03-8593-f0374fe5e5e2%40isocpp.or=
g.
------=_Part_384_1337631529.1498835620149
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, June 29, 2017 at 10:26:08 PM UTC-4, FrankHB19=
89 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">=E5=
=9C=A8 2017=E5=B9=B46=E6=9C=8821=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+8=
=E4=B8=8A=E5=8D=884:21:36=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, June 20, =
2017 at 2:12:43 PM UTC-4, Ricardo Andrade wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr">I found interesting that you focused on `over=
ride` and mentioned nothing about `final` which would much closer to the su=
ggested `virtual` since it applies to classes.</div></blockquote><div></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>If I underst=
ood the OP correctly, `virtual` would be used for base classes that due som=
e design decision it's known ahead of time that it will fall into the d=
iamond problem of multiple inheritance and virtual inheritance must be used=
on the derived classes.</div><div>The annotation as `virtual` triggering a=
compiler error in this case could be beneficial to the users of such base =
class.</div><div><br></div><div>In the same line, someone only uses `final`=
when the class should never be used as a base class due some design decisi=
on.</div><div>So I can't provide such the demonstration you're requ=
esting for `virtual` as one would not be able to provide one `final` for al=
l its uses.<br></div></div></blockquote><div><br>Which is exactly why I did=
n't mention class `final`: because I don't think that we really nee=
ded that one <i>either</i>.<br><br>Function `final` means something: that a=
ny attempt to override that function should fail. But class `final` represe=
nts the class writer trying to demand something of the user that a user sho=
uldn't have to accept: how to use that class as a base class (or rather=
, that you can't).<br><br></div></div></blockquote><div>Then you'd =
reject qualifiers and `constexpr`, similarly. They do introduce restriction=
s to allow some code patterns hardly existed in a language lack of them.</d=
iv></div></blockquote><div><br>Where's this strawman coming from?<br><b=
r>`constexpr` has a purpose: it makes it possible to call a function in a c=
onstant-expression context. It's functionality that comes with restrict=
ions, not a pure-restriction.<br><br>Class-scoped `final` does not make the=
class better; it makes it less useful.<br><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>For example, if you=
don't have explicit `final` annotation in the class definitions, you h=
ave to rely on automatic devirtualization to achieve same effect.</div></di=
v></blockquote><div><br>Nonsense. If you annotate every virtual function wi=
th `final`, then you achieve the same devirtualization effect. That's w=
hy I say that class-`final` ought to do only that; it shouldn't stop yo=
u from deriving from the class.<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div>Similarly, if you don't have quali=
fiers in the type system, you have to rely on qualifier inference to achiev=
e parts of the same effect. If you don't have explicit `constexpr` to i=
nform the implementation of constant expressions in general, you have to re=
ly on general partial evaluation. The point is, at least for C++, all of ar=
e <i>very </i>difficult to implement (if not impossible) with enough availa=
bility in reality, without aid of explicit annotation in the core language;=
and explicit notation also lead to saner interface and more readable code =
(hopefully). So if not standardized, users' may never have possibilitie=
s to use them in real world, with any dialects provided, even they have qui=
te clear and reasonable needs. Note there are differences among these featu=
res (e.g. whether they have effects only on observable behavior of the prog=
rams), but they don't invalidate the point.<br></div><div><br></div><di=
v><div>On the other hand,=C2=A0 `final` is perfectly appropriate in cases w=
here the classes in the hierarchy are all internal implementation details, =
rather than as parts of <i>public </i>interface.</div></div></div></blockqu=
ote><div><br>If a class is not part of the public interface, then the user =
using it <i>at all</i> is a problem; it's a violation of the interface =
contract. Class-`final` doesn't prevent people from using it; it only s=
tops them from using it in one very specific way. So it's hardly a solu=
tion.<br><br>But this is an issue that will become increasingly less import=
ant. With modules, users won't even have access to the names (unless th=
ey use reflection to access them).<br><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div><div>(This should be at least alrea=
dy popular in contemporary standard library implementations.) For the reaso=
ns you mentioned, I'm not sure current `final` is <i>only </i>appropria=
te for such cases, but if the `final` is=20
specified only having effect on <i>public inheritance</i>, it would be=20
more acceptable, though adding `final` in the=20
standard library massively can break currently well-defined program=20
(e.g. my code has used inheritance of `u16string`, as a hack for mixin).<br=
></div> </div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div>Deriving from a class in C++ means something different from=
other languages; that's why multiple inheritance is not a bug in C++. =
It is a perfectly legitimate mechanism for performing various actions, not =
all of which involve overriding functions.<br><br>There's a reason why =
`vector` is not `final`. Nor is any other standard library type; indeed, th=
e standard expressly says that all types are non-`final` unless otherwise n=
oted. It is a pointless restriction on the user's ability to use a type=
..<br><br>The same goes for this `virtual` keyword. If you cannot write a cl=
ass for which `virtual` inheritance is <i>essential</i> in all base class i=
nstances, then you have no right to declare that a user must virtually inhe=
rit from it in all base class instances.<br><br>If there is going to be a r=
estriction, then the restriction ought to be that, if a type inherits from =
this type more than once in the same inheritance graph, then it must be dec=
lared `virtual` at all cites of inheritance.<br><br></div></div></blockquot=
e><div>What if this is violated? UB? Or something other that cannot be <i>p=
ossibly </i>implemented in general?<br></div></div></blockquote><div><br>&q=
uot;must" in spec-speak, when applied to what users can do, usually me=
ans "ill-formed if you don't do it". This is something the co=
mpiler is perfectly capable of detecting.<br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div></div><div></div><div>It's=
a design decision based on the problem at hand. <br></div></div></blockquo=
te><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>And if the=
design decision around multiple inheritance is bad or good, that's bes=
ides the point.<br></div></div></blockquote><div><br>Matt Calabrese mention=
ed a possible example: exception base class types. And this example, to me,=
shows exactly why this is wrong-headed. It's all a matter of what the =
syntax is saying.<br><br>To declare that a class requires virtual inheritan=
ce as a base class is to make a strong statement about that class. You'=
re saying that the class is non-functional if you don't virtually inher=
it from it. If the idea is merely that you <i>might</i> use it wrong, then =
it shouldn't be there.<br><br></div></div></blockquote><div>No.<br></di=
v><div><br></div><div>It is true that the restrictions should only be right=
in quite limited cases. But also importantly, lack of them would cause rea=
l problems.</div><div><br></div><div>For exception base classes as parts of=
<i>public </i>interface (esp. for which are intended as base classes), mis=
sing `virtual` before the <i>base-specifier</i> is almost certainly a mista=
ke, not only "might". It=20
is regrettable that std::exception is inherited non-virtually in the=20
standard library, which have already cause problems on NIH/ABI compatibilit=
y vs. overhead, etc. (Why boost::exception?)</div></div></blockquote><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>For tag dispat=
ching types, mandatory `virtual` reduces mistakes, and can be the only inte=
ntional way for some bases. However there is one more problem: I have no lu=
ck about bloated code without hacking on the implementation (and <a href=3D=
"https://stackoverflow.com/questions/33852593/tag-dispatching-based-special=
ization-for-platform-identification-and-emulation-i" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'https://www.google.com/url?q\=
x3dhttps%3A%2F%2Fstackoverflow.com%2Fquestions%2F33852593%2Ftag-dispatching=
-based-specialization-for-platform-identification-and-emulation-i\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNHmBICgn6OdwGZ752L3YhdDYixqfA';return tru=
e;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F=
%2Fstackoverflow.com%2Fquestions%2F33852593%2Ftag-dispatching-based-special=
ization-for-platform-identification-and-emulation-i\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHmBICgn6OdwGZ752L3YhdDYixqfA';return true;">this </a>i=
s still not resolved). Note all the inheritance is known during translation=
and no RTTI is expected, so no runtime metadata (vtable-like stuff) is nee=
ded. So I want some more attributes here, not only the proposed `virtual`. =
Note that, even if with only this `virtual`, the implementation would be al=
ready able to optimize (theoretically), with expense of altering to new ABI=
in generated code, which is totally insane (breaking compatiblity) if some=
thing like `virtual` here is not exist.<br></div></div></blockquote><div><b=
r>Alternatively, you can just use type-lists and metaprogramming techniques=
based on such things. Type-lists can be concatenated (even with duplicates=
), so you can create "hierarchies" of such things. You can conste=
xpr query whether a type-list contains a member of a certain type, and use =
SFINAE based on that. Or Concepts/`if constexpr`; whichever works for you.<=
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/0d83cdb1-4529-4a03-8593-f0374fe5e5e2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0d83cdb1-4529-4a03-8593-f0374fe5e5e2=
%40isocpp.org</a>.<br />
------=_Part_384_1337631529.1498835620149--
------=_Part_383_408944322.1498835620148--
.