Topic: Virtual Parameters
Author: andrewtomazos@gmail.com
Date: Sat, 24 Aug 2013 12:23:55 -0700 (PDT)
Raw View
------=_Part_7_3027460.1377372235036
Content-Type: text/plain; charset=ISO-8859-1
The proposed feature, Virtual Parameters, suggests adding a new `virtual`
specifier to parameter declarations:
void f(virtual T);
that alters overload resolution.
Once the set of candidate functions is identified, and before viability is
considered, each virtual parameter in the ith position of a candidate
function causes the ith argument in the function call (if it exists) to be
considered a virtual argument.
If a virtual argument of the function call is a glvalue of polymorphic
class type, it shall be replaced by a glvalue refering to the most derived
object.
If a virtual argument of the function call is a pointer to a polymorphic
class type, it shall be converted to a pointer to the most derived object.
Otherwise, it shall have no effect, treated the same as a non-virtual
argument.
Overload resolution then continues with viability as normal.
Example use case, double dynamic dispatch:
struct B { virtual ~B() = default; }
struct D1 : B {}
struct D2 : B {}
void f(virtual B&, virtual B&) = delete;
void f(D1&, D1&) {}
void f(D1&, D2&) {}
void f(D2&, D1&) {}
void f(D2&, D2&) {}
void g(B& x, B& y)
{
f(x,y);
}
int main()
{
D1 d1;
D2 d2;
g(d1,d2); // calls g(B&, B&) that then calls f(D1&, D2&)
}
As an extension to the idea, it may be possible to call functions not
visible in the current TU at point of call and involving types not defined
in the current TU, but linked from other TUs in the final program.
Implementation would be similar to virtual member functions.
Enjoy,
Andrew.
--
---
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_7_3027460.1377372235036
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The proposed feature, Virtual Parameters, suggests adding =
a new `virtual` specifier to parameter declarations:<br><br><span style=3D"=
font-family: courier new,monospace;"> void f(virtual T);<=
br></span><br>that alters overload resolution.<br><br>Once the set of candi=
date functions is identified, and before viability is considered, each virt=
ual parameter in the ith position of a candidate function causes the ith ar=
gument in the function call (if it exists) to be considered a virtual argum=
ent.<br><br>If a virtual argument of the function call is a glvalue of poly=
morphic class type, it shall be replaced by a glvalue refering to the most =
derived object.<br><br>If a virtual argument of the function call is a poin=
ter to a polymorphic class type, it shall be converted to a pointer to the =
most derived object.<br><br>Otherwise, it shall have no effect, treated the=
same as a non-virtual argument.<br><br>Overload resolution then continues =
with viability as normal.<br><br>Example use case, double dynamic dispatch:=
<br><br><span style=3D"font-family: courier new,monospace;"> &nb=
sp; struct B { virtual ~B() =3D default; }<br> struct D1 =
: B {}<br> struct D2 : B {}<br><br> voi=
d f(virtual B&, virtual B&) =3D delete;<br> void =
f(D1&, D1&) {}<br> void f(D1&, D2&) {}<br=
> void f(D2&, D1&) {}<br> void =
f(D2&, D2&) {}<br><br> void g(B& x, B& y)=
<br> {<br> f(x,y);<br> =
}<br><br> int main()<br> {<br> &nbs=
p; D1 d1;<br> D2 d2;<br><br> =
g(d1,d2); // calls g(B&, B&) that then calls f(D1&am=
p;, D2&)<br> }<br></span><br>As an extension to the idea, =
it may be possible to call functions not visible in the current TU at point=
of call and involving types not defined in the current TU, but linked from=
other TUs in the final program.<br><br>Implementation would be similar to =
virtual member functions.<br><br>Enjoy,<br>Andrew.<br><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 />
------=_Part_7_3027460.1377372235036--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 24 Aug 2013 22:28:02 +0300
Raw View
--047d7b33d37491417304e4b6850f
Content-Type: text/plain; charset=ISO-8859-1
On 24 August 2013 22:23, <andrewtomazos@gmail.com> wrote:
> The proposed feature, Virtual Parameters, suggests adding a new `virtual`
> specifier to parameter declarations:
>
Please read http://www.stroustrup.com/multimethods.pdf
I believe the problem with multimethods is that having them seemingly
requires linker modifications.
--
---
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/.
--047d7b33d37491417304e4b6850f
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 24 August 2013 22:23, <span dir=3D"ltr"><<a href=3D"mailto:a=
ndrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@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">The prop=
osed feature, Virtual Parameters, suggests adding a new `virtual` specifier=
to parameter declarations:<br>
</div></blockquote><div><br></div><div>Please read <a href=3D"http://www.st=
roustrup.com/multimethods.pdf">http://www.stroustrup.com/multimethods.pdf</=
a><br><br></div><div>I believe the problem with multimethods is that having=
them seemingly requires linker modifications.<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 />
--047d7b33d37491417304e4b6850f--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 24 Aug 2013 18:09:14 -0700 (PDT)
Raw View
------=_Part_406_27059298.1377392954867
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, August 24, 2013 12:23:55 PM UTC-7, andrew...@gmail.com wrote:
>
> The proposed feature, Virtual Parameters, suggests adding a new `virtual`
> specifier to parameter declarations:
>
> void f(virtual T);
>
> that alters overload resolution.
>
> Once the set of candidate functions is identified, and before viability is
> considered, each virtual parameter in the ith position of a candidate
> function causes the ith argument in the function call (if it exists) to be
> considered a virtual argument.
>
> If a virtual argument of the function call is a glvalue of polymorphic
> class type, it shall be replaced by a glvalue refering to the most derived
> object.
>
> If a virtual argument of the function call is a pointer to a polymorphic
> class type, it shall be converted to a pointer to the most derived object.
>
> Otherwise, it shall have no effect, treated the same as a non-virtual
> argument.
>
> Overload resolution then continues with viability as normal.
>
> Example use case, double dynamic dispatch:
>
> struct B { virtual ~B() = default; }
> struct D1 : B {}
> struct D2 : B {}
>
> void f(virtual B&, virtual B&) = delete;
> void f(D1&, D1&) {}
> void f(D1&, D2&) {}
> void f(D2&, D1&) {}
> void f(D2&, D2&) {}
>
> void g(B& x, B& y)
> {
> f(x,y);
> }
>
> int main()
> {
> D1 d1;
> D2 d2;
>
> g(d1,d2); // calls g(B&, B&) that then calls f(D1&, D2&)
> }
>
> As an extension to the idea, it may be possible to call functions not
> visible in the current TU at point of call and involving types not defined
> in the current TU, but linked from other TUs in the final program.
>
> Implementation would be similar to virtual member functions.
>
That would require *runtime function dispatch*. That's rather different
from a regular old polymorphic call; implementations for that can just pick
an entry from a vtable to get the right function. What you're talking about
is a hell of a lot more complicated, requiring the compile-time generation
of lots of runtime code. That little `f(x, y)` call will balloon out into
what is effectively a runtime system for doing overload resolution.
That's going to be a nightmare to implement.
Also, how do you determine the "most derived type"? Don't you mean the
actual polymorphic type of the object?
--
---
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_406_27059298.1377392954867
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, August 24, 2013 12:23:55 PM UTC-7, andrew...@=
gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">The proposed feature, Virtual Parameters, suggests adding a new `virtual=
` specifier to parameter declarations:<br><br><span style=3D"font-family:co=
urier new,monospace"> void f(virtual T);<br></span><br>th=
at alters overload resolution.<br><br>Once the set of candidate functions i=
s identified, and before viability is considered, each virtual parameter in=
the ith position of a candidate function causes the ith argument in the fu=
nction call (if it exists) to be considered a virtual argument.<br><br>If a=
virtual argument of the function call is a glvalue of polymorphic class ty=
pe, it shall be replaced by a glvalue refering to the most derived object.<=
br><br>If a virtual argument of the function call is a pointer to a polymor=
phic class type, it shall be converted to a pointer to the most derived obj=
ect.<br><br>Otherwise, it shall have no effect, treated the same as a non-v=
irtual argument.<br><br>Overload resolution then continues with viability a=
s normal.<br><br>Example use case, double dynamic dispatch:<br><br><span st=
yle=3D"font-family:courier new,monospace"> struct B { vir=
tual ~B() =3D default; }<br> struct D1 : B {}<br> &n=
bsp; struct D2 : B {}<br><br> void f(virtual B&=
, virtual B&) =3D delete;<br> void f(D1&, D1&=
) {}<br> void f(D1&, D2&) {}<br>  =
; void f(D2&, D1&) {}<br> void f(D2&, D2&=
) {}<br><br> void g(B& x, B& y)<br> =
{<br> f(x,y);<br> }<br><br> &=
nbsp; int main()<br> {<br> D1 d1;<b=
r> D2 d2;<br><br> g(d=
1,d2); // calls g(B&, B&) that then calls f(D1&, D2&)<br>&n=
bsp; }<br></span><br>As an extension to the idea, it may be possible=
to call functions not visible in the current TU at point of call and invol=
ving types not defined in the current TU, but linked from other TUs in the =
final program.<br><br>Implementation would be similar to virtual member fun=
ctions.<br></div></blockquote><div><br>That would require <i>runtime functi=
on dispatch</i>. That's rather different from a regular old polymorphic cal=
l; implementations for that can just pick an entry from a vtable to get the=
right function. What you're talking about is a hell of a lot more complica=
ted, requiring the compile-time generation of lots of runtime code. That li=
ttle `f(x, y)` call will balloon out into what is effectively a runtime sys=
tem for doing overload resolution.<br><br>That's going to be a nightmare to=
implement.<br><br>Also, how do you determine the "most derived type"? Don'=
t you mean the actual polymorphic type of the object?<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 />
------=_Part_406_27059298.1377392954867--
.
Author: Jeffrey Yasskin <jyasskin@google.com>
Date: Sat, 24 Aug 2013 19:59:40 -0700
Raw View
On Sat, Aug 24, 2013 at 12:23 PM, <andrewtomazos@gmail.com> wrote:
> Implementation would be similar to virtual member functions.
That's too handwavy for this feature. You'd need to show an actual
implementation that people can poke at.
--
---
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: andrewtomazos@gmail.com
Date: Sun, 25 Aug 2013 17:34:34 -0700 (PDT)
Raw View
------=_Part_1682_26868027.1377477274563
Content-Type: text/plain; charset=ISO-8859-1
With the extension vaguely eluded to at the end of my message, it would
require linker modifications - however if only the usual visible candidate
functions were considered, then it could be done within the TU.
Specifically, instead of a normal function call, the compiler could
implicitly generate a dispatching function during translation by analyzing
the visible candidate function set alongside the currently known
polymorphic parameter types that could effect the dispatch to those
functions. Logically similar to:
// for the OP example:
static void dispatch_f(B& x_in, B& y_in)
{
B *px = &x_in, *py = &y_in;
if (auto x = dynamic_cast<D1*>(px))
{
if (auto y = dynamic_cast<D1*>(py))
f(*x, *y);
else if (auto y = dynamic_cast<D2*>(py))
f(*x, *y);
}
else if (auto x = dynamic_cast<D2*>(px))
{
if (auto y = dynamic_cast<D1*>(py))
f(*x, *y);
else if (auto y = dynamic_cast<D2*>(py))
f(*x, *y);
}
}
Obviously the compiler could do a lot better than this by generating a jump
table directly switching on the argument type id to the right visible
candidate function, and it could be shared by function calls with identical
candidate function sets, etc The point is that it is generatable using
information available during translation, and it is relatively
straightforward to implement. Even if it doesn't allow for link-time
expansion of the candidate function set, I still think it would be more
useful than the current workarounds to do multiple dynamic dispatch.
-Andrew.
On Saturday, August 24, 2013 9:28:02 PM UTC+2, Ville Voutilainen wrote:
>
>
>
>
> On 24 August 2013 22:23, <andrew...@gmail.com <javascript:>> wrote:
>
>> The proposed feature, Virtual Parameters, suggests adding a new `virtual`
>> specifier to parameter declarations:
>>
>
> Please read http://www.stroustrup.com/multimethods.pdf
>
> I believe the problem with multimethods is that having them seemingly
> requires linker modifications.
>
--
---
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_1682_26868027.1377477274563
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>With the extension vaguely eluded to at the end of my =
message, it would require linker modifications - however if only the usual =
visible candidate functions were considered, then it could be done within t=
he TU.<br><br>Specifically, instead of a normal function call, the compiler=
could implicitly generate a dispatching function during translation by ana=
lyzing the visible candidate function set alongside the currently known pol=
ymorphic parameter types that could effect the dispatch to those functions.=
Logically similar to:<br><br> // for the OP exampl=
e:<br><br> static void dispatch_f(B& x_in, B& y_i=
n)<br> {<br> B =
*px =3D &x_in, *py =3D &y_in;<br><br> =
if (auto x =3D dynamic_cast<D1*>(px))<br> &nb=
sp; {<br> =
if (auto y =3D dynamic_cast<D1*>(py))<br>&nb=
sp; =
f(*x, *y);<br> =
else if (auto y =3D dynamic_cast<D2*>(py))<br>&nbs=
p; &=
nbsp; f(*x, *y);<br> }<br>&=
nbsp; else if (auto x =3D dynamic_cast&=
lt;D2*>(px))<br> {<br> &n=
bsp; if (auto y=
=3D dynamic_cast<D1*>(py))<br> &n=
bsp; f(*x, *y);<br>&n=
bsp; else=
if (auto y =3D dynamic_cast<D2*>(py))<br> &nb=
sp; f(*x,=
*y);<br> }<br> =
}<br><br>Obviously the compiler could do a lot better than this by generat=
ing a jump table directly switching on the argument type id to the right vi=
sible candidate function, and it could be shared by function calls with ide=
ntical candidate function sets, etc The point is that it is generatab=
le using information available during translation, and it is relatively str=
aightforward to implement. Even if it doesn't allow for link-time exp=
ansion of the candidate function set, I still think it would be more useful=
than the current workarounds to do multiple dynamic dispatch.<br> -A=
ndrew.<br><br><br><br>On Saturday, August 24, 2013 9:28:02 PM UTC+2, Ville =
Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-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 24 August 2013 22:23, =
<span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"L5ZJ3uFdouMJ">andrew...@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">The prop=
osed feature, Virtual Parameters, suggests adding a new `virtual` specifier=
to parameter declarations:<br>
</div></blockquote><div><br></div><div>Please read <a href=3D"http://www.st=
roustrup.com/multimethods.pdf" target=3D"_blank">http://www.stroustrup.com/=
<wbr>multimethods.pdf</a><br><br></div><div>I believe the problem with mult=
imethods is that having them seemingly requires linker modifications.<br>
</div></div></div></div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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 />
------=_Part_1682_26868027.1377477274563--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 25 Aug 2013 17:53:48 -0700 (PDT)
Raw View
What about DLLs? Most implementations allow combining TUs at load time, on =
the client machine.
Anything is possible but this would require significant vendor effort. A re=
ference implementation, perhaps a compliant library based on static initial=
izers, might help convince folks. Such initialization can be prioritized wh=
en the library is adopted into the implementation proper, to avoid the init=
ialization order fiasco, if it's unavoidable.
--=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: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 25 Aug 2013 20:39:08 -0700 (PDT)
Raw View
------=_Part_160_19761041.1377488348443
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, August 25, 2013 5:34:34 PM UTC-7, andrew...@gmail.com wrote:
>
>
> With the extension vaguely eluded to at the end of my message, it would
> require linker modifications - however if only the usual visible candidate
> functions were considered, then it could be done within the TU.
>
> Specifically, instead of a normal function call, the compiler could
> implicitly generate a dispatching function during translation by analyzing
> the visible candidate function set alongside the currently known
> polymorphic parameter types that could effect the dispatch to those
> functions.
>
The whole point of virtual functions and runtime polymorphism is that you
can extend them *without* the calling code knowing anything about your
extensions. You can compile a static (or even dynamic) library, and I can
derive classes and override virtual functions, and your code automatically
calls mine.
If all you're doing is local analysis for these "virtual" functions, then
it's not really runtime polymorphism, is it? It's really just a static
overload system with some slight runtime character. This could only ever be
used in very narrow contexts that are 95% static, but you need just a
little dynamic character. What would your code do if someone passed in a
class type that it isn't statically aware of? Because that's an entirely
legitimate possibility. It is, after all, the *whole point* of runtime
polymorphism: interacting with types that you aren't statically aware of.
If you're going to have proper multi-methods in the language, if you're
going to have compiler devs take the time to implement multimethod
dispatch, then you need to do it *right*. Full runtime polymorphism, with
complete freedom of adding new types, adding new overloads, and everything.
This half-version is just too limited to bother implementing as a language
feature. It's something you may as well do on your own.
--
---
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_160_19761041.1377488348443
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, August 25, 2013 5:34:34 PM UTC-7, andre=
w...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br>With the extension vaguely eluded to at the end of my message,=
it would require linker modifications - however if only the usual visible =
candidate functions were considered, then it could be done within the TU.<b=
r><br>Specifically, instead of a normal function call, the compiler could i=
mplicitly generate a dispatching function during translation by analyzing t=
he visible candidate function set alongside the currently known polymorphic=
parameter types that could effect the dispatch to those functions.</div></=
blockquote><div><br>The whole point of virtual functions and runtime polymo=
rphism is that you can extend them <i>without</i> the calling code knowing =
anything about your extensions. You can compile a static (or even dynamic) =
library, and I can derive classes and override virtual functions, and your =
code automatically calls mine.<br><br>If all you're doing is local analysis=
for these "virtual" functions, then it's not really runtime polymorphism, =
is it? It's really just a static overload system with some slight runtime c=
haracter. This could only ever be used in very narrow contexts that are 95%=
static, but you need just a little dynamic character. What would your code=
do if someone passed in a class type that it isn't statically aware of? Be=
cause that's an entirely legitimate possibility. It is, after all, the <i>w=
hole point</i> of runtime polymorphism: interacting with types that you are=
n't statically aware of.<br><br>If you're going to have proper multi-method=
s in the language, if you're going to have compiler devs take the time to i=
mplement multimethod dispatch, then you need to do it <i>right</i>. Full ru=
ntime polymorphism, with complete freedom of adding new types, adding new o=
verloads, and everything.<br><br>This half-version is just too limited to b=
other implementing as a language feature. It's something you may as well do=
on your own.</div><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 />
------=_Part_160_19761041.1377488348443--
.
Author: andrewtomazos@gmail.com
Date: Mon, 26 Aug 2013 07:07:28 -0700 (PDT)
Raw View
------=_Part_1980_19951805.1377526048718
Content-Type: text/plain; charset=ISO-8859-1
> What would your code do if someone passed in a class type that it isn't
statically aware of?
The best match of the candidate set is still selected correctly even if
called with types not defined in the current TU, in much the same way that
`dynamic_cast<T&>` still works even on objects of as-yet undefined
subclasses of T. So you can expand the argument types from outside the TU,
just not the candidate function set.
> The whole point of virtual functions and runtime polymorphism is that you
can extend them *without* the calling code knowing anything about...
It seems by your definition that when foo is `#included` it counts as
"knowing about", whereas when foo is statically linked it doesn't count as
"knowing about", and when foo is dynamically loaded at runtime it doesn't
count as "knowing about". Let us highlight that that this line is more or
less arbitrary, and I wouldn't dare define the "whole point" of "runtime
polymorphism" dependant upon it.
I can also turn your argument around: How can I add a new set of virtual
member functions to an existing type hierarchy without the types "knowing
about" the new functions? With the unextended virtual parameters feature I
can. So shall I argue that virtual member functions were not worth doing,
because they were not done "right".
To take a specific example, suppose I have a `vector<B*>` where `B` is a
polymorphic base class. I now want to iterate over the vector and execute
some code of each element that varies depending on which subclass each
element is. Currently I can add a virtual member function to B, spreading
the code over many different class definitions (causing them to "know
about"), or I can implement an ugly inefficient `dynamic_cast` if-else
switch to do the dispatch, or I can implement some generic bulky visitor
pattern machinery. With virtual parameters it would be simple and obvious,
and this is still only talking about single dispatch. Take a look at the
Pattern Matching (nothing to do with regex) feature in Scala for some
context.
-Andrew.
On Monday, August 26, 2013 5:39:08 AM UTC+2, Nicol Bolas wrote:
>
>
>
> On Sunday, August 25, 2013 5:34:34 PM UTC-7, andrew...@gmail.com wrote:
>>
>>
>> With the extension vaguely eluded to at the end of my message, it would
>> require linker modifications - however if only the usual visible candidate
>> functions were considered, then it could be done within the TU.
>>
>> Specifically, instead of a normal function call, the compiler could
>> implicitly generate a dispatching function during translation by analyzing
>> the visible candidate function set alongside the currently known
>> polymorphic parameter types that could effect the dispatch to those
>> functions.
>>
>
> The whole point of virtual functions and runtime polymorphism is that you
> can extend them *without* the calling code knowing anything about your
> extensions. You can compile a static (or even dynamic) library, and I can
> derive classes and override virtual functions, and your code automatically
> calls mine.
>
> If all you're doing is local analysis for these "virtual" functions, then
> it's not really runtime polymorphism, is it? It's really just a static
> overload system with some slight runtime character. This could only ever be
> used in very narrow contexts that are 95% static, but you need just a
> little dynamic character. What would your code do if someone passed in a
> class type that it isn't statically aware of? Because that's an entirely
> legitimate possibility. It is, after all, the *whole point* of runtime
> polymorphism: interacting with types that you aren't statically aware of.
>
> If you're going to have proper multi-methods in the language, if you're
> going to have compiler devs take the time to implement multimethod
> dispatch, then you need to do it *right*. Full runtime polymorphism, with
> complete freedom of adding new types, adding new overloads, and everything.
>
> This half-version is just too limited to bother implementing as a language
> feature. It's something you may as well do on your own.
>
>
--
---
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_1980_19951805.1377526048718
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-family:courier new,monospace">> </s=
pan><span style=3D"font-family:courier new,monospace">What would your code =
do if someone passed in a class type that it isn't statically aware of?<br>=
</span><br>The best match of the candidate set is still selected correctly =
even if called with types not defined in the current TU, in much the same w=
ay that `dynamic_cast<T&>` still works even on objects of as-yet =
undefined subclasses of T. So you can expand the argument types from =
outside the TU, just not the candidate function set.<br><br>> The whole =
point of virtual functions and runtime polymorphism is that you can extend =
them <i>without</i> the calling code knowing anything about...<br><br>It se=
ems by your definition that when foo is `#included` it counts as "knowing a=
bout", whereas when foo is statically linked it doesn't count as "knowing a=
bout", and when foo is dynamically loaded at runtime it doesn't count as "k=
nowing about". Let us highlight that that this line is more or less a=
rbitrary, and I wouldn't dare define the "whole point" of "runtime polymorp=
hism" dependant upon it.<br><br>I can also turn your argument around: =
How can I add a new set of virtual member functions to an existing type hi=
erarchy without the types "knowing about" the new functions? With the=
unextended virtual parameters feature I can. So shall I argue that v=
irtual member functions were not worth doing, because they were not done "r=
ight".<br><br>To take a specific example, suppose I have a `vector<B*>=
;` where `B` is a polymorphic base class. I now want to iterate over =
the vector and execute some code of each element that varies depending on w=
hich subclass each element is. Currently I can add a virtual member f=
unction to B, spreading the code over many different class definitions (cau=
sing them to "know about"), or I can implement an ugly inefficient `dynamic=
_cast` if-else switch to do the dispatch, or I can implement some generic b=
ulky visitor pattern machinery. With virtual parameters it would be s=
imple and obvious, and this is still only talking about single dispatch.&nb=
sp; Take a look at the Pattern Matching (nothing to do with regex) feature =
in Scala for some context.<br> -Andrew.<br><br>On Monday, August 26, =
2013 5:39:08 AM UTC+2, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><br><br>On Sunday, August 25, 2013 5:34:34 PM U=
TC-7, <a>andrew...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><br>With the extension vaguely eluded to at the end of=
my message, it would require linker modifications - however if only the us=
ual visible candidate functions were considered, then it could be done with=
in the TU.<br><br>Specifically, instead of a normal function call, the comp=
iler could implicitly generate a dispatching function during translation by=
analyzing the visible candidate function set alongside the currently known=
polymorphic parameter types that could effect the dispatch to those functi=
ons.</div></blockquote><div><br>The whole point of virtual functions and ru=
ntime polymorphism is that you can extend them <i>without</i> the calling c=
ode knowing anything about your extensions. You can compile a static (or ev=
en dynamic) library, and I can derive classes and override virtual function=
s, and your code automatically calls mine.<br><br>If all you're doing is lo=
cal analysis for these "virtual" functions, then it's not really runtime po=
lymorphism, is it? It's really just a static overload system with some slig=
ht runtime character. This could only ever be used in very narrow contexts =
that are 95% static, but you need just a little dynamic character. What wou=
ld your code do if someone passed in a class type that it isn't statically =
aware of? Because that's an entirely legitimate possibility. It is, after a=
ll, the <i>whole point</i> of runtime polymorphism: interacting with types =
that you aren't statically aware of.<br><br>If you're going to have proper =
multi-methods in the language, if you're going to have compiler devs take t=
he time to implement multimethod dispatch, then you need to do it <i>right<=
/i>. Full runtime polymorphism, with complete freedom of adding new types, =
adding new overloads, and everything.<br><br>This half-version is just too =
limited to bother implementing as a language feature. It's something you ma=
y as well do on your own.</div><br></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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 />
------=_Part_1980_19951805.1377526048718--
.
Author: cornedbee@google.com
Date: Mon, 26 Aug 2013 08:16:50 -0700 (PDT)
Raw View
------=_Part_61_30268785.1377530210908
Content-Type: text/plain; charset=ISO-8859-1
On Monday, August 26, 2013 4:07:28 PM UTC+2, andrew...@gmail.com wrote:
>
> > What would your code do if someone passed in a class type that it isn't
> statically aware of?
>
> The best match of the candidate set is still selected correctly even if
> called with types not defined in the current TU, in much the same way that
> `dynamic_cast<T&>` still works even on objects of as-yet undefined
> subclasses of T. So you can expand the argument types from outside the TU,
> just not the candidate function set.
>
> So a new type from outside comes in and you select the =delete overload.
What does that mean at runtime?
--
---
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_61_30268785.1377530210908
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, August 26, 2013 4:07:28 PM UTC+2, andre=
w...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><span style=3D"font-family:courier new,monospace">> </span><spa=
n style=3D"font-family:courier new,monospace">What would your code do if so=
meone passed in a class type that it isn't statically aware of?<br></span><=
br>The best match of the candidate set is still selected correctly even if =
called with types not defined in the current TU, in much the same way that =
`dynamic_cast<T&>` still works even on objects of as-yet undefine=
d subclasses of T. So you can expand the argument types from outside =
the TU, just not the candidate function set.<br><br></div></blockquote><div=
>So a new type from outside comes in and you select the =3Ddelete overload.=
What does that mean at runtime? </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 />
------=_Part_61_30268785.1377530210908--
.
Author: andrewtomazos@gmail.com
Date: Mon, 26 Aug 2013 10:16:47 -0700 (PDT)
Raw View
------=_Part_187_25069623.1377537407646
Content-Type: text/plain; charset=ISO-8859-1
On Monday, August 26, 2013 5:16:50 PM UTC+2, corn...@google.com wrote:
> So a new type from outside comes in and you select the =delete overload.
What does that mean at runtime?
If it can be determined during translation that there can never be a
(non-deleted) best match based on the static types of the arguments
compared to the static candidate parameters, then the program is ill-formed
(as is the case now for non-virtual parameters).
If it is determined during run-time dispatch that there is no non-deleted
best match, it could throw an exception such as a `std::bad_cast` - same as
`dynamic_cast`.
Alternatively. you could also give the `=delete` overload a body instead
that handles such cases however you want. The "base function" doesn't need
to be deleted, nor in fact does there need to be a "base function" at all -
there just happens to be one in the example.
-Andrew.
On Monday, August 26, 2013 4:07:28 PM UTC+2, andrew...@gmail.com wrote:
>>
>> > What would your code do if someone passed in a class type that it
>> isn't statically aware of?
>>
>> The best match of the candidate set is still selected correctly even if
>> called with types not defined in the current TU, in much the same way that
>> `dynamic_cast<T&>` still works even on objects of as-yet undefined
>> subclasses of T. So you can expand the argument types from outside the TU,
>> just not the candidate function set.
>>
>
--
---
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_187_25069623.1377537407646
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, August 26, 2013 5:16:50 PM UTC+2, corn...@googl=
e.com wrote:<br>> So a new type from outside comes in and you select the=
=3Ddelete overload. What does that mean at runtime? <br><div><br>If it can=
be determined during translation that there can never be a (non-deleted) b=
est match based on the static types of the arguments compared to the static=
candidate parameters, then the program is ill-formed (as is the case now f=
or non-virtual parameters).<br><br>If it is determined during run-time disp=
atch that there is no non-deleted best match, it could throw an exception s=
uch as a `std::bad_cast` - same as `dynamic_cast`.<br><br>Alternatively. yo=
u could also give the `=3Ddelete` overload a body instead that handles such=
cases however you want. The "base function" doesn't need to be delet=
ed, nor in fact does there need to be a "base function" at all - there just=
happens to be one in the example.<br> -Andrew.<br></div><br><b=
r><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Monday, =
August 26, 2013 4:07:28 PM UTC+2, <a>andrew...@gmail.com</a> wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span style=3D"font-family=
:courier new,monospace">> </span><span style=3D"font-family:courier new,=
monospace">What would your code do if someone passed in a class type that i=
t isn't statically aware of?<br></span><br>The best match of the candidate =
set is still selected correctly even if called with types not defined in th=
e current TU, in much the same way that `dynamic_cast<T&>` still =
works even on objects of as-yet undefined subclasses of T. So you can=
expand the argument types from outside the TU, just not the candidate func=
tion set.</div></blockquote></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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 />
------=_Part_187_25069623.1377537407646--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 26 Aug 2013 16:19:31 -0700 (PDT)
Raw View
------=_Part_1_13105407.1377559171778
Content-Type: text/plain; charset=ISO-8859-1
On Monday, August 26, 2013 7:07:28 AM UTC-7, andrew...@gmail.com wrote:
>
> > What would your code do if someone passed in a class type that it isn't
> statically aware of?
>
> The best match of the candidate set is still selected correctly even if
> called with types not defined in the current TU, in much the same way that
> `dynamic_cast<T&>` still works even on objects of as-yet undefined
> subclasses of T. So you can expand the argument types from outside the TU,
> just not the candidate function set.
>
But dynamic_cast is not being asked to convert pointers/references to types
that are not statically visible to the compiler. By definition, if it can
go in the argument of `dynamic_cast`, then the type must be statically
visible in the translation unit.
> The whole point of virtual functions and runtime polymorphism is that you
> can extend them *without* the calling code knowing anything about...
>
> It seems by your definition that when foo is `#included` it counts as
> "knowing about", whereas when foo is statically linked it doesn't count as
> "knowing about", and when foo is dynamically loaded at runtime it doesn't
> count as "knowing about". Let us highlight that that this line is more or
> less arbitrary, and I wouldn't dare define the "whole point" of "runtime
> polymorphism" dependant upon it.
>
This line is not arbitrary; it's defined by the standard compiler/linker
distinction common to pretty much *every* C++ compiler. It's even defined
by the C++ standard, with the concept of "translation unit".
> I can also turn your argument around: How can I add a new set of virtual
> member functions to an existing type hierarchy without the types "knowing
> about" the new functions? With the unextended virtual parameters feature I
> can. So shall I argue that virtual member functions were not worth doing,
> because they were not done "right".
>
Yes, there are higher levels of dynamic, type-based function dispatching
possible beyond virtual member functions.
But there's a big difference between what you said and what I said. What
you suggested is static and cannot be extended to types beyond the
translation unit in which the dispatching call resides. Virtual member
functions don't work that way. So while virtual member function dispatch
may be a lower form of dynamic, type-based dispatching, it is still a full
and complete feature because it can be dynamically extended from anywhere.
What you've suggested cannot. It's static, bound to only the types visible
from the translation unit. That's what makes it incomplete: it's dynamic,
but only to a point, rather than being fully dynamic across the entire
program.
--
---
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_1_13105407.1377559171778
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, August 26, 2013 7:07:28 AM UTC-7, andrew...@gma=
il.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<span style=3D"font-family:courier new,monospace">> </span><span style=
=3D"font-family:courier new,monospace">What would your code do if someone p=
assed in a class type that it isn't statically aware of?<br></span><br>The =
best match of the candidate set is still selected correctly even if called =
with types not defined in the current TU, in much the same way that `dynami=
c_cast<T&>` still works even on objects of as-yet undefined subcl=
asses of T. So you can expand the argument types from outside the TU,=
just not the candidate function set.<br></div></blockquote><div><br>But dy=
namic_cast is not being asked to convert pointers/references to types that =
are not statically visible to the compiler. By definition, if it can go in =
the argument of `dynamic_cast`, then the type must be statically visible in=
the translation unit.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr">> The whole point of virtual functions and runtim=
e polymorphism is that you can extend them <i>without</i> the calling code =
knowing anything about...<br><br>It seems by your definition that when foo =
is `#included` it counts as "knowing about", whereas when foo is statically=
linked it doesn't count as "knowing about", and when foo is dynamically lo=
aded at runtime it doesn't count as "knowing about". Let us highlight=
that that this line is more or less arbitrary, and I wouldn't dare define =
the "whole point" of "runtime polymorphism" dependant upon it.<br></div></b=
lockquote><div><br>This line is not arbitrary; it's defined by the standard=
compiler/linker distinction common to pretty much <i>every</i> C++ compile=
r. It's even defined by the C++ standard, with the concept of "translation =
unit".<br> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">I can also turn your argument around: How can I add a new se=
t of virtual member functions to an existing type hierarchy without the typ=
es "knowing about" the new functions? With the unextended virtual par=
ameters feature I can. So shall I argue that virtual member functions=
were not worth doing, because they were not done "right".<br></div></block=
quote><div><br>Yes, there are higher levels of dynamic, type-based function=
dispatching possible beyond virtual member functions.<br><br>But there's a=
big difference between what you said and what I said. What you suggested i=
s static and cannot be extended to types beyond the translation unit in whi=
ch the dispatching call resides. Virtual member functions don't work that w=
ay. So while virtual member function dispatch may be a lower form of dynami=
c, type-based dispatching, it is still a full and complete feature because =
it can be dynamically extended from anywhere.<br><br>What you've suggested =
cannot. It's static, bound to only the types visible from the translation u=
nit. That's what makes it incomplete: it's dynamic, but only to a point, ra=
ther than being fully dynamic across the entire program.</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 />
------=_Part_1_13105407.1377559171778--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Mon, 26 Aug 2013 19:31:25 -0400
Raw View
On Sun, Aug 25, 2013 at 8:34 PM, <andrewtomazos@gmail.com> wrote:
> static void dispatch_f(B& x_in, B& y_in)
> {
> B *px = &x_in, *py = &y_in;
>
> if (auto x = dynamic_cast<D1*>(px))
> {
> if (auto y = dynamic_cast<D1*>(py))
> f(*x, *y);
> else if (auto y = dynamic_cast<D2*>(py))
> f(*x, *y);
> }
> else if (auto x = dynamic_cast<D2*>(px))
> {
> if (auto y = dynamic_cast<D1*>(py))
> f(*x, *y);
> else if (auto y = dynamic_cast<D2*>(py))
> f(*x, *y);
> }
> }
Gosh...
Anyway, I think there is one thing possible and efficient thing
we can do: allow single parameter-only multimethod. Like
what Python3 does recently:
http://www.python.org/dev/peps/pep-0443/
It's also useful, and fairly easy to implement based on
the current vtbl implementations.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
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: andrewtomazos@gmail.com
Date: Mon, 26 Aug 2013 16:47:58 -0700 (PDT)
Raw View
------=_Part_2164_15112373.1377560879007
Content-Type: text/plain; charset=ISO-8859-1
> But dynamic_cast is not being asked to convert pointers/references to
types that are not statically visible to the compiler. By definition, if it
can go in the argument of `dynamic_cast`, then the type must be statically
visible in the translation unit.
What you are missing is that the requirements can be implemented as-if a
virtual argument had been converted to the most derived type (even if that
type is not defined in the current TU), because it only needs enough type
information to determine and dispatch to the best match candidate function
- therefore it only needs to "dynamic_cast" the argument to the parameter
types of those candidate functions, and those parameter types are defined
in the current TU, even if the dynamic argument type isn't
-Andrew.
--
---
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_2164_15112373.1377560879007
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>> But dynamic_cast is not being asked to convert po=
inters/references to=20
types that are not statically visible to the compiler. By definition, if
it can go in the argument of `dynamic_cast`, then the type must be=20
statically visible in the translation unit.<br><br>What you are missing is =
that the requirements can be implemented as-if a virtual argument had been =
converted to the most derived type (even if that type is not defined in the=
current TU), because it only needs enough type information to determine an=
d dispatch to the best match candidate function - therefore it only needs t=
o "dynamic_cast" the argument to the parameter types of those candidate fun=
ctions, and those parameter types are defined in the current TU, even if th=
e dynamic argument type isn't<br> -Andrew.<br><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 />
------=_Part_2164_15112373.1377560879007--
.