Topic: Simplify virtual inheritance rules
Author: Denis Kotov <redradist@gmail.com>
Date: Sat, 18 Mar 2017 12:31:32 -0700 (PDT)
Raw View
------=_Part_523_302603043.1489865492046
Content-Type: multipart/alternative;
boundary="----=_Part_524_1738359098.1489865492046"
------=_Part_524_1738359098.1489865492046
Content-Type: text/plain; charset=UTF-8
Hi everyone,
My proposal is to simplify virtual inheritance rules. Consider the
following class hierarchy:
<https://lh3.googleusercontent.com/-h-cp0qNBSRI/WM2Ks4N6-3I/AAAAAAAAFQo/tvd17HoV09U2dPcY6XfzaxLm3K2ITBkrwCLcB/s1600/Simplify%2Brules%2Bfor%2Bvirtual%2Binheritance.png>
and the following code:
class VirtualBase
{
public:
VirtualBase(std::string & str)
{
}
};
class Derived0 : virtual public VirtualBase
{
public:
Derived0(std::string & str)
: VirtualBase(str)
{
}
};
class Derived1 : virtual public VirtualBase
{
public:
Derived1(std::string & str)
: VirtualBase(str)
{
}
};
class ComposedDerived
: public Derived0
, public Derived1
{
public:
ComposedDerived(std::string & str)
: Derived0(str)
, Derived1(str)
, VirtualBase(str)
{
}
};
Let's inherit from ComposedDerived again:
class ComposedDerivedDerived
: public ComposedDerived
, public NewClass
{
public:
ComposedDerivedDerived(std::string & str)
: VirtualBase(str)
{
}
};
I want to simplify it like the following:
class ComposedDerivedDerived
: public ComposedDerived
, public NewClass
{
public:
ComposedDerivedDerived(std::string & str) // Here is no
VirtualBase(str)
{
}
};
*Proposal is the following:*
*Require to specify constructor for VirtualBase only if compiler find
more the one path of virtual inheritance like for C3 (on diagram) or
ComposedDerived (in code) classes*
--
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/6aa2e439-345e-4f04-8843-f38bb7b825b2%40isocpp.org.
------=_Part_524_1738359098.1489865492046
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><p class=3D"separator" style=3D"clear: both;">Hi everyone,=
</p><p class=3D"separator" style=3D"clear: both;"><br></p><p class=3D"separ=
ator" style=3D"clear: both;">My proposal is to simplify virtual inheritance=
rules. Consider the following class hierarchy:</p><div><br></div><p class=
=3D"separator" style=3D"text-align: center; clear: both;"><a imageanchor=3D=
"1" href=3D"https://lh3.googleusercontent.com/-h-cp0qNBSRI/WM2Ks4N6-3I/AAAA=
AAAAFQo/tvd17HoV09U2dPcY6XfzaxLm3K2ITBkrwCLcB/s1600/Simplify%2Brules%2Bfor%=
2Bvirtual%2Binheritance.png" style=3D"margin-left: 1em; margin-right: 1em;"=
><img src=3D"https://lh3.googleusercontent.com/-h-cp0qNBSRI/WM2Ks4N6-3I/AAA=
AAAAAFQo/tvd17HoV09U2dPcY6XfzaxLm3K2ITBkrwCLcB/s320/Simplify%2Brules%2Bfor%=
2Bvirtual%2Binheritance.png" border=3D"0" width=3D"261" height=3D"320"></a>=
</p><div><br></div><br><div>and the following code:</div><div><br></div><di=
v><div>=C2=A0 =C2=A0 class VirtualBase</div><div>=C2=A0 =C2=A0 {</div><div>=
=C2=A0 =C2=A0 public:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0VirtualBase(std:=
:string & str)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0{</div><div><br></d=
iv><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0}</div><div>=C2=A0 =C2=A0 };</div><div><=
br></div><div>=C2=A0 =C2=A0 class Derived0 : virtual public VirtualBase</di=
v><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 public:</div><div>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0Derived0(std::string & str)</div><div>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 : VirtualBase(str)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0{</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0}</div><div>=C2=A0=
=C2=A0 };</div><div><br></div><div>=C2=A0 =C2=A0 class Derived1 : virtual =
public VirtualBase</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 public=
:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0Derived1(std::string & str)</div=
><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : VirtualBase(str)</div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0{</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0}</div><div>=C2=A0 =C2=A0 };</div><div><br></div><div>=C2=A0 =C2=A0 clas=
s ComposedDerived</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0: public Derived0</d=
iv><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0, public Derived1</div><div>=C2=A0 =C2=
=A0 {</div><div>=C2=A0 =C2=A0 public:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
ComposedDerived(std::string & str)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 : Derived0(str)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 , D=
erived1(str)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 , VirtualBase(str=
)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0{</div><div><br></div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0}</div><div>=C2=A0 =C2=A0 };</div></div><div><br></div>=
<div>Let's inherit from ComposedDerived again:</div><div><br></div><div=
><div>=C2=A0 =C2=A0 class ComposedDerivedDerived</div><div>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0: public ComposedDerived</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
, public NewClass<br></div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 pub=
lic:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0ComposedDerivedDerived(std::strin=
g & str)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: VirtualBase(str)=
<br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0{</div><div><br></div><div>=C2=A0=
=C2=A0 =C2=A0 =C2=A0}</div><div>=C2=A0 =C2=A0 };</div></div><div><br></div=
><div>I want to simplify it like the following:</div><div><div><br></div><d=
iv><div>=C2=A0 =C2=A0 class ComposedDerivedDerived</div><div>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0: public ComposedDerived</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
, public NewClass</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 public:=
</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0ComposedDerivedDerived(std::string &a=
mp; str) // Here is no VirtualBase(str)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0{</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0}</div><div>=C2=A0=
=C2=A0 };</div></div></div><div><br></div><div><span style=3D"background-c=
olor: rgb(255, 255, 0);"><b>Proposal is the following:</b></span></div><div=
>=C2=A0 =C2=A0<b>Require to specify constructor for VirtualBase only if com=
piler find more the one path of virtual inheritance like for C3 (on diagram=
) or ComposedDerived (in code) classes</b></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6aa2e439-345e-4f04-8843-f38bb7b825b2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6aa2e439-345e-4f04-8843-f38bb7b825b2=
%40isocpp.org</a>.<br />
------=_Part_524_1738359098.1489865492046--
------=_Part_523_302603043.1489865492046--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 18 Mar 2017 21:45:02 +0200
Raw View
--001a113cd862c0a7a1054b068711
Content-Type: text/plain; charset=UTF-8
On 18 March 2017 at 21:31, Denis Kotov <redradist@gmail.com> wrote:
> I want to simplify it like the following:
>
> class ComposedDerivedDerived
> : public ComposedDerived
> , public NewClass
> {
> public:
> ComposedDerivedDerived(std::string & str) // Here is no
> VirtualBase(str)
> {
>
> }
> };
>
> *Proposal is the following:*
> *Require to specify constructor for VirtualBase only if compiler find
> more the one path of virtual inheritance like for C3 (on diagram) or
> ComposedDerived (in code) classes*
>
ComposedDerivedDerived didn't initialize ComposedDerived in your original
code or this modified code. Also, there's no reason that
a compiler could find an initialization for a virtual base, since that
initialization may be in a separate translation unit that the compiler
doesn't
see, so this idea doesn't work at all.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZgeRfv4zYnc%2By_Cw1-1onyj-725pq-UUizv8GVm8KQCQ%40mail.gmail.com.
--001a113cd862c0a7a1054b068711
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 18 March 2017 at 21:31, Denis Kotov <span dir=3D"ltr"><<a href=3D=
"mailto:redradist@gmail.com" target=3D"_blank">redradist@gmail.com</a>><=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I want to =
simplify it like the following:<div><div><br></div><div><div>=C2=A0 =C2=A0 =
class ComposedDerivedDerived</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0: public =
ComposedDerived</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0, public NewClass</div=
><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 public:</div><div>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0ComposedDerivedDerived(std::<wbr>string & str) // Here=
is no VirtualBase(str)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0{</div><div><b=
r></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0}</div><div>=C2=A0 =C2=A0 };</div><=
/div></div><div><br></div><div><span style=3D"background-color:rgb(255,255,=
0)"><b>Proposal is the following:</b></span></div><div>=C2=A0 =C2=A0<b>Requ=
ire to specify constructor for VirtualBase only if compiler find more the o=
ne path of virtual inheritance like for C3 (on diagram) or ComposedDerived =
(in code) classes</b></div></div></blockquote><div><br><br></div><div>Compo=
sedDerivedDerived didn't initialize ComposedDerived in your original co=
de or this modified code. Also, there's no reason that<br></div><div>a =
compiler could find an initialization for a virtual base, since that initia=
lization may be in a separate translation unit that the compiler doesn'=
t<br></div><div>see, so this idea doesn't work at all.<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/CAFk2RUZgeRfv4zYnc%2By_Cw1-1onyj-725p=
q-UUizv8GVm8KQCQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZgeRfv4z=
Ync%2By_Cw1-1onyj-725pq-UUizv8GVm8KQCQ%40mail.gmail.com</a>.<br />
--001a113cd862c0a7a1054b068711--
.
Author: Denis Kotov <redradist@gmail.com>
Date: Sat, 18 Mar 2017 14:18:26 -0700 (PDT)
Raw View
------=_Part_616_1307519651.1489871906742
Content-Type: multipart/alternative;
boundary="----=_Part_617_754500275.1489871906742"
------=_Part_617_754500275.1489871906742
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Yes your are right I have misspelled it. Should be something like this:
class ComposedDerivedDerived
: public ComposedDerived
, public NewClass
{
public:
ComposedDerivedDerived(std::string & str) // Here is no=20
VirtualBase(str)
: ComposedDerived(str),
, NewClass()
{
}
};
But I do not see any problems with separate translation unit.
We should not care about another separate unit, it is responsibility of=20
compiler that will support this rule to require an user calls a constructor=
=20
for VirtualBase.
We should not care because according to this rule we know that constructor=
=20
had been called above.
But if user want it can call it directly for backward compitability.
VirtualBase constructor should be required to call only when class inherits=
=20
from two or more classes those inhertits virtually from VirtualBase class.
=D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 18 =D0=BC=D0=B0=D1=80=D1=82=D0=
=B0 2017 =D0=B3., 21:45:04 UTC+2 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=
=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Ville Voutilainen=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
>
>
> On 18 March 2017 at 21:31, Denis Kotov <redr...@gmail.com <javascript:>>=
=20
> wrote:
>
>> I want to simplify it like the following:
>>
>> class ComposedDerivedDerived
>> : public ComposedDerived
>> , public NewClass
>> {
>> public:
>> ComposedDerivedDerived(std::string & str) // Here is no=20
>> VirtualBase(str)
>> {
>>
>> }
>> };
>>
>> *Proposal is the following:*
>> *Require to specify constructor for VirtualBase only if compiler find=
=20
>> more the one path of virtual inheritance like for C3 (on diagram) or=20
>> ComposedDerived (in code) classes*
>>
>
>
> ComposedDerivedDerived didn't initialize ComposedDerived in your original=
=20
> code or this modified code. Also, there's no reason that
> a compiler could find an initialization for a virtual base, since that=20
> initialization may be in a separate translation unit that the compiler=20
> doesn't
> see, so this idea doesn't work at all.
>
>
--=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/2340e1b0-09bd-4f5b-bf15-7605eaed858b%40isocpp.or=
g.
------=_Part_617_754500275.1489871906742
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Yes your are right I have misspelled it. Should be somethi=
ng like this:<div><br></div><div><div>=C2=A0 =C2=A0 class ComposedDerivedDe=
rived</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: public ComposedD=
erived</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0, public NewClass=
</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 public:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ComposedDeri=
vedDerived(std::<wbr>string & str) // Here is no VirtualBase(str)</div>=
<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: ComposedDeriv=
ed(str),</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0,=
NewClass()</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{</div><div>=
<br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}</div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 };</div><div><br></div><div><div>But I do not see any =
problems with separate translation unit.</div><div>We should not care about=
another separate unit, it is responsibility of compiler that will support =
this rule to require an user calls a constructor for VirtualBase.</div><div=
>We should not care because according to this rule we know that constructor=
had been called above.</div><div>But if user want it can call it directly =
for backward compitability.</div><div><br></div><div>VirtualBase constructo=
r should be required to call only when class inherits from two or more clas=
ses those inhertits virtually from VirtualBase class.</div></div><br>=D1=81=
=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 18 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 201=
7 =D0=B3., 21:45:04 UTC+2 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=
=D1=82=D0=B5=D0=BB=D1=8C Ville Voutilainen =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0=D0=BB:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<br><div><br><div class=3D"gmail_quote">On 18 March 2017 at 21:31, Denis Ko=
tov <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"i22x4yD-EQAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'javascript:';return true;" onclick=3D"this.href=3D'javascri=
pt:';return true;">redr...@gmail.com</a>></span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr">I want to simplify it like the follo=
wing:<div><div><br></div><div><div>=C2=A0 =C2=A0 class ComposedDerivedDeriv=
ed</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0: public ComposedDerived</div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0, public NewClass</div><div>=C2=A0 =C2=A0 {</div=
><div>=C2=A0 =C2=A0 public:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0ComposedDe=
rivedDerived(std::<wbr>string & str) // Here is no VirtualBase(str)</di=
v><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0{</div><div><br></div><div>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0}</div><div>=C2=A0 =C2=A0 };</div></div></div><div><br></div><=
div><span style=3D"background-color:rgb(255,255,0)"><b>Proposal is the foll=
owing:</b></span></div><div>=C2=A0 =C2=A0<b>Require to specify constructor =
for VirtualBase only if compiler find more the one path of virtual inherita=
nce like for C3 (on diagram) or ComposedDerived (in code) classes</b></div>=
</div></blockquote><div><br><br></div><div>ComposedDerivedDerived didn'=
t initialize ComposedDerived in your original code or this modified code. A=
lso, there's no reason that<br></div><div>a compiler could find an init=
ialization for a virtual base, since that initialization may be in a separa=
te translation unit that the compiler doesn't<br></div><div>see, so thi=
s idea doesn't work at all.<br></div></div><br></div></div>
</blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2340e1b0-09bd-4f5b-bf15-7605eaed858b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2340e1b0-09bd-4f5b-bf15-7605eaed858b=
%40isocpp.org</a>.<br />
------=_Part_617_754500275.1489871906742--
------=_Part_616_1307519651.1489871906742--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 19 Mar 2017 00:08:20 +0200
Raw View
On 18 March 2017 at 23:18, Denis Kotov <redradist@gmail.com> wrote:
> But I do not see any problems with separate translation unit.
You're asking for this rule:
If the constructor I call initializes the virtual base, I won't have
to. That rule is unimplementable
in the presence of separate translation units.
Furthermore, you cannot know what value the constructor you call
(would) initializes the virtual base with.
Currently, the intermediate class you initialize will not initialize
the virtual base at all, so there's a good
chance that what you're proposing is also an ABI break.
--
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/CAFk2RUZJf0Ls6dD3EE4eSTUiEET7Caa_2h2S4O7YWbBAeYP9xg%40mail.gmail.com.
.
Author: "T. C." <rs2740@gmail.com>
Date: Sat, 18 Mar 2017 15:55:24 -0700 (PDT)
Raw View
------=_Part_768_1454849518.1489877724618
Content-Type: multipart/alternative;
boundary="----=_Part_769_1018248968.1489877724618"
------=_Part_769_1018248968.1489877724618
Content-Type: text/plain; charset=UTF-8
On Saturday, March 18, 2017 at 6:08:22 PM UTC-4, Ville Voutilainen wrote:
>
> On 18 March 2017 at 23:18, Denis Kotov <redr...@gmail.com <javascript:>>
> wrote:
> > But I do not see any problems with separate translation unit.
>
> You're asking for this rule:
>
> If the constructor I call initializes the virtual base, I won't have
> to. That rule is unimplementable
> in the presence of separate translation units.
>
> Furthermore, you cannot know what value the constructor you call
> (would) initializes the virtual base with.
> Currently, the intermediate class you initialize will not initialize
> the virtual base at all, so there's a good
> chance that what you're proposing is also an ABI break.
>
I think OP's proposed rule is something like
If an indirect virtual base is a (direct or indirect) base of only one
direct base, then you can omit initializing the virtual base. Presumably in
that case you'd call the complete object constructor of said direct base so
that it initializes the virtual base, rather than the base object
constructor.
This wouldn't depend on the definition of the constructors at issue, only
the classes, and won't run into separate translation issues. It does have
plenty of other issues, though (e.g., handling of default constructible
virtual bases, initialization order issues, etc., etc.), and I don't see
how the headache is worth the minuscule benefit.
--
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/b16cfa2e-0aea-45c3-a822-87e196a10ddb%40isocpp.org.
------=_Part_769_1018248968.1489877724618
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, March 18, 2017 at 6:08:22 PM UTC-4, V=
ille Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 18 M=
arch 2017 at 23:18, Denis Kotov <<a href=3D"javascript:" target=3D"_blan=
k" gdf-obfuscated-mailto=3D"lGuVt_IFEgAJ" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
javascript:';return true;">redr...@gmail.com</a>> wrote:
<br>> But I do not see any problems with separate translation unit.
<br>
<br>You're asking for this rule:
<br>
<br>If the constructor I call initializes the virtual base, I won't hav=
e
<br>to. That rule is unimplementable
<br>in the presence of separate translation units.
<br>
<br>Furthermore, you cannot know what value the constructor you call
<br>(would) initializes the virtual base with.
<br>Currently, the intermediate class you initialize will not initialize
<br>the virtual base at all, so there's a good
<br>chance that what you're proposing is also an ABI break.
<br></blockquote><div><br></div><div>I think OP's proposed rule is some=
thing like</div><div><br></div><div>If an indirect virtual base is a (direc=
t or indirect) base of only one direct base, then you can omit initializing=
the virtual base. Presumably in that case you'd call the complete obje=
ct constructor of said direct base so that it initializes the virtual base,=
rather than the base object constructor.</div><div><br></div><div>This wou=
ldn't depend on the definition of the constructors at issue, only the c=
lasses, and won't run into separate translation issues. It does have pl=
enty of other issues, though (e.g., handling of default constructible virtu=
al bases, initialization order issues, etc., etc.), and I don't see how=
the headache is worth the minuscule benefit.</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/b16cfa2e-0aea-45c3-a822-87e196a10ddb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b16cfa2e-0aea-45c3-a822-87e196a10ddb=
%40isocpp.org</a>.<br />
------=_Part_769_1018248968.1489877724618--
------=_Part_768_1454849518.1489877724618--
.
Author: Denis Kotov <redradist@gmail.com>
Date: Sun, 19 Mar 2017 05:22:28 -0700 (PDT)
Raw View
------=_Part_758_115881469.1489926148125
Content-Type: multipart/alternative;
boundary="----=_Part_759_528400850.1489926148125"
------=_Part_759_528400850.1489926148125
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Thanks for comment *T. C.,*
But I do not agree that it is not worth to do it.
Consider situation of very long chain of inheritance. Why in this chain=20
user has to call every time constructor for *VirtualBase *?
It violates an encapsulation. User in derived class does not have to know=
=20
something about it parent long long ago ... It will just simplify=20
development of class hierarchy and make class hierarchy looks like in *Java=
=20
*or *C#* with one instance of *Base *class and similar rules.
Consider another situation where in long chain of inheritance somewhere=20
user inherite *VirtualBase *implicitly with access modifier *'protected'*=
=20
or *'private'.*
*Why user should know something about parent class ?*
=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 19 =D0=
=BC=D0=B0=D1=80=D1=82=D0=B0 2017 =D0=B3., 0:55:24 UTC+2 =D0=BF=D0=BE=D0=BB=
=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C T. C. =D0=BD=D0=B0=
=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
>
>
> On Saturday, March 18, 2017 at 6:08:22 PM UTC-4, Ville Voutilainen wrote:
>>
>> On 18 March 2017 at 23:18, Denis Kotov <redr...@gmail.com> wrote:=20
>> > But I do not see any problems with separate translation unit.=20
>>
>> You're asking for this rule:=20
>>
>> If the constructor I call initializes the virtual base, I won't have=20
>> to. That rule is unimplementable=20
>> in the presence of separate translation units.=20
>>
>> Furthermore, you cannot know what value the constructor you call=20
>> (would) initializes the virtual base with.=20
>> Currently, the intermediate class you initialize will not initialize=20
>> the virtual base at all, so there's a good=20
>> chance that what you're proposing is also an ABI break.=20
>>
>
> I think OP's proposed rule is something like
>
> If an indirect virtual base is a (direct or indirect) base of only one=20
> direct base, then you can omit initializing the virtual base. Presumably =
in=20
> that case you'd call the complete object constructor of said direct base =
so=20
> that it initializes the virtual base, rather than the base object=20
> constructor.
>
> This wouldn't depend on the definition of the constructors at issue, only=
=20
> the classes, and won't run into separate translation issues. It does have=
=20
> plenty of other issues, though (e.g., handling of default constructible=
=20
> virtual bases, initialization order issues, etc., etc.), and I don't see=
=20
> how the headache is worth the minuscule benefit.
>
--=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/25e054ca-aac4-4bcc-805a-4e1357de4f37%40isocpp.or=
g.
------=_Part_759_528400850.1489926148125
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Thanks for comment=C2=A0<b>T. C.,</b></div><div><br><=
/div><div>But I do not agree that it is not worth to do it.</div><div>Consi=
der situation of very long chain of inheritance. <span style=3D"background-=
color: rgb(255, 255, 0);">Why in this chain user has to call every time con=
structor for <b>VirtualBase </b>?</span></div><div>It violates an encapsula=
tion. User in derived class does not have to know something about it parent=
long long ago ... It will just simplify development of class hierarchy and=
make class hierarchy looks like in <b>Java </b>or <b>C#</b> with one insta=
nce of <b>Base </b>class and similar rules.</div><div><br></div><div>Consid=
er another situation where in long chain of inheritance somewhere user inhe=
rite <b>VirtualBase </b>implicitly with access modifier <b>'protected&#=
39;</b> or <b>'private'.</b></div><div><span style=3D"background-co=
lor: rgb(255, 255, 0);"><b>Why user should know something about parent clas=
s ?</b></span></div><div><br>=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=
=B5=D0=BD=D1=8C=D0=B5, 19 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2017 =D0=B3., 0:55=
:24 UTC+2 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=
=BB=D1=8C T. C. =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><br>On Saturday, March 18=
, 2017 at 6:08:22 PM UTC-4, Ville Voutilainen wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex">On 18 March 2017 at 23:18, Denis Kotov <<a rel=3D"nofol=
low">redr...@gmail.com</a>> wrote:
<br>> But I do not see any problems with separate translation unit.
<br>
<br>You're asking for this rule:
<br>
<br>If the constructor I call initializes the virtual base, I won't hav=
e
<br>to. That rule is unimplementable
<br>in the presence of separate translation units.
<br>
<br>Furthermore, you cannot know what value the constructor you call
<br>(would) initializes the virtual base with.
<br>Currently, the intermediate class you initialize will not initialize
<br>the virtual base at all, so there's a good
<br>chance that what you're proposing is also an ABI break.
<br></blockquote><div><br></div><div>I think OP's proposed rule is some=
thing like</div><div><br></div><div>If an indirect virtual base is a (direc=
t or indirect) base of only one direct base, then you can omit initializing=
the virtual base. Presumably in that case you'd call the complete obje=
ct constructor of said direct base so that it initializes the virtual base,=
rather than the base object constructor.</div><div><br></div><div>This wou=
ldn't depend on the definition of the constructors at issue, only the c=
lasses, and won't run into separate translation issues. It does have pl=
enty of other issues, though (e.g., handling of default constructible virtu=
al bases, initialization order issues, etc., etc.), and I don't see how=
the headache is worth the minuscule benefit.</div></div></blockquote></div=
></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/25e054ca-aac4-4bcc-805a-4e1357de4f37%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/25e054ca-aac4-4bcc-805a-4e1357de4f37=
%40isocpp.org</a>.<br />
------=_Part_759_528400850.1489926148125--
------=_Part_758_115881469.1489926148125--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 19 Mar 2017 14:28:15 +0200
Raw View
On 19 March 2017 at 14:22, Denis Kotov <redradist@gmail.com> wrote:
> Thanks for comment T. C.,
>
> But I do not agree that it is not worth to do it.
> Consider situation of very long chain of inheritance. Why in this chain user
> has to call every time constructor for VirtualBase ?
The language statically guarantees that the initialization of the
VirtualBase is performed. Your
suggestion turns that static guarantee into undefined behavior.
--
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/CAFk2RUZNBo6oE9M4uZbN97yCDHwsvj_zKN0qV8EAX%3DwmQTX9Xw%40mail.gmail.com.
.
Author: Denis Kotov <redradist@gmail.com>
Date: Sun, 19 Mar 2017 05:55:08 -0700 (PDT)
Raw View
------=_Part_782_2008942085.1489928108589
Content-Type: multipart/alternative;
boundary="----=_Part_783_1796710921.1489928108590"
------=_Part_783_1796710921.1489928108590
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Ville Voutilainen,
*That is the point:* We will anyway know that *VirtualBase *is performed,=
=20
but by parent class where two *VirtualBase (VC class) *class inherites in=
=20
class *C3*.
Class *C5 *already knows that class *C3 *initialized *VirtualBase (VC=20
class)*
*C5 *class should not know anything about *VirtualBase*, because *C3 *has=
=20
already called constructor for *VirtualBase.* It is useless to call in *C5 =
*constructor=20
for *VirtualBase* if *C5 *does not what to do with parent classes.
=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 19 =D0=
=BC=D0=B0=D1=80=D1=82=D0=B0 2017 =D0=B3., 14:28:17 UTC+2 =D0=BF=D0=BE=D0=BB=
=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Ville=20
Voutilainen =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> On 19 March 2017 at 14:22, Denis Kotov <redr...@gmail.com <javascript:>>=
=20
> wrote:=20
> > Thanks for comment T. C.,=20
> >=20
> > But I do not agree that it is not worth to do it.=20
> > Consider situation of very long chain of inheritance. Why in this chain=
=20
> user=20
> > has to call every time constructor for VirtualBase ?=20
>
>
> The language statically guarantees that the initialization of the=20
> VirtualBase is performed. Your=20
> suggestion turns that static guarantee into undefined behavior.=20
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/633f2640-aef5-46a2-9ae2-6db626bc47fb%40isocpp.or=
g.
------=_Part_783_1796710921.1489928108590
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span class=3D"_username" style=3D"white-space: nowrap;"><=
span class=3D"IVILX2C-D-a">Ville Voutilainen,</span></span><div><span style=
=3D"white-space: nowrap;"><b><br></b></span></div><div><span style=3D"white=
-space: nowrap;"><b>That is the point:</b> We will anyway know that <b>Virt=
ualBase </b>is=C2=A0</span>performed, but by parent class where two <b>Virt=
ualBase (VC class)=C2=A0</b>class inherites in class <b>C3</b>.</div><div>C=
lass <b>C5 </b>already knows that class <b>C3 </b>initialized <b>VirtualBas=
e (VC class)</b><br><b>C5 </b>class should not know anything about=C2=A0<b>=
VirtualBase</b>,=C2=A0because <b>C3 </b>has already called constructor for=
=C2=A0<b>VirtualBase.</b> It is useless to call in=C2=A0<b>C5=C2=A0</b>cons=
tructor for=C2=A0<b>VirtualBase</b> if <b>C5 </b>does not what to do with p=
arent classes.<br><br>=D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5=D0=
=BD=D1=8C=D0=B5, 19 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2017 =D0=B3., 14:28:17 U=
TC+2 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=
=8C Ville Voutilainen =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">On 19 March 2017 at 14:22, Denis Kotov &=
lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"fCzzo=
N80EgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';=
return true;" onclick=3D"this.href=3D'javascript:';return true;">re=
dr...@gmail.com</a>> wrote:
<br>> Thanks for comment T. C.,
<br>>
<br>> But I do not agree that it is not worth to do it.
<br>> Consider situation of very long chain of inheritance. Why in this =
chain user
<br>> has to call every time constructor for VirtualBase ?
<br>
<br>
<br>The language statically guarantees that the initialization of the
<br>VirtualBase is performed. Your
<br>suggestion turns that static guarantee into undefined behavior.
<br></blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/633f2640-aef5-46a2-9ae2-6db626bc47fb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/633f2640-aef5-46a2-9ae2-6db626bc47fb=
%40isocpp.org</a>.<br />
------=_Part_783_1796710921.1489928108590--
------=_Part_782_2008942085.1489928108589--
.
Author: Denis Kotov <redradist@gmail.com>
Date: Sun, 19 Mar 2017 06:07:04 -0700 (PDT)
Raw View
------=_Part_713_2045404918.1489928824934
Content-Type: multipart/alternative;
boundary="----=_Part_714_1735362021.1489928824934"
------=_Part_714_1735362021.1489928824934
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
To share my view more clear I have added a new picture:
<https://lh3.googleusercontent.com/-K-Qmdj7-vio/WM6CYV4X4OI/AAAAAAAAFRE/VgM=
pfnwSEQcIrdxPaMU9nlUJksrijhrpQCLcB/s1600/Simplify%2Brules%2Bfor%2Bvirtual%2=
Binheritance.png>
=D1=81=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 18 =D0=BC=D0=B0=D1=80=D1=82=D0=
=B0 2017 =D0=B3., 21:31:32 UTC+2 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=
=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Denis Kotov =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=
=D0=B0=D0=BB:
>
> Hi everyone,
>
>
> My proposal is to simplify virtual inheritance rules. Consider the=20
> following class hierarchy:
>
>
> <https://lh3.googleusercontent.com/-h-cp0qNBSRI/WM2Ks4N6-3I/AAAAAAAAFQo/t=
vd17HoV09U2dPcY6XfzaxLm3K2ITBkrwCLcB/s1600/Simplify%2Brules%2Bfor%2Bvirtual=
%2Binheritance.png>
>
>
> and the following code:
>
> class VirtualBase
> {
> public:
> VirtualBase(std::string & str)
> {
>
> }
> };
>
> class Derived0 : virtual public VirtualBase
> {
> public:
> Derived0(std::string & str)
> : VirtualBase(str)
> {
>
> }
> };
>
> class Derived1 : virtual public VirtualBase
> {
> public:
> Derived1(std::string & str)
> : VirtualBase(str)
> {
>
> }
> };
>
> class ComposedDerived
> : public Derived0
> , public Derived1
> {
> public:
> ComposedDerived(std::string & str)
> : Derived0(str)
> , Derived1(str)
> , VirtualBase(str)
> {
>
> }
> };
>
> Let's inherit from ComposedDerived again:
>
> class ComposedDerivedDerived
> : public ComposedDerived
> , public NewClass
> {
> public:
> ComposedDerivedDerived(std::string & str)
> : VirtualBase(str)
> {
>
> }
> };
>
> I want to simplify it like the following:
>
> class ComposedDerivedDerived
> : public ComposedDerived
> , public NewClass
> {
> public:
> ComposedDerivedDerived(std::string & str) // Here is no=20
> VirtualBase(str)
> {
>
> }
> };
>
> *Proposal is the following:*
> *Require to specify constructor for VirtualBase only if compiler find=
=20
> more the one path of virtual inheritance like for C3 (on diagram) or=20
> ComposedDerived (in code) classes*
>
--=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/1b33375c-526b-4e20-a691-a85d512fa4a8%40isocpp.or=
g.
------=_Part_714_1735362021.1489928824934
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">To share my view more clear I have added a new picture:<di=
v><br></div><p class=3D"separator" style=3D"text-align: center; clear: both=
;"><a imageanchor=3D"1" href=3D"https://lh3.googleusercontent.com/-K-Qmdj7-=
vio/WM6CYV4X4OI/AAAAAAAAFRE/VgMpfnwSEQcIrdxPaMU9nlUJksrijhrpQCLcB/s1600/Sim=
plify%2Brules%2Bfor%2Bvirtual%2Binheritance.png" style=3D"margin-left: 1em;=
margin-right: 1em;"><img src=3D"https://lh3.googleusercontent.com/-K-Qmdj7=
-vio/WM6CYV4X4OI/AAAAAAAAFRE/VgMpfnwSEQcIrdxPaMU9nlUJksrijhrpQCLcB/s320/Sim=
plify%2Brules%2Bfor%2Bvirtual%2Binheritance.png" border=3D"0" style=3D"" wi=
dth=3D"257" height=3D"320"></a></p><div><br><br>=D1=81=D1=83=D0=B1=D0=B1=D0=
=BE=D1=82=D0=B0, 18 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2017 =D0=B3., 21:31:32 U=
TC+2 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=
=8C Denis Kotov =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><p style=3D"clear:both">Hi ev=
eryone,</p><p style=3D"clear:both"><br></p><p style=3D"clear:both">My propo=
sal is to simplify virtual inheritance rules. Consider the following class =
hierarchy:</p><div><br></div><p style=3D"text-align:center;clear:both"><a h=
ref=3D"https://lh3.googleusercontent.com/-h-cp0qNBSRI/WM2Ks4N6-3I/AAAAAAAAF=
Qo/tvd17HoV09U2dPcY6XfzaxLm3K2ITBkrwCLcB/s1600/Simplify%2Brules%2Bfor%2Bvir=
tual%2Binheritance.png" style=3D"margin-left:1em;margin-right:1em" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://lh3.go=
ogleusercontent.com/-h-cp0qNBSRI/WM2Ks4N6-3I/AAAAAAAAFQo/tvd17HoV09U2dPcY6X=
fzaxLm3K2ITBkrwCLcB/s1600/Simplify%2Brules%2Bfor%2Bvirtual%2Binheritance.pn=
g';return true;" onclick=3D"this.href=3D'https://lh3.googleusercont=
ent.com/-h-cp0qNBSRI/WM2Ks4N6-3I/AAAAAAAAFQo/tvd17HoV09U2dPcY6XfzaxLm3K2ITB=
krwCLcB/s1600/Simplify%2Brules%2Bfor%2Bvirtual%2Binheritance.png';retur=
n true;"><img src=3D"https://lh3.googleusercontent.com/-h-cp0qNBSRI/WM2Ks4N=
6-3I/AAAAAAAAFQo/tvd17HoV09U2dPcY6XfzaxLm3K2ITBkrwCLcB/s320/Simplify%2Brule=
s%2Bfor%2Bvirtual%2Binheritance.png" border=3D"0" width=3D"261" height=3D"3=
20"></a></p><div><br></div><br><div>and the following code:</div><div><br><=
/div><div><div>=C2=A0 =C2=A0 class VirtualBase</div><div>=C2=A0 =C2=A0 {</d=
iv><div>=C2=A0 =C2=A0 public:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0VirtualB=
ase(std::string & str)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0{</div><div=
><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0}</div><div>=C2=A0 =C2=A0 };</di=
v><div><br></div><div>=C2=A0 =C2=A0 class Derived0 : virtual public Virtual=
Base</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 public:</div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0Derived0(std::string & str)</div><div>=C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 : VirtualBase(str)</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0{</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0}</div><div=
>=C2=A0 =C2=A0 };</div><div><br></div><div>=C2=A0 =C2=A0 class Derived1 : v=
irtual public VirtualBase</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0=
public:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0Derived1(std::string & st=
r)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : VirtualBase(str)</div><di=
v>=C2=A0 =C2=A0 =C2=A0 =C2=A0{</div><div><br></div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0}</div><div>=C2=A0 =C2=A0 };</div><div><br></div><div>=C2=A0 =C2=
=A0 class ComposedDerived</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0: public Der=
ived0</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0, public Derived1</div><div>=C2=
=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 public:</div><div>=C2=A0 =C2=A0 =C2=A0=
=C2=A0ComposedDerived(std::string & str)</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 : Derived0(str)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 , Derived1(str)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 , VirtualB=
ase(str)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0{</div><div><br></div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0}</div><div>=C2=A0 =C2=A0 };</div></div><div><br=
></div><div>Let's inherit from ComposedDerived again:</div><div><br></d=
iv><div><div>=C2=A0 =C2=A0 class ComposedDerivedDerived</div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0: public ComposedDerived</div><div>=C2=A0 =C2=A0 =C2=A0=
=C2=A0, public NewClass<br></div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=
=A0 public:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0ComposedDerivedDerived(std=
::<wbr>string & str)</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Virt=
ualBase(str)<br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0{</div><div><br></div=
><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0}</div><div>=C2=A0 =C2=A0 };</div></div><d=
iv><br></div><div>I want to simplify it like the following:</div><div><div>=
<br></div><div><div>=C2=A0 =C2=A0 class ComposedDerivedDerived</div><div>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0: public ComposedDerived</div><div>=C2=A0 =C2=A0=
=C2=A0 =C2=A0, public NewClass</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =
=C2=A0 public:</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0ComposedDerivedDerived(=
std::<wbr>string & str) // Here is no VirtualBase(str)</div><div>=C2=A0=
=C2=A0 =C2=A0 =C2=A0{</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
}</div><div>=C2=A0 =C2=A0 };</div></div></div><div><br></div><div><span sty=
le=3D"background-color:rgb(255,255,0)"><b>Proposal is the following:</b></s=
pan></div><div>=C2=A0 =C2=A0<b>Require to specify constructor for VirtualBa=
se only if compiler find more the one path of virtual inheritance like for =
C3 (on diagram) or ComposedDerived (in code) classes</b></div></div></block=
quote></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/1b33375c-526b-4e20-a691-a85d512fa4a8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1b33375c-526b-4e20-a691-a85d512fa4a8=
%40isocpp.org</a>.<br />
------=_Part_714_1735362021.1489928824934--
------=_Part_713_2045404918.1489928824934--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 19 Mar 2017 15:07:24 +0200
Raw View
On 19 March 2017 at 14:55, Denis Kotov <redradist@gmail.com> wrote:
> Ville Voutilainen,
>
> That is the point: We will anyway know that VirtualBase is performed, but by
> parent class where two VirtualBase (VC class) class inherites in class C3.
There are situations where the bases do not need to initialize the virtual base:
http://open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#1611
--
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/CAFk2RUY%3D9O-6%3Dh7XYt%2B0Xg_GOxfrhwwC-vs8mSKexAtbJ6M-mw%40mail.gmail.com.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 19 Mar 2017 15:24:33 +0200
Raw View
On 19 March 2017 at 15:07, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 19 March 2017 at 14:55, Denis Kotov <redradist@gmail.com> wrote:
>> Ville Voutilainen,
>>
>> That is the point: We will anyway know that VirtualBase is performed, but by
>> parent class where two VirtualBase (VC class) class inherites in class C3.
>
> There are situations where the bases do not need to initialize the virtual base:
> http://open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#1611
However, thanks for the clarification, so what we have here is
1) if the intermediate bases are non-abstract, they will have compiled
the virtual base initialization into them
2) therefore the more-derived class wouldn't need to do it
So we don't have a case of UB. We have cases where code that wasn't
previously valid will now be valid,
though:
struct B
{
private:
B(int) {}
friend class D;
};
struct D : virtual B // thou shalt not initialize me from a derived class
{
D() : B(42) {}
};
struct E : D
{
E() : B(42) {} // this attempt to initialize D is ill-formed
};
int main()
{
D d; // ok
E e; // we can't even get this far
}
With your proposal, E could skip the initialization of B and be well-formed.
Another problem with the proposal is that today it's possible to write
class hierarchies that
rely on the most-derived class being the one to initialize the virtual
base. This proposal
changes how such hierarchies behave.
--
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/CAFk2RUam2MkSDw_6-%3DZ%2BJppmnJ0q%3DuCc99q0RZ5--U5AqwqBbQ%40mail.gmail.com.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 19 Mar 2017 10:58:06 -0700
Raw View
On domingo, 19 de mar=C3=A7o de 2017 05:28:15 PDT Ville Voutilainen wrote:
> On 19 March 2017 at 14:22, Denis Kotov <redradist@gmail.com> wrote:
> > Thanks for comment T. C.,
> >=20
> > But I do not agree that it is not worth to do it.
> > Consider situation of very long chain of inheritance. Why in this chain
> > user has to call every time constructor for VirtualBase ?
>=20
> The language statically guarantees that the initialization of the
> VirtualBase is performed. Your
> suggestion turns that static guarantee into undefined behavior.
The complete constructor must exist if the direct base class is not abstrac=
t.=20
In other words, the complete constructor must exist if a user is able to=20
construct that class.
The compiler will have to emit the base object constructor for all of those=
=20
classes, since another class down the line could choose to construct the=20
virtual base directly.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1785771.9FtZOUdvrM%40tjmaciei-mobl1.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 19 Mar 2017 20:12:25 +0200
Raw View
On 19 March 2017 at 19:58, Thiago Macieira <thiago@macieira.org> wrote:
>> The language statically guarantees that the initialization of the
>> VirtualBase is performed. Your
>> suggestion turns that static guarantee into undefined behavior.
>
> The complete constructor must exist if the direct base class is not abstract.
> In other words, the complete constructor must exist if a user is able to
> construct that class.
>
> The compiler will have to emit the base object constructor for all of those
> classes, since another class down the line could choose to construct the
> virtual base directly.
Right, so this proposal doesn't produce UB. That leaves the other
compatibility issues.
--
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/CAFk2RUZ1xwEG_L-LG-FE9oKoDeEbVmBqvc6LRwdnOeWV%2BKENgw%40mail.gmail.com.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 19 Mar 2017 11:20:38 -0700
Raw View
On domingo, 19 de mar=C3=A7o de 2017 11:12:25 PDT Ville Voutilainen wrote:
> > The compiler will have to emit the base object constructor for all of
> > those
> > classes, since another class down the line could choose to construct th=
e
> > virtual base directly.
>=20
> Right, so this proposal doesn't produce UB. That leaves the other
> compatibility issues.
Which ones?
Does it make a difference in behaviour which base class actually called the=
=20
virtual base's construtor? Is there any situation in which it changes with=
=20
this proposal?
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2697868.vdYFrBLFDC%40tjmaciei-mobl1.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 19 Mar 2017 20:32:04 +0200
Raw View
On 19 March 2017 at 20:20, Thiago Macieira <thiago@macieira.org> wrote:
>> Right, so this proposal doesn't produce UB. That leaves the other
>> compatibility issues.
>
> Which ones?
See a couple of emails ago. The cases where the most-derived class
doesn't have access to the constructor
of the virtual base; that makes intentionally ill-formed cases well-formed.
> Does it make a difference in behaviour which base class actually called the
> virtual base's construtor? Is there any situation in which it changes with
> this proposal?
There may well be cases where the designer of the class hierarchy
intends to force the authors
of derived classes to provide a value to be used for initializing the
virtual base. It might also be the case
that that value is an invariant for the hierarchy, although I'm not
sure whether anyone writes such hierarchies.
Practically, that means passing 'this' up the hierarchy into the virtual base.
--
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/CAFk2RUZW%2BrW5NsDQGff25eF6Kj1RuMwbhE24y800GE584pdhpg%40mail.gmail.com.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 19 Mar 2017 12:10:31 -0700
Raw View
On domingo, 19 de mar=C3=A7o de 2017 11:32:04 PDT Ville Voutilainen wrote:
> On 19 March 2017 at 20:20, Thiago Macieira <thiago@macieira.org> wrote:
> >> Right, so this proposal doesn't produce UB. That leaves the other
> >> compatibility issues.
> >=20
> > Which ones?
>=20
> See a couple of emails ago. The cases where the most-derived class
> doesn't have access to the constructor
> of the virtual base; that makes intentionally ill-formed cases well-forme=
d.
Right. This may have been used in existing code to limit inheritance in a t=
ree=20
to only classes that are explicitly white-listed as friends at some point.
I'm wondering if now allowing this inheritance is a problem.
> > Does it make a difference in behaviour which base class actually called
> > the
> > virtual base's construtor? Is there any situation in which it changes w=
ith
> > this proposal?
>=20
> There may well be cases where the designer of the class hierarchy
> intends to force the authors
> of derived classes to provide a value to be used for initializing the
> virtual base.=20
And in this case, the author of the new class is simply saying "I'll have w=
hat=20
he's having" (the direct base class that includes the virtual base). I=20
understand that this technique would have been very useful to force a uniqu=
e=20
identifier per class in the hierarchy, but now we're allowing a derived cla=
ss=20
not to override the identifier (or silently forget to).
Do we need a keyword to specifically allow this new functionality?
> It might also be the case
> that that value is an invariant for the hierarchy, although I'm not
> sure whether anyone writes such hierarchies.
> Practically, that means passing 'this' up the hierarchy into the virtual
> base.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5741111.lt9RR1yvSQ%40tjmaciei-mobl1.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 19 Mar 2017 22:01:52 +0200
Raw View
On 19 March 2017 at 21:10, Thiago Macieira <thiago@macieira.org> wrote:
> On domingo, 19 de mar=C3=A7o de 2017 11:32:04 PDT Ville Voutilainen wrote=
:
>> On 19 March 2017 at 20:20, Thiago Macieira <thiago@macieira.org> wrote:
>> >> Right, so this proposal doesn't produce UB. That leaves the other
>> >> compatibility issues.
>> >
>> > Which ones?
>>
>> See a couple of emails ago. The cases where the most-derived class
>> doesn't have access to the constructor
>> of the virtual base; that makes intentionally ill-formed cases well-form=
ed.
>
> Right. This may have been used in existing code to limit inheritance in a=
tree
> to only classes that are explicitly white-listed as friends at some point=
..
>
> I'm wondering if now allowing this inheritance is a problem.
The technique appears in http://www.stroustrup.com/bs_faq2.html#no-derivati=
on
> And in this case, the author of the new class is simply saying "I'll have=
what
> he's having" (the direct base class that includes the virtual base). I
> understand that this technique would have been very useful to force a uni=
que
> identifier per class in the hierarchy, but now we're allowing a derived c=
lass
> not to override the identifier (or silently forget to).
>
> Do we need a keyword to specifically allow this new functionality?
Grr. Let's not make it that complex. I think another interesting case is th=
is:
#include <iostream>
struct B
{
B() {std::cout << "B default" << std::endl;}
B(int) {std::cout << "B int" << std::endl;}
};
struct D : virtual B
{
D() : B(42) {}
};
struct E : D
{
};
int main()
{
E e;
}
We presumably don't want to change how that behaves. So, in some
cases, E does initialize the virtual
base, in others, it doesn't. So, trying to keep that unchanged and the
no-derivation case working, we have something like
1) if default-initializing B from E is valid, we're done.
2) if default-initializing B from E fails due to access violation, we're do=
ne.
3) if default-initializing B from E fails due to overload resolution
failure for not finding a viable candidate,
don't initialize B in E but instead initialize E in D.
4) any existing explicit initialization of B from E is unchanged, and
there's no fallback to any base class.
--=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/CAFk2RUaf23ZfK3v%3Dg4j6gwA6KAOTWNtbB%3D1fGKuRia8=
HiNs35Q%40mail.gmail.com.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 19 Mar 2017 17:36:21 -0700
Raw View
On domingo, 19 de mar=C3=A7o de 2017 13:01:52 PDT Ville Voutilainen wrote:
> 1) if default-initializing B from E is valid, we're done.
> 2) if default-initializing B from E fails due to access violation, we're
> done. 3) if default-initializing B from E fails due to overload resolutio=
n
> failure for not finding a viable candidate,
> don't initialize B in E but instead initialize E in D.
> 4) any existing explicit initialization of B from E is unchanged, and
> there's no fallback to any base class.
You're excluding the "I'll have what he's having" case. That is, in your=20
example, there's no way to have E initilise B like D does without specifica=
lly=20
duplicating what D does.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/40301952.JFSPpDkHTG%40tjmaciei-mobl1.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 20 Mar 2017 02:57:17 +0200
Raw View
On 20 March 2017 at 02:36, Thiago Macieira <thiago@macieira.org> wrote:
> On domingo, 19 de mar=C3=A7o de 2017 13:01:52 PDT Ville Voutilainen wrote=
:
>> 1) if default-initializing B from E is valid, we're done.
>> 2) if default-initializing B from E fails due to access violation, we're
>> done. 3) if default-initializing B from E fails due to overload resoluti=
on
>> failure for not finding a viable candidate,
>> don't initialize B in E but instead initialize E in D.
>> 4) any existing explicit initialization of B from E is unchanged, and
>> there's no fallback to any base class.
>
> You're excluding the "I'll have what he's having" case. That is, in your
> example, there's no way to have E initilise B like D does without specifi=
cally
> duplicating what D does.
Well, if B doesn't have a default constructor, don't write any
initialization for B in E.
Then you get what D gets, unless there's an access violation in the
potential initialization
of B in E. So no, I'm not trying to provide an additional facility
that always gives E
what D gets.
--=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/CAFk2RUYomjfnsCHuxevU8vhGK6wQJZK0FN52rKH4bNUeqJP=
Zyg%40mail.gmail.com.
.