Topic: proposal for more explicit vtable control
Author: cschueler@gmx.de
Date: Tue, 9 Jul 2013 15:34:07 -0700 (PDT)
Raw View
------=_Part_737_11608449.1373409247103
Content-Type: text/plain; charset=ISO-8859-1
Hallo list,
I searched for similar existing proposals but found none, so I posting it
here.
The proposed features seems so basic to me that I think it must have been
proposed before, in one way or another. But in any case, here it goes:
In addition to the "= 0" initializer to indicate pure virtual functions, the
proposal allows to initialize a virtual function with the address of another
function, like so:
struct foo
{
virtual void bar();
virtual void baz() = &bar;
};
This shall mean, that the default implementation for baz() is bar(), unless
this
behavior is overridden in a derived class. The envisioned canonical
implementation is of course, that the address of function bar is put into
both
slots of foo's vtable. In the absence of this feature, the workarounds are
either code duplication (same implementation for bar and baz) or an
additional
function call (baz calls bar).
I feel that neither workaround should be necessary and this is a capability
gap in C++.
I am motivated by the possibilities that are available to pure C
programmers when
designing a scheme for a polymorphic object hierarchy (for example,
PyObject in CPython).
There, it is perfectly possible to assign the same function pointer into
different slots
of what is the equivalent of the vtable. It is also possible to put data
elements there, thereby creating the equivalent of virtual static data
members
(which I am strongly in favor of).
Feedback and comments welcome.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_737_11608449.1373409247103
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<span style=3D"color: rgb(0, 0, 0); font-family: monospace; font-size: 12px=
; line-height: 18px; ">Hallo list,</span><br style=3D"color: rgb(0, 0, 0); =
font-family: monospace; font-size: 12px; line-height: 18px; "><span style=
=3D"color: rgb(0, 0, 0); font-family: monospace; font-size: 12px; line-heig=
ht: 18px; ">I searched for similar existing proposals but found none, so I =
posting it here.</span><br style=3D"color: rgb(0, 0, 0); font-family: monos=
pace; font-size: 12px; line-height: 18px; "><span style=3D"color: rgb(0, 0,=
0); font-family: monospace; font-size: 12px; line-height: 18px; ">The prop=
osed features seems so basic to me that I think it must have been</span><br=
style=3D"color: rgb(0, 0, 0); font-family: monospace; font-size: 12px; lin=
e-height: 18px; "><span style=3D"color: rgb(0, 0, 0); font-family: monospac=
e; font-size: 12px; line-height: 18px; ">proposed before, in one way or ano=
ther. But in any case, here it goes:</span><br style=3D"color: rgb(0, 0, 0)=
; font-family: monospace; font-size: 12px; line-height: 18px; "><br style=
=3D"color: rgb(0, 0, 0); font-family: monospace; font-size: 12px; line-heig=
ht: 18px; "><span style=3D"color: rgb(0, 0, 0); font-family: monospace; fon=
t-size: 12px; line-height: 18px; ">In addition to the "=3D 0" initializer t=
o indicate pure virtual functions, the</span><br style=3D"color: rgb(0, 0, =
0); font-family: monospace; font-size: 12px; line-height: 18px; "><span sty=
le=3D"color: rgb(0, 0, 0); font-family: monospace; font-size: 12px; line-he=
ight: 18px; ">proposal allows to initialize a virtual function with the add=
ress of another</span><br style=3D"color: rgb(0, 0, 0); font-family: monosp=
ace; font-size: 12px; line-height: 18px; "><span style=3D"color: rgb(0, 0, =
0); font-family: monospace; font-size: 12px; line-height: 18px; ">function,=
like so:</span><br style=3D"color: rgb(0, 0, 0); font-family: monospace; f=
ont-size: 12px; line-height: 18px; "><br style=3D"color: rgb(0, 0, 0); font=
-family: monospace; font-size: 12px; line-height: 18px; "><div style=3D"bac=
kground-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); wo=
rd-wrap: break-word; " class=3D"prettyprint"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> foo<br></span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">virtual</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> bar</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><s=
pan 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: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> baz</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: #660;" class=3D"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">bar</s=
pan><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>=
<span style=3D"color: rgb(0, 0, 0); font-family: monospace; font-size: 12px=
; line-height: 18px; "><div><span style=3D"color: rgb(0, 0, 0); font-family=
: monospace; font-size: 12px; line-height: 18px; "><br></span></div>This sh=
all mean, that the default implementation for baz() is bar(), unless this</=
span><br style=3D"color: rgb(0, 0, 0); font-family: monospace; font-size: 1=
2px; line-height: 18px; "><span style=3D"color: rgb(0, 0, 0); font-family: =
monospace; font-size: 12px; line-height: 18px; ">behavior is overridden in =
a derived class. The envisioned canonical</span><br style=3D"color: r=
gb(0, 0, 0); font-family: monospace; font-size: 12px; line-height: 18px; ">=
<span style=3D"color: rgb(0, 0, 0); font-family: monospace; font-size: 12px=
; line-height: 18px; ">implementation is of course, that the address of fun=
ction bar is put into both</span><br style=3D"color: rgb(0, 0, 0); font-fam=
ily: monospace; font-size: 12px; line-height: 18px; "><span style=3D"color:=
rgb(0, 0, 0); font-family: monospace; font-size: 12px; line-height: 18px; =
">slots of foo's vtable. In the absence of this feature, the workarounds ar=
e</span><br style=3D"color: rgb(0, 0, 0); font-family: monospace; font-size=
: 12px; line-height: 18px; "><span style=3D"color: rgb(0, 0, 0); font-famil=
y: monospace; font-size: 12px; line-height: 18px; ">either code duplication=
(same implementation for bar and baz) or an additional</span><br style=3D"=
color: rgb(0, 0, 0); font-family: monospace; font-size: 12px; line-height: =
18px; "><span style=3D"color: rgb(0, 0, 0); font-family: monospace; font-si=
ze: 12px; line-height: 18px; ">function call (baz calls bar).</span><br sty=
le=3D"color: rgb(0, 0, 0); font-family: monospace; font-size: 12px; line-he=
ight: 18px; "><br style=3D"color: rgb(0, 0, 0); font-family: monospace; fon=
t-size: 12px; line-height: 18px; "><span style=3D"color: rgb(0, 0, 0); font=
-family: monospace; font-size: 12px; line-height: 18px; ">I feel that neith=
er workaround should be necessary and this is a capability gap in C++.</spa=
n><div><span style=3D"color: rgb(0, 0, 0); font-family: monospace; font-siz=
e: 12px; line-height: 18px; ">I am motivated by the </span><span style=
=3D"color: rgb(0, 0, 0); font-family: monospace; font-size: 12px; line-heig=
ht: 18px; ">possibilities that are available to pure C programmers when&nbs=
p;</span></div><div><span style=3D"color: rgb(0, 0, 0); font-family: monosp=
ace; font-size: 12px; line-height: 18px; ">designing a scheme </span><=
span style=3D"color: rgb(0, 0, 0); font-family: monospace; font-size: 12px;=
line-height: 18px; ">for a polymorphic object hierarchy (for example, PyOb=
ject in CPython). </span></div><div><span style=3D"color: rgb(0, 0, 0)=
; font-family: monospace; font-size: 12px; line-height: 18px; ">There, it&n=
bsp;</span><span style=3D"color: rgb(0, 0, 0); font-family: monospace; font=
-size: 12px; line-height: 18px; ">is perfectly possible to assign the same =
function pointer into different slots</span><br style=3D"color: rgb(0, 0, 0=
); font-family: monospace; font-size: 12px; line-height: 18px; "><span styl=
e=3D"color: rgb(0, 0, 0); font-family: monospace; font-size: 12px; line-hei=
ght: 18px; ">of what is the equivalent of the vtable. It is also possible t=
o put data</span><br style=3D"color: rgb(0, 0, 0); font-family: monospace; =
font-size: 12px; line-height: 18px; "><span style=3D"color: rgb(0, 0, 0); f=
ont-family: monospace; font-size: 12px; line-height: 18px; ">elements there=
, thereby creating the equivalent of virtual static data members</span><br =
style=3D"color: rgb(0, 0, 0); font-family: monospace; font-size: 12px; line=
-height: 18px; "><span style=3D"color: rgb(0, 0, 0); font-family: monospace=
; font-size: 12px; line-height: 18px; ">(which I am strongly in favor of).&=
nbsp;</span><br style=3D"color: rgb(0, 0, 0); font-family: monospace; font-=
size: 12px; line-height: 18px; "><br style=3D"color: rgb(0, 0, 0); font-fam=
ily: monospace; font-size: 12px; line-height: 18px; "><span style=3D"color:=
rgb(0, 0, 0); font-family: monospace; font-size: 12px; line-height: 18px; =
">Feedback and comments welcome.</span><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_737_11608449.1373409247103--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Wed, 10 Jul 2013 13:03:48 +0200
Raw View
--089e0118266a66747a04e1263bec
Content-Type: text/plain; charset=ISO-8859-1
Some questions, I'm just curious:
1. are there important differences with the following?
struct foo
{
virtual void bar();
virtual void baz() { bar(); } // this is inlined AFAIK, isn't it?
};
or maybe you're suggesting that there are more complex cases where
it is not appropriate or maintanable to do it this way?
2. Do you have real use cases where you need such features?
Joel Lamotte
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e0118266a66747a04e1263bec
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Some questions, I'm just curious:<div><br></div><div>1=
.. are there important differences with the following?</div><div><br></div><=
div>struct foo</div><div>{</div><div>=A0 =A0 =A0virtual void bar();</div><d=
iv>=A0 =A0 =A0virtual void baz() { bar(); } // this is inlined AFAIK, isn&#=
39;t it?</div>
<div>};</div><div><br></div><div>or maybe you're suggesting that there =
are more complex cases where=A0</div><div>it is not appropriate or maintana=
ble to do it this way?</div><div><br></div><div>2. Do you have real use cas=
es where you need such features?</div>
<div><br></div><div>Joel Lamotte</div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--089e0118266a66747a04e1263bec--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 10 Jul 2013 14:17:38 +0300
Raw View
--089e013cb85ce4fe1a04e1266c84
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 10 July 2013 14:03, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com> wrote:
> Some questions, I'm just curious:
>
> 1. are there important differences with the following?
>
> struct foo
> {
> virtual void bar();
> virtual void baz() { bar(); } // this is inlined AFAIK, isn't it?
> };
>
Inlined? It's a virtual call.
But, for the alternative:
struct foo
{
virtual void bar();
virtual void baz();
};
// in a separate TU
void foo::bar() {common_impl();}
void foo::baz() {common_impl();}
In the TU of these definitions, common_impl(); can be inlined. So why would
we make this
proposed change, when this work-around doesn't add extra function calls and
causes a tiny
amount of code duplication?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--089e013cb85ce4fe1a04e1266c84
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 10 July 2013 14:03, Klaim - Jo=EBl Lamotte <span dir=3D"ltr"><=
;<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com</=
a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Some que=
stions, I'm just curious:<div><br></div><div>1. are there important dif=
ferences with the following?</div>
<div class=3D"im"><div><br></div><div>struct foo</div><div>{</div><div>=A0 =
=A0 =A0virtual void bar();</div></div><div>=A0 =A0 =A0virtual void baz() { =
bar(); } // this is inlined AFAIK, isn't it?</div>
<div>};</div></div></blockquote><div><br></div><div>Inlined? It's a vir=
tual call.<br><br><br></div><div>But, for the alternative:<br><br>struct fo=
o<br>{<br></div><div>=A0=A0=A0 virtual void bar();<br></div><div>=A0=A0=A0 =
virtual void baz();<br>
</div><div>};<br></div></div><br></div><div class=3D"gmail_extra">// in a s=
eparate TU<br></div><div class=3D"gmail_extra">void foo::bar() {common_impl=
();}<br>void foo::baz() {common_impl();}<br><br></div><div class=3D"gmail_e=
xtra">
In the TU of these definitions, common_impl(); can be inlined. So why would=
we make this<br>proposed change, when this work-around doesn't add ext=
ra function calls and causes a tiny<br></div><div class=3D"gmail_extra">amo=
unt of code duplication?<br>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--089e013cb85ce4fe1a04e1266c84--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Wed, 10 Jul 2013 04:42:49 -0700 (PDT)
Raw View
------=_Part_2806_22909541.1373456569718
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Wednesday, July 10, 2013 12:17:38 PM UTC+1, Ville Voutilainen wrote:
>
>
>
>
> On 10 July 2013 14:03, Klaim - Jo=EBl Lamotte <mjk...@gmail.com<javascrip=
t:>
> > wrote:
>
>> Some questions, I'm just curious:
>>
>> 1. are there important differences with the following?
>>
>> struct foo
>> {
>> virtual void bar();
>> virtual void baz() { bar(); } // this is inlined AFAIK, isn't it?
>> };
>>
>
> Inlined? It's a virtual call.
>
You could qualify the call to foo::bar() directly. Frankly, I don't see how=
=20
even if it wasn't inlined, one function call that a compiler which really=
=20
wanted to could optimize out is worth a language feature.=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_2806_22909541.1373456569718
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Wednesday, July 10, 2013 12:17:38 PM UTC+1, Ville Voutilainen wr=
ote:<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"><br><div>=
<br><br><div class=3D"gmail_quote">On 10 July 2013 14:03, Klaim - Jo=EBl La=
motte <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"m5l1T2gFMuQJ">mjk...@gmail.com</a>></span> wrote:<br=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Some que=
stions, I'm just curious:<div><br></div><div>1. are there important differe=
nces with the following?</div>
<div><div><br></div><div>struct foo</div><div>{</div><div> &nb=
sp;virtual void bar();</div></div><div> virtual void baz=
() { bar(); } // this is inlined AFAIK, isn't it?</div>
<div>};</div></div></blockquote><div><br></div><div>Inlined? It's a virtual=
call.</div></div></div></div></blockquote><div><br></div><div>You could qu=
alify the call to foo::bar() directly. Frankly, I don't see how even if it =
wasn't inlined, one function call that a compiler which really wanted to co=
uld optimize out is worth a language feature. </div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_2806_22909541.1373456569718--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 10 Jul 2013 14:46:31 +0300
Raw View
--001a11c2eaae2e3dfd04e126d4de
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 10 July 2013 14:42, DeadMG <wolfeinstein@gmail.com> wrote:
>
>
> On Wednesday, July 10, 2013 12:17:38 PM UTC+1, Ville Voutilainen wrote:
>
>>
>>
>>
>> On 10 July 2013 14:03, Klaim - Jo=EBl Lamotte <mjk...@gmail.com> wrote:
>>
>>> Some questions, I'm just curious:
>>>
>>> 1. are there important differences with the following?
>>>
>>> struct foo
>>> {
>>> virtual void bar();
>>> virtual void baz() { bar(); } // this is inlined AFAIK, isn't it?
>>> };
>>>
>>
>> Inlined? It's a virtual call.
>>
>
> You could qualify the call to foo::bar() directly. Frankly, I don't see
> how even if it wasn't inlined, one function call that a compiler which
> really wanted to could optimize out is worth a language feature.
>
>
>
>
The remainder of my message shows an alternative approach that avoids any
function call via inlining of
a non-virtual and at the same time avoids/minimizes code duplication, so I
don't disagree with you - I find
the motivation for this feature weak.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c2eaae2e3dfd04e126d4de
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 10 July 2013 14:42, DeadMG <span dir=3D"ltr"><<a href=3D"mail=
to:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstein@gmail.com</a>>=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><br>On Wednesday, July 10, 2013 12:17:38=
PM UTC+1, Ville Voutilainen wrote:<div class=3D"im"><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<div dir=3D"ltr"><br><div><br><br><div class=3D"gmail_quote">On 10 July 201=
3 14:03, Klaim - Jo=EBl Lamotte <span dir=3D"ltr"><<a>mjk...@gmail.com</=
a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Some que=
stions, I'm just curious:<div><br></div><div>1. are there important dif=
ferences with the following?</div>
<div><div><br></div><div>struct foo</div><div>{</div><div>=A0 =A0 =A0virtua=
l void bar();</div></div><div>=A0 =A0 =A0virtual void baz() { bar(); } // t=
his is inlined AFAIK, isn't it?</div>
<div>};</div></div></blockquote><div><br></div><div>Inlined? It's a vir=
tual call.</div></div></div></div></blockquote><div><br></div></div><div>Yo=
u could qualify the call to foo::bar() directly. Frankly, I don't see h=
ow even if it wasn't inlined, one function call that a compiler which r=
eally wanted to could optimize out is worth a language feature.=A0</div>
<div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
<br><br></div></div></blockquote><div><br></div><div>The remainder of my me=
ssage shows an alternative approach that avoids any function call via inlin=
ing of<br>a non-virtual and at the same time avoids/minimizes code duplicat=
ion, so I don't disagree with you - I find <br>
the motivation for this feature weak. <br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--001a11c2eaae2e3dfd04e126d4de--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Wed, 10 Jul 2013 14:23:29 +0200
Raw View
--001a11c2deaa5c1a9804e1275842
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Jul 10, 2013 at 1:17 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> Inlined? It's a virtual call.
Ah yes, I was thinking without the potential inheritance because there is
none in the example, sorry.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c2deaa5c1a9804e1275842
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Jul 10, 2013 at 1:17 PM, Ville Voutilainen <span dir=3D"ltr"><<a=
href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutil=
ainen@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Inlined? It's a virtual call.</blockquot=
e></div><br>Ah yes, I was thinking without the potential inheritance becaus=
e there is none in the example, sorry.</div>
</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--001a11c2deaa5c1a9804e1275842--
.
Author: Jeffrey Yasskin <jyasskin@google.com>
Date: Wed, 10 Jul 2013 10:43:18 -0700
Raw View
On Wed, Jul 10, 2013 at 4:17 AM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>
>
>
> On 10 July 2013 14:03, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com> wrote:
>>
>> Some questions, I'm just curious:
>>
>> 1. are there important differences with the following?
>>
>> struct foo
>> {
>> virtual void bar();
>> virtual void baz() { foo::bar(); } // this is inlined AFAIK, isn't =
it?
>> };
>
>
> But, for the alternative:
>
> struct foo
> {
> virtual void bar();
> virtual void baz();
> };
>
> // in a separate TU
> void foo::bar() {common_impl();}
> void foo::baz() {common_impl();}
>
> In the TU of these definitions, common_impl(); can be inlined. So why wou=
ld
> we make this
> proposed change, when this work-around doesn't add extra function calls a=
nd
> causes a tiny
> amount of code duplication?
Both of these cost a small amount of code size with current compilers.
The proposed syntax would make it fairly obvious that no extra
function is emitted. However, I believe compilers could optimize
either of the suggested alternatives into a shared vtable entry, and
if the code size improvement is important to someone, they should bug
their compiler vendor to do that. If something in the language
prohibits that optimization, that would be worth fixing.
Jeffrey
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 10 Jul 2013 20:54:36 +0300
Raw View
--20cf306844d5840edb04e12bf84c
Content-Type: text/plain; charset=ISO-8859-1
On 10 July 2013 20:43, Jeffrey Yasskin <jyasskin@google.com> wrote:
> Both of these cost a small amount of code size with current compilers.
> The proposed syntax would make it fairly obvious that no extra
> function is emitted. However, I believe compilers could optimize
> either of the suggested alternatives into a shared vtable entry, and
> if the code size improvement is important to someone, they should bug
> their compiler vendor to do that. If something in the language
> prohibits that optimization, that would be worth fixing.
>
>
>
I'm not quite convinced it would be worth fixing, to be honest.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--20cf306844d5840edb04e12bf84c
Content-Type: text/html; charset=ISO-8859-1
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 10 July 2013 20:43, Jeffrey Yasskin <span dir="ltr"><<a href="mailto:jyasskin@google.com" target="_blank">jyasskin@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Both of these cost a small amount of code size with current compilers.<br>
The proposed syntax would make it fairly obvious that no extra<br>
function is emitted. However, I believe compilers could optimize<br>
either of the suggested alternatives into a shared vtable entry, and<br>
if the code size improvement is important to someone, they should bug<br>
their compiler vendor to do that. If something in the language<br>
prohibits that optimization, that would be worth fixing.<br>
<span class="HOEnZb"><font color="#888888"><br><br></font></span></blockquote><div><br></div><div>I'm not quite convinced it would be worth fixing, to be honest. <br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
<br />
<br />
--20cf306844d5840edb04e12bf84c--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 10 Jul 2013 13:22:45 -0700
Raw View
--nextPart3044531.lxhK53xoiW
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
On quarta-feira, 10 de julho de 2013 20.54.36, Ville Voutilainen wrote:
> On 10 July 2013 20:43, Jeffrey Yasskin <jyasskin@google.com> wrote:
> > Both of these cost a small amount of code size with current compilers.
> > The proposed syntax would make it fairly obvious that no extra
> > function is emitted. However, I believe compilers could optimize
> > either of the suggested alternatives into a shared vtable entry, and
> > if the code size improvement is important to someone, they should bug
> > their compiler vendor to do that. If something in the language
> > prohibits that optimization, that would be worth fixing.
>
> I'm not quite convinced it would be worth fixing, to be honest.
I don't see the point either. If the ABI in question allows one function to be
replaced with another entirely, then it's just an optimisation matter. Please
talk to your compiler people.
It might not be worth saving 16 bytes or less.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--nextPart3044531.lxhK53xoiW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iD8DBQBR3cKiM/XwBW70U1gRAgO5AJwKWelRflH11dx2qbt0GeYl35JjigCgtm9d
nHN7YY3Le45MVodmDVkQM90=
=TCwd
-----END PGP SIGNATURE-----
--nextPart3044531.lxhK53xoiW--
.
Author: cschueler@gmx.de
Date: Wed, 10 Jul 2013 15:30:15 -0700 (PDT)
Raw View
------=_Part_3_26757882.1373495415413
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi Joel, here is one such use case
class ScriptObject
{
virtual void OpCopyAssign( const ScriptObject * );
virtual void OpMoveAssign( ScriptObject * ) =3D &CopyAssign;
};
class ScriptNumber : public ScriptObject
{
// defines only OpCopyAssign
}
class ScriptString : public ScriptObject
{
// defines both
};
It would start to get interesting (and really useful) when the feature was=
=20
defined to be *covariant*.
Then the compiler would, as long as a derived class does not define its own=
=20
version of OpMoveAssign, use whatever version of OpCopyAssign it has=20
(derived or overridden).
Thus, you'll get the equivalent behavior of that
class ScriptObject
{
virtual void OpCopyAssign( const ScriptObject * );
virtual void OpMoveAssign( ScriptObject *other ) { OpCopyAssign( other=
=20
); } // virtual call
};
without the overhead of a 2nd virtual call.
Of course, if compilers would be smart enough to detect this configuration=
=20
and optimize the vtable entries along the way, that'd be great too. But the=
=20
ability to specify in the language that this behavior is explicitly wanted=
=20
is more conceptually pure.
On Wednesday, July 10, 2013 1:03:48 PM UTC+2, Klaim - Jo=EBl Lamotte wrote:
>
> Some questions, I'm just curious:
>
> 1. are there important differences with the following?
>
> struct foo
> {
> virtual void bar();
> virtual void baz() { bar(); } // this is inlined AFAIK, isn't it?
> };
>
> or maybe you're suggesting that there are more complex cases where=20
> it is not appropriate or maintanable to do it this way?
>
> 2. Do you have real use cases where you need such features?
>
> Joel Lamotte
>
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_3_26757882.1373495415413
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi Joel, here is one such use case<div><br></div><div><div style=3D"backgro=
und-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-w=
rap: break-word; " class=3D"prettyprint"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">class</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">ScriptO=
bject</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">virtual</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">OpCopyAssign</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">ScriptObject</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">virtual</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: rgb(102, 0, 102); ">Op</span><span class=3D"styled-by-prettify" style=3D"=
color: rgb(102, 0, 102); ">MoveAssign</span><span class=3D"styled-by-pretti=
fy" style=3D"color: rgb(102, 102, 0); ">(</span><span class=3D"styled-by-pr=
ettify" style=3D"color: rgb(0, 0, 0); "> </span><span class=3D"styled-by-pr=
ettify" style=3D"color: rgb(102, 0, 102); ">ScriptObject</span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0); "> </span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0); ">*</span><span c=
lass=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0); "> </span><span c=
lass=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0); ">)</span><sp=
an class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0); "> </span><sp=
an class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0); ">=3D</sp=
an><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0); "> </sp=
an><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0); ">&=
amp;</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 0, 1=
02); ">CopyAssign</span><span class=3D"styled-by-prettify" style=3D"color: =
rgb(102, 102, 0); ">;</span></div><div class=3D"subprettyprint"><span style=
=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color:=
#008;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">ScriptNumber</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">p=
ublic</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #606;" class=3D"styled-by-prettify">ScriptObject</=
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 styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><s=
pan style=3D"color: #800;" class=3D"styled-by-prettify">// defines only&nbs=
p;</span><span style=3D"color: rgb(102, 0, 102); ">Op</span><span style=3D"=
color: rgb(136, 0, 0); ">CopyAssign</span></div><div class=3D"subprettyprin=
t"><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span st=
yle=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">ScriptString</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">public</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify=
">ScriptObject</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><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: #800;" class=3D"styled-by-prettify">// =
defines both</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br><br>=
</span></div></code></div><br><div>It would start to get interesting (and r=
eally useful) when the feature was defined to be *covariant*.</div><div>The=
n the compiler would, as long as a derived class does not define its own ve=
rsion of OpMoveAssign, use whatever version of OpCopyAssign it has (derived=
or overridden).</div><div>Thus, you'll get the equivalent behavior of that=
</div><div><br></div><div><div style=3D"background-color: rgb(250, 250, 250=
); border: 1px solid rgb(187, 187, 187); word-wrap: break-word; " class=3D"=
prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><div=
class=3D"subprettyprint"><span class=3D"styled-by-prettify" style=3D"color=
: rgb(0, 0, 136); ">class</span><span class=3D"styled-by-prettify" style=3D=
"color: rgb(0, 0, 0); "> </span><span class=3D"styled-by-prettify" sty=
le=3D"color: rgb(102, 0, 102); ">ScriptObject</span><span class=3D"styled-b=
y-prettify" style=3D"color: rgb(0, 0, 0); "><br></span><span class=3D"style=
d-by-prettify" style=3D"color: rgb(102, 102, 0); ">{</span><span class=3D"s=
tyled-by-prettify" style=3D"color: rgb(0, 0, 0); "><br> <=
/span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 136); ">=
virtual</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, =
0); "> </span><span class=3D"styled-by-prettify" style=3D"color: rgb(0=
, 0, 136); ">void</span><span class=3D"styled-by-prettify" style=3D"color: =
rgb(0, 0, 0); "> </span><span class=3D"styled-by-prettify" style=3D"co=
lor: rgb(102, 0, 102); ">OpCopyAssign</span><span class=3D"styled-by-pretti=
fy" style=3D"color: rgb(102, 102, 0); ">(</span><span class=3D"styled-by-pr=
ettify" style=3D"color: rgb(0, 0, 0); "> </span><span class=3D"styled-=
by-prettify" style=3D"color: rgb(0, 0, 136); ">const</span><span class=3D"s=
tyled-by-prettify" style=3D"color: rgb(0, 0, 0); "> </span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(102, 0, 102); ">ScriptObject</s=
pan><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0); ">&nbs=
p;</span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 102, 0=
); ">*</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0=
); "> </span><span class=3D"styled-by-prettify" style=3D"color: rgb(10=
2, 102, 0); ">);</span><span class=3D"styled-by-prettify" style=3D"color: r=
gb(0, 0, 0); "><br> </span><span class=3D"styled-by-prett=
ify" style=3D"color: rgb(0, 0, 136); ">virtual</span><span class=3D"styled-=
by-prettify" style=3D"color: rgb(0, 0, 0); "> </span><span class=3D"st=
yled-by-prettify" style=3D"color: rgb(0, 0, 136); ">void</span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0); "> </span><span =
style=3D"color: rgb(102, 0, 102); ">Op</span><span class=3D"styled-by-prett=
ify" style=3D"color: rgb(102, 0, 102); ">MoveAssign</span><span class=3D"st=
yled-by-prettify" style=3D"color: rgb(102, 102, 0); ">(</span><span class=
=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0); "> </span><span =
class=3D"styled-by-prettify" style=3D"color: rgb(102, 0, 102); ">ScriptObje=
ct</span><span class=3D"styled-by-prettify" style=3D"color: rgb(0, 0, 0); "=
> </span><span class=3D"styled-by-prettify" style=3D"color: rgb(102, 1=
02, 0); ">*other</span><span class=3D"styled-by-prettify" style=3D"color: r=
gb(0, 0, 0); "> </span><span class=3D"styled-by-prettify" style=3D"col=
or: rgb(102, 102, 0); ">) { </span><span style=3D"color: rgb(102, 0, 1=
02); ">OpCopyAssign( other ); } // virtual call</span></div><div class=3D"s=
ubprettyprint"><span class=3D"styled-by-prettify" style=3D"color: rgb(102, =
102, 0); ">};</span></div></div></code></div><div><br></div>without the ove=
rhead of a 2nd virtual call.</div><div>Of course, if compilers would be sma=
rt enough to detect this configuration and optimize the vtable entries alon=
g the way, that'd be great too. But the ability to specify in the language =
that this behavior is explicitly wanted is more conceptually pure.</div><di=
v><br><br><br>On Wednesday, July 10, 2013 1:03:48 PM UTC+2, Klaim - Jo=EBl =
Lamotte wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>Some questions, I'm just curious:<div><br></div><div>1. are there importan=
t differences with the following?</div><div><br></div><div>struct foo</div>=
<div>{</div><div> virtual void bar();</div><div> &=
nbsp; virtual void baz() { bar(); } // this is inlined AFAIK, isn't i=
t?</div>
<div>};</div><div><br></div><div>or maybe you're suggesting that there are =
more complex cases where </div><div>it is not appropriate or maintanab=
le to do it this way?</div><div><br></div><div>2. Do you have real use case=
s where you need such features?</div>
<div><br></div><div>Joel Lamotte</div><div><br></div></div>
</blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_3_26757882.1373495415413--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 10 Jul 2013 17:38:15 -0500
Raw View
--001a11c3e0e45cc8c804e12ff1a6
Content-Type: text/plain; charset=ISO-8859-1
On 9 July 2013 17:34, <cschueler@gmx.de> wrote:
>
> struct foo
> {
> virtual void bar();
> virtual void baz() = &bar;
> };
>
> This shall mean, that the default implementation for baz() is bar(),
> unless this
> behavior is overridden in a derived class.
What is the intended output of the following program:
struct foo
{
virtual void bar() { cout << "foo::bar" << endl; }
virtual void baz() = &bar();
};
struct goo : foo
{
void bar() override { cout << "goo::bar" << endl; }
};
struct hoo : goo
{
void baz() override { cout << "hoo::baz" << endl; }
};
void print(foo const& f)
{
cout << "bar: "; f.bar();
cout << "baz: "; f.baz();
cout << endl;
}
int main()
{
print(foo());
print(goo());
print(hoo());
}
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c3e0e45cc8c804e12ff1a6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 9 July 2013 17:34, <span dir=3D"ltr"><<a href=3D"mailto:cschueler@gm=
x.de" target=3D"_blank">cschueler@gmx.de</a>></span> wrote:<br><div clas=
s=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">
<br style=3D"line-height:18px;font-size:12px;font-family:monospace"><div st=
yle=3D"background-color:rgb(250,250,250);border:1px solid rgb(187,187,187);=
word-wrap:break-word"><code><div><span style=3D"color:#008">struct</span><s=
pan style> foo<br>
</span><span style=3D"color:#660">{</span><span style><br>=A0 =A0 </span><s=
pan style=3D"color:#008">virtual</span><span style> </span><span style=3D"c=
olor:#008">void</span><span style> bar</span><span style=3D"color:#660">();=
</span><span style><br>
=A0 =A0 </span><span style=3D"color:#008">virtual</span><span style> </span=
><span style=3D"color:#008">void</span><span style> baz</span><span style=
=3D"color:#660">()</span><span style> </span><span style=3D"color:#660">=3D=
</span><span style> </span><span style=3D"color:#660">&</span><span sty=
le>bar</span><span style=3D"color:#660">;</span><span style><br>
</span><span style=3D"color:#660">};</span></div></code></div><span style=
=3D"line-height:18px;font-size:12px;font-family:monospace"><div><span style=
=3D"line-height:18px;font-size:12px;font-family:monospace"><br></span></div=
>This shall mean, that the default implementation for baz() is bar(), unles=
s this</span><br style=3D"line-height:18px;font-size:12px;font-family:monos=
pace">
<span style=3D"line-height:18px;font-size:12px;font-family:monospace">behav=
ior is overridden in a derived class.=A0</span></blockquote><div><br>What i=
s the intended output of the following program:<br><br>struct foo<br>{<br>
=A0=A0=A0 virtual void bar() { cout << "foo::bar" << =
endl; }<br>
=A0=A0=A0 virtual void baz() =3D &bar();<br>};<br><br>struct goo : foo<=
br>{<br>=A0=A0=A0 void bar() override { cout << "goo::bar" =
<< endl; }<br>};<br><br>struct hoo : goo<br>{<br>=A0=A0=A0 void baz()=
override { cout << "hoo::baz" << endl; }<br>
};<br><br>void print(foo const& f)<br>{<br>=A0=A0=A0 cout << &quo=
t;bar: "; f.bar();<br>=A0=A0=A0 cout << "baz: "; f.baz=
();<br>=A0=A0=A0 cout << endl;<br>}<br><br>int main()<br>{<br>=A0=A0=
=A0 print(foo());<br>
=A0=A0=A0 print(goo());<br>=A0=A0=A0 print(hoo());<br>}<br></div></div>-- <=
br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@evi=
loverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847) 69=
1-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--001a11c3e0e45cc8c804e12ff1a6--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 10 Jul 2013 17:51:34 -0700
Raw View
--nextPart1577858.Jka74vuAMS
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
On quarta-feira, 10 de julho de 2013 15.30.15, cschueler@gmx.de wrote:
> Hi Joel, here is one such use case
>
> class ScriptObject
> {
> virtual void OpCopyAssign( const ScriptObject * );
> virtual void OpMoveAssign( ScriptObject * ) = &CopyAssign;
> };
>
> class ScriptNumber : public ScriptObject
> {
> // defines only OpCopyAssign
> }
>
> class ScriptString : public ScriptObject
> {
> // defines both
> };
I don't see why you need explicit control over the vtable. What you want can
be easily achieved by the code you wrote below.
In most compilers today and architectures, that code will be one single
instruction. The compiler could optimise the two functions to be one and the
same by aliasing their symbol names, though. Maybe you want to talk to your
compiler vendor.
I don't think this violates anything in the standard, since you can't get the
non-virtual address of the function anyway.
> It would start to get interesting (and really useful) when the feature was
> defined to be *covariant*.
> Then the compiler would, as long as a derived class does not define its own
> version of OpMoveAssign, use whatever version of OpCopyAssign it has
> (derived or overridden).
> Thus, you'll get the equivalent behavior of that
>
> class ScriptObject
> {
>
> virtual void OpCopyAssign( const ScriptObject * );
> virtual void OpMoveAssign( ScriptObject *other ) { OpCopyAssign( other
>
> ); } // virtual call
> };
>
> without the overhead of a 2nd virtual call.
That's only possible if the passing of the arguments is compatible without a
thunk. That is entirely ABI-specific and we can't have a feature in the
standard that depends on the ABI.
Maybe the above case is trivial, but think of the case if OpCopyAssign had a
returned value. Or of covariant return types.
> Of course, if compilers would be smart enough to detect this configuration
> and optimize the vtable entries along the way, that'd be great too. But the
> ability to specify in the language that this behavior is explicitly wanted
> is more conceptually pure.
In my opinion, this is assuming too much about how compilers implement virtual
calls in the first place.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--nextPart1577858.Jka74vuAMS
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iD8DBQBR3gGjM/XwBW70U1gRAq/GAJwNgl07i2zQWo09D7GnVvMorFIr0gCgt+uq
K2yv+xvQqx5+JRZNeyq8sKQ=
=Oouv
-----END PGP SIGNATURE-----
--nextPart1577858.Jka74vuAMS--
.
Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Thu, 11 Jul 2013 12:49:29 -0700 (PDT)
Raw View
------=_Part_394_4318911.1373572169594
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
2013. j=FAlius 11., cs=FCt=F6rt=F6k 0:38:15 UTC+2 id=F5pontban Nevin ":-)" =
Liber a=20
k=F6vetkez=F5t =EDrta:
>
> On 9 July 2013 17:34, <csch...@gmx.de <javascript:>> wrote:
>
>>
>> struct foo
>> {
>> virtual void bar();
>> virtual void baz() =3D &bar;
>> };
>>
>> This shall mean, that the default implementation for baz() is bar(),=20
>> unless this
>> behavior is overridden in a derived class.=20
>
>
> What is the intended output of the following program:
>
> struct foo
> {
> virtual void bar() { cout << "foo::bar" << endl; }
> virtual void baz() =3D &bar();
> };
>
> struct goo : foo
> {
> void bar() override { cout << "goo::bar" << endl; }
> };
>
> struct hoo : goo
> {
> void baz() override { cout << "hoo::baz" << endl; }
> };
>
> void print(foo const& f)
> {
> cout << "bar: "; f.bar();
> cout << "baz: "; f.baz();
> cout << endl;
> }
>
> int main()
> {
> print(foo());
> print(goo());
> print(hoo());
> }
> --=20
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>> (847)=
=20
> 691-1404=20
If people's answer will be same or different to this question, it will show=
=20
if it is consistent of not.
Here is my take:
Foo has two entries in the vtable, bar and baz. Both points to the function=
=20
that prints foo::bar. So far:
bar: foo::bar
baz: foo::bar
Goo has the same two entries, overrides bar, but doesn't change baz:
bar: goo::bar
baz: foo::bar
Hoo keeps Goo's entry for bar, but overrides baz:
bar: goo::bar
baz: hoo::baz
I guess the key question was what happens at goo::baz..
To be honest, I find the feature interesting, and even relatively easy to=
=20
implement, but I don't really see high value of the feature. I would like=
=20
to see a better example, where the code is more simple and elegant using=20
this proposed syntax, but is hard to implement currently.
Regards, Robert
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_394_4318911.1373572169594
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>2013. j=FAlius 11., cs=FCt=F6rt=F6k 0:38:15 UTC+2 id=F5pontban Nevi=
n ":-)" Liber a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">On 9 July 2013 17:34, <span dir=3D"ltr"><<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"-HFSE1I-xCgJ">csch...@gmx.de</=
a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
<br style=3D"line-height:18px;font-size:12px;font-family:monospace"><div st=
yle=3D"background-color:rgb(250,250,250);border:1px solid rgb(187,187,187);=
word-wrap:break-word"><code><div><span style=3D"color:#008">struct</span><s=
pan> foo<br>
</span><span style=3D"color:#660">{</span><span><br> </span><s=
pan style=3D"color:#008">virtual</span><span> </span><span style=3D"color:#=
008">void</span><span> bar</span><span style=3D"color:#660">();</span><span=
><br>
</span><span style=3D"color:#008">virtual</span><span> </span=
><span style=3D"color:#008">void</span><span> baz</span><span style=3D"colo=
r:#660">()</span><span> </span><span style=3D"color:#660">=3D</span><span> =
</span><span style=3D"color:#660">&</span><span>bar</span><span style=
=3D"color:#660">;</span><span><br>
</span><span style=3D"color:#660">};</span></div></code></div><span style=
=3D"line-height:18px;font-size:12px;font-family:monospace"><div><span style=
=3D"line-height:18px;font-size:12px;font-family:monospace"><br></span></div=
>This shall mean, that the default implementation for baz() is bar(), unles=
s this</span><br style=3D"line-height:18px;font-size:12px;font-family:monos=
pace">
<span style=3D"line-height:18px;font-size:12px;font-family:monospace">behav=
ior is overridden in a derived class. </span></blockquote><div><br>Wha=
t is the intended output of the following program:<br><br>struct foo<br>{<b=
r>
virtual void bar() { cout << "foo::bar" << e=
ndl; }<br>
virtual void baz() =3D &bar();<br>};<br><br>struct g=
oo : foo<br>{<br> void bar() override { cout << "go=
o::bar" << endl; }<br>};<br><br>struct hoo : goo<br>{<br> =
void baz() override { cout << "hoo::baz" << endl; }<br>
};<br><br>void print(foo const& f)<br>{<br> cout <=
< "bar: "; f.bar();<br> cout << "baz: "; f.baz()=
;<br> cout << endl;<br>}<br><br>int main()<br>{<br>=
print(foo());<br>
print(goo());<br> print(hoo());<br>}<b=
r></div></div>-- <br> Nevin ":-)" Liber <mailto:<a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"-HFSE1I-xCgJ">ne...@e=
viloverlord.com</a><wbr>> (847) 691-1404
</blockquote><div><br>If people's answer will be same or different to this =
question, it will show if it is consistent of not.<br>Here is my take:<br><=
br>Foo has two entries in the vtable, bar and baz. Both points to the funct=
ion that prints foo::bar. So far:<br><div class=3D"prettyprint" style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">bar</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">bar<b=
r>baz</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">bar<br></span></div></code><=
/div>Goo has the same two entries, overrides bar, but doesn't change baz:<b=
r><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"subpretty=
print"><span style=3D"color: #000;" class=3D"styled-by-prettify">bar</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> goo</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">bar<br>baz</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">bar</span></div></code></div>Hoo keeps Goo's entry for bar, but=
overrides baz:<br><div class=3D"prettyprint" style=3D"background-color: rg=
b(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bo=
rder-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">bar</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> goo</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">bar<br>baz</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> hoo</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">baz</span></div></code></div>I guess the key q=
uestion was what happens at goo::baz..<br><br>To be honest, I find the feat=
ure interesting, and even relatively easy to implement, but I don't really =
see high value of the feature. I would like to see a better example, where =
the code is more simple and elegant using this proposed syntax, but is hard=
to implement currently.<br><br>Regards, Robert<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_394_4318911.1373572169594--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 11 Jul 2013 23:14:43 +0300
Raw View
--047d7bdc93967e92c004e1420bc4
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
On 11 July 2013 22:49, R=F3bert D=E1vid <lrdxgm@gmail.com> wrote:
>
>
> 2013. j=FAlius 11., cs=FCt=F6rt=F6k 0:38:15 UTC+2 id=F5pontban Nevin ":-)=
" Liber a
> k=F6vetkez=F5t =EDrta:
>>
>> On 9 July 2013 17:34, <csch...@gmx.de> wrote:
>>
>>>
>>> struct foo
>>> {
>>> virtual void bar();
>>> virtual void baz() =3D &bar;
>>> };
>>>
>>> This shall mean, that the default implementation for baz() is bar(),
>>> unless this
>>> behavior is overridden in a derived class.
>>
>>
>> What is the intended output of the following program:
>>
>> struct foo
>> {
>> virtual void bar() { cout << "foo::bar" << endl; }
>> virtual void baz() =3D &bar();
>> };
>>
>> struct goo : foo
>> {
>> void bar() override { cout << "goo::bar" << endl; }
>> };
>>
>> struct hoo : goo
>> {
>> void baz() override { cout << "hoo::baz" << endl; }
>> };
>>
>> void print(foo const& f)
>> {
>> cout << "bar: "; f.bar();
>> cout << "baz: "; f.baz();
>> cout << endl;
>> }
>>
>> int main()
>> {
>> print(foo());
>> print(goo());
>> print(hoo());
>> }
>> --
>> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com**> (847) 691-1404
>
>
> If people's answer will be same or different to this question, it will
> show if it is consistent of not.
> Here is my take:
>
> Foo has two entries in the vtable, bar and baz. Both points to the
> function that prints foo::bar. So far:
> bar: foo::bar
> baz: foo::bar
> Goo has the same two entries, overrides bar, but doesn't change baz:
> bar: goo::bar
> baz: foo::bar
> Hoo keeps Goo's entry for bar, but overrides baz:
> bar: goo::bar
> baz: hoo::baz
> I guess the key question was what happens at goo::baz..
>
>
I would expect the same result.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--047d7bdc93967e92c004e1420bc4
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 11 July 2013 22:49, R=F3bert D=E1vid <span dir=3D"ltr"><<a hr=
ef=3D"mailto:lrdxgm@gmail.com" target=3D"_blank">lrdxgm@gmail.com</a>></=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><br>2013. j=FAlius 11., cs=FCt=F6rt=F6k =
0:38:15 UTC+2 id=F5pontban Nevin ":-)" Liber a k=F6vetkez=F5t =ED=
rta:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On 9 July 2013 17:34, <span dir=3D"ltr"><<a>csch...@g=
mx.de</a>></span> wrote:<br><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<br style=3D"line-height:18px;font-size:12px;font-family:monospace"><div st=
yle=3D"background-color:rgb(250,250,250);border:1px solid rgb(187,187,187);=
word-wrap:break-word"><code><div><span style=3D"color:#008">struct</span><s=
pan> foo<br>
</span><span style=3D"color:#660">{</span><span><br>=A0 =A0 </span><span st=
yle=3D"color:#008">virtual</span><span> </span><span style=3D"color:#008">v=
oid</span><span> bar</span><span style=3D"color:#660">();</span><span><br>
=A0 =A0 </span><span style=3D"color:#008">virtual</span><span> </span><span=
style=3D"color:#008">void</span><span> baz</span><span style=3D"color:#660=
">()</span><span> </span><span style=3D"color:#660">=3D</span><span> </span=
><span style=3D"color:#660">&</span><span>bar</span><span style=3D"colo=
r:#660">;</span><span><br>
</span><span style=3D"color:#660">};</span></div></code></div><span style=
=3D"line-height:18px;font-size:12px;font-family:monospace"><div><span style=
=3D"line-height:18px;font-size:12px;font-family:monospace"><br></span></div=
>This shall mean, that the default implementation for baz() is bar(), unles=
s this</span><br style=3D"line-height:18px;font-size:12px;font-family:monos=
pace">
<span style=3D"line-height:18px;font-size:12px;font-family:monospace">behav=
ior is overridden in a derived class.=A0</span></blockquote><div><br>What i=
s the intended output of the following program:<br><br>struct foo<br>{<br>
=A0=A0=A0 virtual void bar() { cout << "foo::bar" << =
endl; }<br>
=A0=A0=A0 virtual void baz() =3D &bar();<br>};<br><br>struct goo : foo<=
br>{<br>=A0=A0=A0 void bar() override { cout << "goo::bar" =
<< endl; }<br>};<br><br>struct hoo : goo<br>{<br>=A0=A0=A0 void baz()=
override { cout << "hoo::baz" << endl; }<br>
};<br><br>void print(foo const& f)<br>{<br>=A0=A0=A0 cout << &quo=
t;bar: "; f.bar();<br>=A0=A0=A0 cout << "baz: "; f.baz=
();<br>=A0=A0=A0 cout << endl;<br>}<br><br>int main()<br>{<br>=A0=A0=
=A0 print(foo());<br>
=A0=A0=A0 print(goo());<br>=A0=A0=A0 print(hoo());<br>}<br></div></div>-- <=
br></div>=A0Nevin ":-)" Liber=A0 <mailto:<a>ne...@eviloverlord=
..com</a><u></u>>=A0 (847) 691-1404
</blockquote><div><br>If people's answer will be same or different to t=
his question, it will show if it is consistent of not.<br>Here is my take:<=
br><br>Foo has two entries in the vtable, bar and baz. Both points to the f=
unction that prints foo::bar. So far:<br>
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,18=
7);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><sp=
an style>bar</span><span style=3D"color:#660">:</span><span style> foo</spa=
n><span style=3D"color:#660">::</span><span style>bar<br>
baz</span><span style=3D"color:#660">:</span><span style> foo</span><span s=
tyle=3D"color:#660">::</span><span style>bar<br></span></div></code></div>G=
oo has the same two entries, overrides bar, but doesn't change baz:<br>
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,18=
7);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><sp=
an style>bar</span><span style=3D"color:#660">:</span><span style> goo</spa=
n><span style=3D"color:#660">::</span><span style>bar<br>
baz</span><span style=3D"color:#660">:</span><span style> foo</span><span s=
tyle=3D"color:#660">::</span><span style>bar</span></div></code></div>Hoo k=
eeps Goo's entry for bar, but overrides baz:<br><div style=3D"backgroun=
d-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;b=
order-width:1px;word-wrap:break-word">
<code><div><span style>bar</span><span style=3D"color:#660">:</span><span s=
tyle> goo</span><span style=3D"color:#660">::</span><span style>bar<br>baz<=
/span><span style=3D"color:#660">:</span><span style> hoo</span><span style=
=3D"color:#660">::</span><span style>baz</span></div>
</code></div>I guess the key question was what happens at goo::baz..<br><br=
></div></blockquote><div><br></div><div>I would expect the same result. <br=
></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--047d7bdc93967e92c004e1420bc4--
.
Author: Michael Price - Dev <michael.b.price.dev@gmail.com>
Date: Thu, 11 Jul 2013 18:13:03 -0700 (PDT)
Raw View
This is quite similar to an idea that I've been mulling over for more than a year. Function aliasing.
Currently you can achieve something like this with function pointers, but they have certain limitations.
Here's an example of one use I was envisioning:
template <typename T>
void func(int myInt, const char* myStr, bool myBool)
{
T::something(myInt, myStr, myBool);
}
struct thing_i_dont_control
{
static int doIt(int, const char*, bool);
};
// essentially a concept map
struct map_it
{
using something = thing_i_dont_control::doIt;
};
func<map_it>(1, "a", true);
This would be even better if it allowed for parameter reordering and providing defaults.
The examples provided so far have been "simple" functions. When you get functions that take five or six parameters that need to be forwarded, it gets a bit verbose (and I'd argue error prone).
I also have a gut feeling that this type of technique can be used for some interesting dependency injection and mocking scenarios, but I haven't fully developed those ideas.
True, my thoughts have nothing to do with virtual functions, but I believe the ideas presented thus far are similar enough to broaden the discussion.
And apologies for the poor formatting, this was from my mobile.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 12 Jul 2013 07:37:42 +0200
Raw View
This is a multi-part message in MIME format.
--------------090302080809020105030007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 11/07/13 22:14, Ville Voutilainen a =E9crit :
>
>
>
> On 11 July 2013 22:49, R=F3bert D=E1vid <lrdxgm@gmail.com=20
> <mailto:lrdxgm@gmail.com>> wrote:
>
>
>
> 2013. j=FAlius 11., cs=FCt=F6rt=F6k 0:38:15 UTC+2 ido"pontban Nevin "=
:-)"
> Liber a k=F6vetkezo"t =EDrta:
>
> On 9 July 2013 17:34, <csch...@gmx.de> wrote:
>
>
> |
> structfoo
> {
> virtualvoidbar();
> virtualvoidbaz()=3D&bar;
> };
> |
>
> This shall mean, that the default implementation for baz()
> is bar(), unless this
> behavior is overridden in a derived class.=20
>
>
> What is the intended output of the following program:
>
> struct foo
> {
> virtual void bar() { cout << "foo::bar" << endl; }
> virtual void baz() =3D &bar();
> };
>
> struct goo : foo
> {
> void bar() override { cout << "goo::bar" << endl; }
> };
>
> struct hoo : goo
> {
> void baz() override { cout << "hoo::baz" << endl; }
> };
>
> void print(foo const& f)
> {
> cout << "bar: "; f.bar();
> cout << "baz: "; f.baz();
> cout << endl;
> }
>
> int main()
> {
> print(foo());
> print(goo());
> print(hoo());
> }
> --=20
> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com> (847)
> 691-1404=20
>
>
> If people's answer will be same or different to this question, it
> will show if it is consistent of not.
> Here is my take:
>
> Foo has two entries in the vtable, bar and baz. Both points to the
> function that prints foo::bar. So far:
> |
> bar:foo::bar
> baz:foo::bar
> |
> Goo has the same two entries, overrides bar, but doesn't change baz:
> |
> bar:goo::bar
> baz:foo::bar
> |
> Hoo keeps Goo's entry for bar, but overrides baz:
> |
> bar:goo::bar
> baz:hoo::baz
> |
> I guess the key question was what happens at goo::baz..
>
>
> I would expect the same result.
>
>
Not me. I would expect that goo::baz vtable entry is &goo::bar as the=20
declaration
virtual void baz() =3D &bar();
is a shortcut for
virtual void baz() { bar() }
Otherwise I don't see the interest.
Vicente
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--------------090302080809020105030007
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 11/07/13 22:14, Ville Voutilainen a
écrit :<br>
</div>
<blockquote
cite="mid:CAFk2RUaxxKkxDMj=oLxy9g54jt3ZnnzEA0_gkieMrzRKCKUNcg@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 11 July 2013 22:49, Róbert Dávid <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:lrdxgm@gmail.com" target="_blank">lrdxgm@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
2013. július 11., csütörtök 0:38:15 UTC+2 időpontban Nevin
":-)" Liber a következőt írta:
<blockquote class="gmail_quote"
style="margin:0;margin-left:0.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div class="im">On 9 July 2013 17:34, <span dir="ltr"><<a
moz-do-not-send="true">csch...@gmx.de</a>></span>
wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br
style="line-height:18px;font-size:12px;font-family:monospace">
<div
style="background-color:rgb(250,250,250);border:1px
solid rgb(187,187,187);word-wrap:break-word"><code>
<div><span style="color:#008">struct</span><span>
foo<br>
</span><span style="color:#660">{</span><span><br>
</span><span style="color:#008">virtual</span><span>
</span><span style="color:#008">void</span><span>
bar</span><span style="color:#660">();</span><span><br>
</span><span style="color:#008">virtual</span><span>
</span><span style="color:#008">void</span><span>
baz</span><span style="color:#660">()</span><span>
</span><span style="color:#660">=</span><span>
</span><span style="color:#660">&</span><span>bar</span><span
style="color:#660">;</span><span><br>
</span><span style="color:#660">};</span></div>
</code></div>
<span
style="line-height:18px;font-size:12px;font-family:monospace">
<div><span
style="line-height:18px;font-size:12px;font-family:monospace"><br>
</span></div>
This shall mean, that the default implementation
for baz() is bar(), unless this</span><br
style="line-height:18px;font-size:12px;font-family:monospace">
<span
style="line-height:18px;font-size:12px;font-family:monospace">behavior
is overridden in a derived class. </span></blockquote>
<div><br>
What is the intended output of the following
program:<br>
<br>
struct foo<br>
{<br>
virtual void bar() { cout << "foo::bar"
<< endl; }<br>
virtual void baz() = &bar();<br>
};<br>
<br>
struct goo : foo<br>
{<br>
void bar() override { cout << "goo::bar"
<< endl; }<br>
};<br>
<br>
struct hoo : goo<br>
{<br>
void baz() override { cout << "hoo::baz"
<< endl; }<br>
};<br>
<br>
void print(foo const& f)<br>
{<br>
cout << "bar: "; f.bar();<br>
cout << "baz: "; f.baz();<br>
cout << endl;<br>
}<br>
<br>
int main()<br>
{<br>
print(foo());<br>
print(goo());<br>
print(hoo());<br>
}<br>
</div>
</div>
-- <br>
</div>
Nevin ":-)" Liber <mailto:<a moz-do-not-send="true">ne...@eviloverlord.com</a>>
(847) 691-1404
</blockquote>
<div><br>
If people's answer will be same or different to this
question, it will show if it is consistent of not.<br>
Here is my take:<br>
<br>
Foo has two entries in the vtable, bar and baz. Both
points to the function that prints foo::bar. So far:<br>
<div
style="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="">bar</span><span
style="color:#660">:</span><span style=""> foo</span><span
style="color:#660">::</span><span style="">bar<br>
baz</span><span style="color:#660">:</span><span
style=""> foo</span><span style="color:#660">::</span><span
style="">bar<br>
</span></div>
</code></div>
Goo has the same two entries, overrides bar, but doesn't
change baz:<br>
<div
style="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="">bar</span><span
style="color:#660">:</span><span style=""> goo</span><span
style="color:#660">::</span><span style="">bar<br>
baz</span><span style="color:#660">:</span><span
style=""> foo</span><span style="color:#660">::</span><span
style="">bar</span></div>
</code></div>
Hoo keeps Goo's entry for bar, but overrides baz:<br>
<div
style="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="">bar</span><span
style="color:#660">:</span><span style=""> goo</span><span
style="color:#660">::</span><span style="">bar<br>
baz</span><span style="color:#660">:</span><span
style=""> hoo</span><span style="color:#660">::</span><span
style="">baz</span></div>
</code></div>
I guess the key question was what happens at goo::baz..<br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>I would expect the same result. <br>
</div>
</div>
<br>
</div>
</div>
<br>
</blockquote>
Not me. I would expect that goo::baz vtable entry is &goo::bar
as the declaration<br>
<br>
virtual void baz() = &bar();<br>
<br>
is a shortcut for<br>
<br>
virtual void baz() { bar() } <br>
<br>
Otherwise I don't see the interest.<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
<br />
<br />
--------------090302080809020105030007--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 12 Jul 2013 13:16:40 +0300
Raw View
--001a11c3d0e68a5eda04e14dce95
Content-Type: text/plain; charset=ISO-8859-1
On 12 July 2013 08:37, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>wrote:
> Not me. I would expect that goo::baz vtable entry is &goo::bar as the
> declaration
>
>
> virtual void baz() = &bar();
>
> is a shortcut for
>
> virtual void baz() { bar() }
>
> Otherwise I don't see the interest.
>
>
>
If that's the shortcut you expect baz() = &bar(); to mean, then goo::baz()
should
override that behavior to not invoke bar() at all. Perhaps you expect the
"shortcut"
to be different.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c3d0e68a5eda04e14dce95
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 12 July 2013 08:37, Vicente J. Botet Escriba <span dir=3D"ltr">&=
lt;<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.bo=
tet@wanadoo.fr</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">Not me. I would expect that goo=
::baz vtable entry is &goo::bar
as the declaration<div class=3D"im"><br>
<br>
=A0 virtual void baz() =3D &bar();<br>
<br></div>
is a shortcut for<br>
<br>
=A0 virtual void baz() { bar() }=A0 <br>
<br>
Otherwise I don't see the interest.<span class=3D"HOEnZb"><font col=
or=3D"#888888"><br>
<br><br></font></span></div></blockquote><div><br></div><div>If that=
9;s the shortcut you expect baz() =3D &bar();=A0 to mean, then goo::baz=
() should<br>override that behavior to not invoke bar() at all. Perhaps you=
expect the "shortcut"<br>
to be different.<br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--001a11c3d0e68a5eda04e14dce95--
.
Author: =?UTF-8?Q?R=C3=B3bert_D=C3=A1vid?= <lrdxgm@gmail.com>
Date: Fri, 12 Jul 2013 10:31:33 -0700 (PDT)
Raw View
------=_Part_461_7153826.1373650293490
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
2013. j=FAlius 12., p=E9ntek 7:37:42 UTC+2 id=F5pontban Vicente J. Botet Es=
criba=20
a k=F6vetkez=F5t =EDrta:
>
> Le 11/07/13 22:14, Ville Voutilainen a =E9crit :
> =20
>
>
>
> On 11 July 2013 22:49, R=F3bert D=E1vid <lrd...@gmail.com <javascript:>>w=
rote:
>
>>
>>
>> 2013. j=FAlius 11., cs=FCt=F6rt=F6k 0:38:15 UTC+2 id=F5pontban Nevin ":-=
)" Liber a=20
>> k=F6vetkez=F5t =EDrta:=20
>>>
>>> On 9 July 2013 17:34, <csch...@gmx.de> wrote:
>>> =20
>>>>
>>>> struct foo
>>>> {
>>>> virtual void bar();
>>>> virtual void baz() =3D &bar;
>>>> };
>>>> =20
>>>> This shall mean, that the default implementation for baz() is bar(),=
=20
>>>> unless this
>>>> behavior is overridden in a derived class.=20
>>>
>>>
>>> What is the intended output of the following program:
>>>
>>> struct foo
>>> {
>>> virtual void bar() { cout << "foo::bar" << endl; }
>>> virtual void baz() =3D &bar();
>>> };
>>>
>>> struct goo : foo
>>> {
>>> void bar() override { cout << "goo::bar" << endl; }
>>> };
>>>
>>> struct hoo : goo
>>> {
>>> void baz() override { cout << "hoo::baz" << endl; }
>>> };
>>>
>>> void print(foo const& f)
>>> {
>>> cout << "bar: "; f.bar();
>>> cout << "baz: "; f.baz();
>>> cout << endl;
>>> }
>>>
>>> int main()
>>> {
>>> print(foo());
>>> print(goo());
>>> print(hoo());
>>> }
>>> --=20
>>> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com> (847) 691-1404=20
>>
>>
>> If people's answer will be same or different to this question, it will=
=20
>> show if it is consistent of not.
>> Here is my take:
>>
>> Foo has two entries in the vtable, bar and baz. Both points to the=20
>> function that prints foo::bar. So far:
>> bar: foo::bar
>> baz: foo::bar
>> Goo has the same two entries, overrides bar, but doesn't change baz:
>> bar: goo::bar
>> baz: foo::bar
>> Hoo keeps Goo's entry for bar, but overrides baz:
>> bar: goo::bar
>> baz: hoo::baz
>> I guess the key question was what happens at goo::baz..
>>
>> =20
> I would expect the same result.=20
> =20
> =20
> Not me. I would expect that goo::baz vtable entry is &goo::bar as the=20
> declaration
>
> virtual void baz() =3D &bar();
>
> is a shortcut for
>
> virtual void baz() { bar() } =20
>
> Otherwise I don't see the interest.
>
> Vicente
>
If you interpret it as that, this features has absolute zero value - it is=
=20
even LONGER to write than what it was shortcut to ("=3D&x;" vs. "{x}").
However, if you interpret is as defining a vtable entry that points to the=
=20
very same function, that is different, it might be useful. But as I said,=
=20
still needs a better usecase.
Regards, Robert
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_461_7153826.1373650293490
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>2013. j=FAlius 12., p=E9ntek 7:37:42 UTC+2 id=F5pontban Vicente J. =
Botet Escriba a k=F6vetkez=F5t =EDrta:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 11/07/13 22:14, Ville Voutilainen a
=E9crit :<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
<div><br>
<br>
<div class=3D"gmail_quote">On 11 July 2013 22:49, R=F3bert D=E1vi=
d <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"9-uuPgQ79ZgJ">lrd...@gmail.com</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><br>
<br>
2013. j=FAlius 11., cs=FCt=F6rt=F6k 0:38:15 UTC+2 id=F5pontba=
n Nevin
":-)" Liber a k=F6vetkez=F5t =EDrta:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 9 July 2013 17:34, <span dir=3D"ltr"><<a>csch...=
@gmx.de</a>></span>
wrote:<br>
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br style=3D"line-height:18px;font-size:12px;font-fam=
ily:monospace">
<div style=3D"background-color:rgb(250,250,250);borde=
r:1px solid rgb(187,187,187);word-wrap:break-word"><code>
<div><span style=3D"color:#008">struct</span><spa=
n>
foo<br>
</span><span style=3D"color:#660">{</span><span=
><br>
</span><span style=3D"color:#00=
8">virtual</span><span>
</span><span style=3D"color:#008">void</span><s=
pan>
bar</span><span style=3D"color:#660">();</spa=
n><span><br>
</span><span style=3D"color:#00=
8">virtual</span><span>
</span><span style=3D"color:#008">void</span><s=
pan>
baz</span><span style=3D"color:#660">()</span=
><span>
</span><span style=3D"color:#660">=3D</span><sp=
an>
</span><span style=3D"color:#660">&</span><=
span>bar</span><span style=3D"color:#660">;</span><span><br>
</span><span style=3D"color:#660">};</span></di=
v>
</code></div>
<span style=3D"line-height:18px;font-size:12px;font-f=
amily:monospace">
<div><span style=3D"line-height:18px;font-size:12px=
;font-family:monospace"><br>
</span></div>
This shall mean, that the default implementation
for baz() is bar(), unless this</span><br style=3D"=
line-height:18px;font-size:12px;font-family:monospace">
<span style=3D"line-height:18px;font-size:12px;font-f=
amily:monospace">behavior
is overridden in a derived class. </span></blo=
ckquote>
<div><br>
What is the intended output of the following
program:<br>
<br>
struct foo<br>
{<br>
virtual void bar() { cout <<=
"foo::bar"
<< endl; }<br>
virtual void baz() =3D &bar();=
<br>
};<br>
<br>
struct goo : foo<br>
{<br>
void bar() override { cout <<=
; "goo::bar"
<< endl; }<br>
};<br>
<br>
struct hoo : goo<br>
{<br>
void baz() override { cout <<=
; "hoo::baz"
<< endl; }<br>
};<br>
<br>
void print(foo const& f)<br>
{<br>
cout << "bar: "; f.bar();<br=
>
cout << "baz: "; f.baz();<br=
>
cout << endl;<br>
}<br>
<br>
int main()<br>
{<br>
print(foo());<br>
print(goo());<br>
print(hoo());<br>
}<br>
</div>
</div>
-- <br>
</div>
Nevin ":-)" Liber <mailto:<a>ne...@eviloverl=
ord.com</a><wbr>>
(847) 691-1404
</blockquote>
<div><br>
If people's answer will be same or different to this
question, it will show if it is consistent of not.<br>
Here is my take:<br>
<br>
Foo has two entries in the vtable, bar and baz. Both
points to the function that prints foo::bar. So far:<br>
<div style=3D"background-color:rgb(250,250,250);border-colo=
r:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word=
"><code>
<div><span>bar</span><span style=3D"color:#660">:</span=
><span> foo</span><span style=3D"color:#660">::</span><span>bar<br>
baz</span><span style=3D"color:#660">:</span><span>=
foo</span><span style=3D"color:#660">::</span><span>bar<br>
</span></div>
</code></div>
Goo has the same two entries, overrides bar, but doesn't
change baz:<br>
<div style=3D"background-color:rgb(250,250,250);border-colo=
r:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word=
"><code>
<div><span>bar</span><span style=3D"color:#660">:</span=
><span> goo</span><span style=3D"color:#660">::</span><span>bar<br>
baz</span><span style=3D"color:#660">:</span><span>=
foo</span><span style=3D"color:#660">::</span><span>bar</span></div>
</code></div>
Hoo keeps Goo's entry for bar, but overrides baz:<br>
<div style=3D"background-color:rgb(250,250,250);border-colo=
r:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word=
"><code>
<div><span>bar</span><span style=3D"color:#660">:</span=
><span> goo</span><span style=3D"color:#660">::</span><span>bar<br>
baz</span><span style=3D"color:#660">:</span><span>=
hoo</span><span style=3D"color:#660">::</span><span>baz</span></div>
</code></div>
I guess the key question was what happens at goo::baz..<br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>I would expect the same result. <br>
</div>
</div>
<br>
</div>
</div>
<br>
</blockquote>
Not me. I would expect that goo::baz vtable entry is &goo::bar
as the declaration<br>
<br>
virtual void baz() =3D &bar();<br>
<br>
is a shortcut for<br>
<br>
virtual void baz() { bar() } <br>
<br>
Otherwise I don't see the interest.<br>
<br>
Vicente<br></div></blockquote><div><br>If you interpret it as that, thi=
s features has absolute zero value - it is even LONGER to write than what i=
t was shortcut to ("=3D&x;" vs. "{x}").<br><br>However, if you interpre=
t is as defining a vtable entry that points to the very same function, that=
is different, it might be useful. But as I said, still needs a better usec=
ase.<br><br>Regards, Robert<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_461_7153826.1373650293490--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 12 Jul 2013 21:55:17 +0300
Raw View
--001a11c2ed4a3a0f6204e1550d49
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 12 July 2013 20:31, R=F3bert D=E1vid <lrdxgm@gmail.com> wrote:
> Not me. I would expect that goo::baz vtable entry is &goo::bar as the
> declaration
>
>>
>> virtual void baz() =3D &bar();
>>
>> is a shortcut for
>>
>> virtual void baz() { bar() }
>>
>> Otherwise I don't see the interest.
>>
>> Vicente
>>
>
> If you interpret it as that, this features has absolute zero value - it i=
s
> even LONGER to write than what it was shortcut to ("=3D&x;" vs. "{x}").
>
> However, if you interpret is as defining a vtable entry that points to th=
e
> very same function, that is different, it might be useful. But as I said,
> still needs a better usecase.
>
>
The whole idea in this proposal is that virtual void baz() =3D &bar(); is
almost but not quite equivalent
to a baz that calls bar, because the "slot" of baz has the same function
pointer implementation-wise
as bar does. Even so, when a derived class overrides baz, it overrides baz,
not bar. The override
of bar is up to discussion; the original vtable is so that baz/bar point to
the base implementation
of bar. If bar is overridden, should the vtable entry for baz now point to
that override? It makes
rather little sense not to, since otherwise calls to bar would call the new
override but calls to
baz would still invoke the base bar, as was my and Robert's thinking in our
replies. I think it needs to be so
that print(goo); prints
goo::bar
goo::bar
I don't know how to implement that. I'm not sure there's reserved space in
a vtable to record the
information that a vtable entry "aliases" another and when that "another"
is overridden, the alias
should update too.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--001a11c2ed4a3a0f6204e1550d49
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 12 July 2013 20:31, R=F3bert D=E1vid <span dir=3D"ltr"><<a hr=
ef=3D"mailto:lrdxgm@gmail.com" target=3D"_blank">lrdxgm@gmail.com</a>></=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">Not me. I would expect th=
at goo::baz vtable entry is &goo::bar
as the declaration<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div bgcolor=3D"#FFFFFF" text=3D"#000000"><div><div class=3D"h5">
<br>
=A0 virtual void baz() =3D &bar();<br>
<br>
is a shortcut for<br>
<br>
=A0 virtual void baz() { bar() }=A0 <br>
<br>
Otherwise I don't see the interest.<br>
<br>
Vicente<br></div></div></div></blockquote><div><br>If you interpret it =
as that, this features has absolute zero value - it is even LONGER to write=
than what it was shortcut to ("=3D&x;" vs. "{x}").=
<br>
<br>However, if you interpret is as defining a vtable entry that points to =
the very same function, that is different, it might be useful. But as I sai=
d, still needs a better usecase.<br><br></div></blockquote><div><br></div>
<div>The whole idea in this proposal is that virtual void baz() =3D &ba=
r(); is almost but not quite equivalent<br>to a baz that calls bar, because=
the "slot" of baz has the same function pointer implementation-w=
ise<br>
as bar does. Even so, when a derived class overrides baz, it overrides baz,=
not bar. The override<br>of bar is up to discussion; the original vtable i=
s so that baz/bar point to the base implementation<br></div><div>of bar. If=
bar is overridden, should the vtable entry for baz now point to that overr=
ide? It makes<br>
</div><div>rather little sense not to, since otherwise calls to bar would c=
all the new override but calls to<br>baz would still invoke the base bar, a=
s was my and Robert's thinking in our replies. I think it needs to be s=
o<br>
that print(goo); prints<br>goo::bar<br>goo::bar<br><br></div><div>I don'=
;t know how to implement that. I'm not sure there's reserved space =
in a vtable to record the<br>information that a vtable entry "aliases&=
quot; another and when that "another" is overridden, the alias<br=
>
should update too.<br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--001a11c2ed4a3a0f6204e1550d49--
.
Author: cschueler@gmx.de
Date: Tue, 16 Jul 2013 14:57:21 -0700 (PDT)
Raw View
------=_Part_132_29070551.1374011841531
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
The proposal really only useful if goo is going to print
bar: goo:bar
baz: goo:bar
so that the declaration "=3D &bar" is covariant, i.e. the vtable entry of b=
az=20
co-varies with the vtable entry of bar, until the link is broken with with=
=20
a manual override of baz.=20
Therein lies the utility of the proposal, otherwise it would just be=20
syntactic sugar for a qualified, non-virtual call.
In the case of above, the vtable of class "goo" already has an entry for=20
baz, so there is no problem in regard to missing vtable slot.
Think about header files that are published as part of an SDK interface, in=
=20
anticipation that 3rd party programmers are going to derive from it. With=
=20
this proposal, it would be possible for the interface author to=20
specify that "baz =3D &bar", and if a user does not wish to override baz, h=
e=20
gets the reasonable default behavior (i.e. a call to baz will call his=20
*overridden* version of bar) with out the penalty of a double dispatch.=20
This is IMHO better than just having a documentation that says "but you=20
also must override baz" etc.
On Friday, July 12, 2013 8:55:17 PM UTC+2, Ville Voutilainen wrote:
>
>
>
>
> On 12 July 2013 20:31, R=F3bert D=E1vid <lrd...@gmail.com <javascript:>>w=
rote:
>
>> Not me. I would expect that goo::baz vtable entry is &goo::bar as the=20
>> declaration
>>
>>>
>>> virtual void baz() =3D &bar();
>>>
>>> is a shortcut for
>>>
>>> virtual void baz() { bar() } =20
>>>
>>> Otherwise I don't see the interest.
>>>
>>> Vicente
>>>
>>
>> If you interpret it as that, this features has absolute zero value - it=
=20
>> is even LONGER to write than what it was shortcut to ("=3D&x;" vs. "{x}"=
).
>>
>> However, if you interpret is as defining a vtable entry that points to=
=20
>> the very same function, that is different, it might be useful. But as I=
=20
>> said, still needs a better usecase.
>>
>>
> The whole idea in this proposal is that virtual void baz() =3D &bar(); is=
=20
> almost but not quite equivalent
> to a baz that calls bar, because the "slot" of baz has the same function=
=20
> pointer implementation-wise
> as bar does. Even so, when a derived class overrides baz, it overrides=20
> baz, not bar. The override
> of bar is up to discussion; the original vtable is so that baz/bar point=
=20
> to the base implementation
> of bar. If bar is overridden, should the vtable entry for baz now point t=
o=20
> that override? It makes
> rather little sense not to, since otherwise calls to bar would call the=
=20
> new override but calls to
> baz would still invoke the base bar, as was my and Robert's thinking in=
=20
> our replies. I think it needs to be so
> that print(goo); prints
> goo::bar
> goo::bar
>
> I don't know how to implement that. I'm not sure there's reserved space i=
n=20
> a vtable to record the
> information that a vtable entry "aliases" another and when that "another"=
=20
> is overridden, the alias
> should update too.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_132_29070551.1374011841531
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div><br></div><div>The proposal really only useful if goo is going to prin=
t<br></div><div><br></div><div>bar: goo:bar</div><div>baz: goo:bar</div><di=
v><br></div><div>so that the declaration "=3D &bar" is covariant, i.e. =
the vtable entry of baz co-varies with the vtable entry of bar, until the l=
ink is broken with with a manual override of baz. </div><div>Therein l=
ies the utility of the proposal, otherwise it would just be syntactic sugar=
for a qualified, non-virtual call.<br></div><div><br></div><div>In the cas=
e of above, the vtable of class "goo" already has an entry for baz, so ther=
e is no problem in regard to missing vtable slot.</div><div><br></div><div>=
Think about header files that are published as part of an SDK interfac=
e, in anticipation that 3rd party programmers are going to derive from it. =
With this proposal, it would be possible for the interface author to specif=
y that "baz =3D &bar", and if a user does not wish to override baz=
, he gets the reasonable default behavior (i.e. a call to baz will call his=
*overridden* version of bar) with out the penalty of a double dispatch. Th=
is is IMHO better than just having a documentation that says "but you also =
must override baz" etc.</div><div><br></div><br><br>On Friday, July 12, 201=
3 8:55:17 PM UTC+2, Ville Voutilainen wrote:<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"><br><div><br><br><div class=3D"gmail_quote">=
On 12 July 2013 20:31, R=F3bert D=E1vid <span dir=3D"ltr"><<a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"4CbNTesIuZcJ">lrd...@=
gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">Not me. I would expect th=
at goo::baz vtable entry is &goo::bar
as the declaration<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div bgcolor=3D"#FFFFFF" text=3D"#000000"><div><div>
<br>
virtual void baz() =3D &bar();<br>
<br>
is a shortcut for<br>
<br>
virtual void baz() { bar() } <br>
<br>
Otherwise I don't see the interest.<br>
<br>
Vicente<br></div></div></div></blockquote><div><br>If you interpret it =
as that, this features has absolute zero value - it is even LONGER to write=
than what it was shortcut to ("=3D&x;" vs. "{x}").<br>
<br>However, if you interpret is as defining a vtable entry that points to =
the very same function, that is different, it might be useful. But as I sai=
d, still needs a better usecase.<br><br></div></blockquote><div><br></div>
<div>The whole idea in this proposal is that virtual void baz() =3D &ba=
r(); is almost but not quite equivalent<br>to a baz that calls bar, because=
the "slot" of baz has the same function pointer implementation-wise<br>
as bar does. Even so, when a derived class overrides baz, it overrides baz,=
not bar. The override<br>of bar is up to discussion; the original vtable i=
s so that baz/bar point to the base implementation<br></div><div>of bar. If=
bar is overridden, should the vtable entry for baz now point to that overr=
ide? It makes<br>
</div><div>rather little sense not to, since otherwise calls to bar would c=
all the new override but calls to<br>baz would still invoke the base bar, a=
s was my and Robert's thinking in our replies. I think it needs to be so<br=
>
that print(goo); prints<br>goo::bar<br>goo::bar<br><br></div><div>I don't k=
now how to implement that. I'm not sure there's reserved space in a vtable =
to record the<br>information that a vtable entry "aliases" another and when=
that "another" is overridden, the alias<br>
should update too.<br></div></div></div></div>
</blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
------=_Part_132_29070551.1374011841531--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 16 Jul 2013 17:14:05 -0500
Raw View
--047d7b2e5290f3999a04e1a84dea
Content-Type: text/plain; charset=ISO-8859-1
On 16 July 2013 16:57, <cschueler@gmx.de> wrote:
> Think about header files that are published as part of an SDK interface,
> in anticipation that 3rd party programmers are going to derive from it.
> With this proposal, it would be possible for the interface author to
> specify that "baz = &bar", and if a user does not wish to override baz, he
> gets the reasonable default behavior (i.e. a call to baz will call his
> *overridden* version of bar) with out the penalty of a double dispatch.
Only if they have the exact same calling signatures. That makes it of very
limited use.
Combined with two reasonable behaviors, neither of which is obvious from
the syntax, IMHO this feature isn't worth the cost in added complexity to
the language. -1.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b2e5290f3999a04e1a84dea
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 16 July 2013 16:57, <span dir=3D"ltr"><<a href=3D"mailto:cschueler@g=
mx.de" target=3D"_blank">cschueler@gmx.de</a>></span> wrote:<br><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex">
Think=A0about header files that are published as part of an SDK interface, =
in anticipation that 3rd party programmers are going to derive from it. Wit=
h this proposal, it would be possible for the interface author to specify=
=A0that "baz =3D &bar", and if a user does not wish to overri=
de baz, he gets the reasonable default behavior (i.e. a call to baz will ca=
ll his *overridden* version of bar) with out the penalty of a double dispat=
ch. </blockquote>
<div><br>Only if they have the exact same calling signatures.=A0 That makes=
it of very limited use.<br><br>Combined with two reasonable behaviors, nei=
ther of which is obvious from the syntax, IMHO this feature isn't worth=
the cost in added complexity to the language.=A0 -1.<br>
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 (847) 691-1404
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
<br />
<br />
--047d7b2e5290f3999a04e1a84dea--
.
Author: Jeffrey Yasskin <jyasskin@google.com>
Date: Tue, 16 Jul 2013 15:16:31 -0700
Raw View
On Tue, Jul 16, 2013 at 3:14 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 16 July 2013 16:57, <cschueler@gmx.de> wrote:
>>
>> Think about header files that are published as part of an SDK interface,
>> in anticipation that 3rd party programmers are going to derive from it. With
>> this proposal, it would be possible for the interface author to specify that
>> "baz = &bar", and if a user does not wish to override baz, he gets the
>> reasonable default behavior (i.e. a call to baz will call his *overridden*
>> version of bar) with out the penalty of a double dispatch.
>
>
> Only if they have the exact same calling signatures. That makes it of very
> limited use.
>
> Combined with two reasonable behaviors, neither of which is obvious from the
> syntax, IMHO this feature isn't worth the cost in added complexity to the
> language. -1.
I agree. -1 to the feature.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.