Topic: Static and Dynamic Polymorphism Harmony
Author: talzion12@gmail.com
Date: Mon, 15 Apr 2013 15:48:04 -0700 (PDT)
Raw View
------=_Part_2442_20764183.1366066084284
Content-Type: text/plain; charset=ISO-8859-1
There is a big problem in C++ and I want to bring it into awareness and
*maybe* propose a solution to it.
*The problem:*
Today there is a war going on between static polymorphism and dynamic
polymorphism.
For example, consider the following piece of code:
void print_str(std::ofstream & os, std::string const& str) {
os << str;
}
(I'm not good at giving concrete examples)
It simply writes a std::string to an std::ofstream.
Why is it that this operation involves a virtual function call? I'm using
concrete types, and I didn't even ask for polymorphism of any kind.
Why is it that I'm not given a *choice* of whether or not I want dynamic
polymorphism, but when using std::string for example I can only use
static polymorphism? Why is it chosen for me by the class writer. Surely,
he/she doesn't know what my specific needs are.
C++ is about giving the user as much *choice* as possible to do what suits
him/her.
I feel like the choice has been made for me by someone who doesn't know
what suits me in my specific situation.
Let's look at it from a class writer's point of view:
I'm writing a new class and I want some sort of polymorphism. Do I need
static or dynamic polymorphism? And for which method/s?
No one can answer this question because *it depends on the case*.
That is exactly why you should be able to choose when the case arrives.
*What I think is the solution to the problem:*
In my opinion the solution is to have some sort of std::any class that
receives a *concept *as its
template parameter and then provides us with type erasure based on that
concept.
Much like std::function can provide a single interface to all functor types
based on signature,
std::any<std::Ostream> would be able to provide a single dynamic interface
to all std::Ostream models.
So I have a choice between the code example above and this:
template <std::ForwardRange<char> Str>
void print_name(std::any<std::Ostream> & os, Str const& str) {
os << str;
}
The first code example would use static polymorphism whereas this one would
use dynamic polymorphism for os and static for str.
Just as I asked from the compiler.
This way we can get dynamic/static polymorphism when we explicitly ask for
it.
By the way, std::any<std::Ostream> would also be a model of std::Ostream
which makes this solution very flexible and
makes this a whole lot more exciting in my opinion.
This solution is very similar to a proposed Boost library called
Boost.TypeErasure.
It is a very interesting and exciting library in my opinion, but I think
that it needs to be able to work with core-language concepts in order
to change the way we write code for the better.
Here's a link to Boost.TypeErasure's docs<http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/index.html>
..
*My vision:*
C++ will be full of types and concepts. Types would merely be
implementations of generic concepts.
C++ would be totally polymorphic, either by static or dynamic polymorphism
based on the case at hand.
Concepts would not be limited to templates anymore. They would be the best *
uncompromising* way for creating interfaces.
I'm very excited for the future of C++ and I think this might be it.
Please let me know what you think.
Tal Zion
--
---
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/?hl=en.
------=_Part_2442_20764183.1366066084284
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
There is a big problem in C++ and I want to bring it into awareness and *ma=
ybe* propose a solution to it.<div><br></div><div><b><u>The problem:</u></b=
></div><div>Today there is a war going on between static polymorphism and d=
ynamic polymorphism.<br><div>For example, consider the following piece=
of code:</div><div><br></div><div>void print_str(std::ofstream & os, s=
td::string const& str) {<br></div><div> os << str;</=
div><div>}</div><div><br></div><div>(I'm not good at giving concrete exampl=
es)</div><div>It simply writes a std::string to an std::ofstream.</div><div=
>Why is it that this operation involves a virtual function call? I'm using =
concrete types, and I didn't even ask for polymorphism of any kind.</div><d=
iv>Why is it that I'm not given a <b>choice</b> of whether or not I want dy=
namic polymorphism, but when using std::string for example I can only use</=
div><div>static polymorphism? Why is it chosen for me by the class writer. =
Surely, he/she doesn't know what my specific needs are.</div><div><br></div=
><div>C++ is about giving the user as much <b>choice</b> as possible to do =
what suits him/her.</div><div>I feel like the choice has been made for me b=
y someone who doesn't know what suits me in my specific situation.</div><di=
v><br></div><div>Let's look at it from a class writer's point of view:</div=
><div>I'm writing a new class and I want some sort of polymorphism. Do I ne=
ed static or dynamic polymorphism? And for which method/s?</div><div>No one=
can answer this question because <b>it depends on the case</b>.</div><div>=
That is exactly why you should be able to choose when the case arrives.</di=
v><div><br></div><div><b><u>What I think is the solution to the problem:</u=
></b></div><div>In my opinion the solution is to have some sort of std::any=
class that receives a <b>concept </b>as its </div><div>template param=
eter and then provides us with type erasure based on that concept.</div><di=
v>Much like std::function can provide a single interface to all functor typ=
es based on signature, </div><div>std::any<std::Ostream> would b=
e able to provide a single dynamic interface to all std::Ostream models.</d=
iv><div><br></div><div>So I have a choice between the code example above an=
d this:</div><div><br></div><div>template <std::ForwardRange<char>=
Str></div><div>void print_name(std::any<std::Ostream> & =
os, Str const& str) {</div><div> os << str;</div><di=
v>}</div><div><br></div><div>The first code example would use static polymo=
rphism whereas this one would use dynamic polymorphism for os and static fo=
r str.</div><div>Just as I asked from the compiler.</div><div>This way we c=
an get dynamic/static polymorphism when we explicitly ask for it.</div></di=
v><div>By the way, std::any<std::Ostream> would also be a model of st=
d::Ostream which makes this solution very flexible and</div><div>makes this=
a whole lot more exciting in my opinion.</div><div><br></div><div>This sol=
ution is very similar to a proposed Boost library called Boost.TypeErasure.=
</div><div>It is a very interesting and exciting library in my opinion, but=
I think that it needs to be able to work with core-language concepts in or=
der</div><div>to change the way we write code for the better.</div><div>Her=
e's a link to <a href=3D"http://steven_watanabe.users.sourceforge.net/=
type_erasure/libs/type_erasure/doc/html/index.html">Boost.TypeErasure's doc=
s</a>.</div><div><br></div><div><b><u>My vision:</u></b></div><div>C++ will=
be full of types and concepts. Types would merely be implementations of ge=
neric concepts.</div><div>C++ would be totally polymorphic, either by stati=
c or dynamic polymorphism based on the case at hand.<br></div><div>Concepts=
would not be limited to templates anymore. They would be the best <b>=
uncompromising</b> way for creating interfaces.</div><div><br></div><d=
iv>I'm very excited for the future of C++ and I think this might be it.</di=
v><div>Please let me know what you think.</div><div><br></div><div>Tal Zion=
</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_2442_20764183.1366066084284--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 15 Apr 2013 17:38:04 -0700 (PDT)
Raw View
------=_Part_1032_8523165.1366072684539
Content-Type: text/plain; charset=ISO-8859-1
On Monday, April 15, 2013 3:48:04 PM UTC-7, talz...@gmail.com wrote:
>
> There is a big problem in C++ and I want to bring it into awareness and
> *maybe* propose a solution to it.
>
> *The problem:*
> Today there is a war going on between static polymorphism and dynamic
> polymorphism.
> For example, consider the following piece of code:
>
> void print_str(std::ofstream & os, std::string const& str) {
> os << str;
> }
>
> (I'm not good at giving concrete examples)
> It simply writes a std::string to an std::ofstream.
> Why is it that this operation involves a virtual function call? I'm using
> concrete types, and I didn't even ask for polymorphism of any kind.
>
You used a `std::ofstream &`, which is very much a polymorphic type. The
compiler does not know that you will not derive from `ofstream` and that a
user will not pass such a derived class to your function.
Also, remember that `std::ofstream` forwards all of its stuff to a
`streambuf`, which may *not* be an `filebuf`.
> Why is it that I'm not given a *choice* of whether or not I want dynamic
> polymorphism, but when using std::string for example I can only use
> static polymorphism? Why is it chosen for me by the class writer. Surely,
> he/she doesn't know what my specific needs are.
>
If you have specific needs that the class writer does not provide... get a *new
class writer*. That's generally how things are done. If Tool X doesn't do
what you need, you move on to Tool Y.
C++ is about giving the user as much *choice* as possible to do what suits
> him/her.
> I feel like the choice has been made for me by someone who doesn't know
> what suits me in my specific situation.
>
> Let's look at it from a class writer's point of view:
> I'm writing a new class and I want some sort of polymorphism. Do I need
> static or dynamic polymorphism? And for which method/s?
> No one can answer this question because *it depends on the case*.
> That is exactly why you should be able to choose when the case arrives.
>
> *What I think is the solution to the problem:*
> In my opinion the solution is to have some sort of std::any class that
> receives a *concept *as its
> template parameter and then provides us with type erasure based on that
> concept.
> Much like std::function can provide a single interface to all functor
> types based on signature,
> std::any<std::Ostream> would be able to provide a single dynamic interface
> to all std::Ostream models.
>
> So I have a choice between the code example above and this:
>
> template <std::ForwardRange<char> Str>
> void print_name(std::any<std::Ostream> & os, Str const& str) {
> os << str;
> }
>
> The first code example would use static polymorphism whereas this one
> would use dynamic polymorphism for os and static for str.
> Just as I asked from the compiler.
> This way we can get dynamic/static polymorphism when we explicitly ask for
> it.
> By the way, std::any<std::Ostream> would also be a model of std::Ostream
> which makes this solution very flexible and
> makes this a whole lot more exciting in my opinion.
>
This solution is very similar to a proposed Boost library called
> Boost.TypeErasure.
> It is a very interesting and exciting library in my opinion, but I think
> that it needs to be able to work with core-language concepts in order
> to change the way we write code for the better.
> Here's a link to Boost.TypeErasure's docs<http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/index.html>
> .
>
> *My vision:*
> C++ will be full of types and concepts. Types would merely be
> implementations of generic concepts.
> C++ would be totally polymorphic, either by static or dynamic polymorphism
> based on the case at hand.
> Concepts would not be limited to templates anymore. They would be the best
> *uncompromising* way for creating interfaces.
>
> I'm very excited for the future of C++ and I think this might be it.
> Please let me know what you think.
>
What you want would require a combination of a full concepts proposal as
well as a full *reflection* proposal (by "full", I mean integration between
reflection and concepts, as well as the ability to define new members and
types based on reflection). After all, *something* is going to have to
build these `any` objects with an interface based on a concept. That would
have to be done via reflection over the concept and building a type based
on that.
Maybe for C++22.
--
---
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/?hl=en.
------=_Part_1032_8523165.1366072684539
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Monday, April 15, 2013 3:48:04 PM UTC-7, talz...@gmail.com wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">There is a big problem in C++ and I w=
ant to bring it into awareness and *maybe* propose a solution to it.<div><b=
r></div><div><b><u>The problem:</u></b></div><div>Today there is a war goin=
g on between static polymorphism and dynamic polymorphism.<br><div>For exam=
ple, consider the following piece of code:</div><div><br></div><div>vo=
id print_str(std::ofstream & os, std::string const& str) {<br></div=
><div> os << str;</div><div>}</div><div><br></div><div>(=
I'm not good at giving concrete examples)</div><div>It simply writes a std:=
:string to an std::ofstream.</div><div>Why is it that this operation involv=
es a virtual function call? I'm using concrete types, and I didn't even ask=
for polymorphism of any kind.</div></div></blockquote><div><br>You used a =
`std::ofstream &`, which is very much a polymorphic type. The compiler =
does not know that you will not derive from `ofstream` and that a user will=
not pass such a derived class to your function.<br><br>Also, remember that=
`std::ofstream` forwards all of its stuff to a `streambuf`, which may <i>n=
ot</i> be an `filebuf`.<br> </div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div><div>Why is it that I'm not given a <b>choice</b> of whether =
or not I want dynamic polymorphism, but when using std::string for example =
I can only use</div><div>static polymorphism? Why is it chosen for me by th=
e class writer. Surely, he/she doesn't know what my specific needs are.</di=
v></div></blockquote><div><br>If you have specific needs that the class wri=
ter does not provide... get a <i>new class writer</i>. That's generally how=
things are done. If Tool X doesn't do what you need, you move on to Tool Y=
..<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><div></div=
><div>C++ is about giving the user as much <b>choice</b> as possible to do =
what suits him/her.</div><div>I feel like the choice has been made for me b=
y someone who doesn't know what suits me in my specific situation.</div><di=
v><br></div><div>Let's look at it from a class writer's point of view:</div=
><div>I'm writing a new class and I want some sort of polymorphism. Do I ne=
ed static or dynamic polymorphism? And for which method/s?</div><div>No one=
can answer this question because <b>it depends on the case</b>.</div><div>=
That is exactly why you should be able to choose when the case arrives.</di=
v><div><br></div><div><b><u>What I think is the solution to the problem:</u=
></b></div><div>In my opinion the solution is to have some sort of std::any=
class that receives a <b>concept </b>as its </div><div>template param=
eter and then provides us with type erasure based on that concept.</div><di=
v>Much like std::function can provide a single interface to all functor typ=
es based on signature, </div><div>std::any<std::Ostream> would b=
e able to provide a single dynamic interface to all std::Ostream models.</d=
iv><div><br></div><div>So I have a choice between the code example above an=
d this:</div><div><br></div><div>template <std::ForwardRange<char>=
Str></div><div>void print_name(std::any<std::<wbr>Ostream> &=
amp; os, Str const& str) {</div><div> os << str;</di=
v><div>}</div><div><br></div><div>The first code example would use static p=
olymorphism whereas this one would use dynamic polymorphism for os and stat=
ic for str.</div><div>Just as I asked from the compiler.</div><div>This way=
we can get dynamic/static polymorphism when we explicitly ask for it.</div=
></div><div>By the way, std::any<std::Ostream> would also be a model =
of std::Ostream which makes this solution very flexible and</div><div>makes=
this a whole lot more exciting in my opinion.</div></blockquote><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div>This solution is very similar to a =
proposed Boost library called Boost.TypeErasure.</div><div>It is a very int=
eresting and exciting library in my opinion, but I think that it needs to b=
e able to work with core-language concepts in order</div><div>to change the=
way we write code for the better.</div><div>Here's a link to <a href=
=3D"http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_era=
sure/doc/html/index.html" target=3D"_blank">Boost.TypeErasure's docs</a>.</=
div><div><br></div><div><b><u>My vision:</u></b></div><div>C++ will be full=
of types and concepts. Types would merely be implementations of generic co=
ncepts.</div><div>C++ would be totally polymorphic, either by static or dyn=
amic polymorphism based on the case at hand.<br></div><div>Concepts would n=
ot be limited to templates anymore. They would be the best <b>uncompro=
mising</b> way for creating interfaces.</div><div><br></div><div>I'm v=
ery excited for the future of C++ and I think this might be it.</div><div>P=
lease let me know what you think.</div></blockquote><div><br>What you want =
would require a combination of a full concepts proposal as well as a full <=
i>reflection</i> proposal (by "full", I mean integration between reflection=
and concepts, as well as the ability to define new members and types based=
on reflection). After all, <i>something</i> is going to have to build thes=
e `any` objects with an interface based on a concept. That would have to be=
done via reflection over the concept and building a type based on that.<br=
><br>Maybe for C++22.<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1032_8523165.1366072684539--
.
Author: talzion12@gmail.com
Date: Mon, 15 Apr 2013 17:46:45 -0700 (PDT)
Raw View
------=_Part_2446_1114473.1366073205572
Content-Type: text/plain; charset=ISO-8859-1
You are correct.
I think that a library implementation of std::any would be best and that
would require reflection and concepts.
Reflection and concepts are currently being explored by people much
more experienced than me.
Nonetheless I thought this issue would be worth bringing up to help with
shaping those features.
This is how I see C++'s future and I think many people would gain from C++
being this way.
On Tuesday, April 16, 2013 3:38:04 AM UTC+3, Nicol Bolas wrote:
>
> On Monday, April 15, 2013 3:48:04 PM UTC-7, talz...@gmail.com wrote:
>>
>> There is a big problem in C++ and I want to bring it into awareness and
>> *maybe* propose a solution to it.
>>
>> *The problem:*
>> Today there is a war going on between static polymorphism and dynamic
>> polymorphism.
>> For example, consider the following piece of code:
>>
>> void print_str(std::ofstream & os, std::string const& str) {
>> os << str;
>> }
>>
>> (I'm not good at giving concrete examples)
>> It simply writes a std::string to an std::ofstream.
>> Why is it that this operation involves a virtual function call? I'm using
>> concrete types, and I didn't even ask for polymorphism of any kind.
>>
>
> You used a `std::ofstream &`, which is very much a polymorphic type. The
> compiler does not know that you will not derive from `ofstream` and that a
> user will not pass such a derived class to your function.
>
> Also, remember that `std::ofstream` forwards all of its stuff to a
> `streambuf`, which may *not* be an `filebuf`.
>
>
>> Why is it that I'm not given a *choice* of whether or not I want dynamic
>> polymorphism, but when using std::string for example I can only use
>> static polymorphism? Why is it chosen for me by the class writer. Surely,
>> he/she doesn't know what my specific needs are.
>>
>
> If you have specific needs that the class writer does not provide... get a
> *new class writer*. That's generally how things are done. If Tool X
> doesn't do what you need, you move on to Tool Y.
>
> C++ is about giving the user as much *choice* as possible to do what
>> suits him/her.
>> I feel like the choice has been made for me by someone who doesn't know
>> what suits me in my specific situation.
>>
>> Let's look at it from a class writer's point of view:
>> I'm writing a new class and I want some sort of polymorphism. Do I need
>> static or dynamic polymorphism? And for which method/s?
>> No one can answer this question because *it depends on the case*.
>> That is exactly why you should be able to choose when the case arrives.
>>
>> *What I think is the solution to the problem:*
>> In my opinion the solution is to have some sort of std::any class that
>> receives a *concept *as its
>> template parameter and then provides us with type erasure based on that
>> concept.
>> Much like std::function can provide a single interface to all functor
>> types based on signature,
>> std::any<std::Ostream> would be able to provide a single dynamic
>> interface to all std::Ostream models.
>>
>> So I have a choice between the code example above and this:
>>
>> template <std::ForwardRange<char> Str>
>> void print_name(std::any<std::Ostream> & os, Str const& str) {
>> os << str;
>> }
>>
>> The first code example would use static polymorphism whereas this one
>> would use dynamic polymorphism for os and static for str.
>> Just as I asked from the compiler.
>> This way we can get dynamic/static polymorphism when we explicitly ask
>> for it.
>> By the way, std::any<std::Ostream> would also be a model of std::Ostream
>> which makes this solution very flexible and
>> makes this a whole lot more exciting in my opinion.
>>
> This solution is very similar to a proposed Boost library called
>> Boost.TypeErasure.
>> It is a very interesting and exciting library in my opinion, but I think
>> that it needs to be able to work with core-language concepts in order
>> to change the way we write code for the better.
>> Here's a link to Boost.TypeErasure's docs<http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/index.html>
>> .
>>
>> *My vision:*
>> C++ will be full of types and concepts. Types would merely be
>> implementations of generic concepts.
>> C++ would be totally polymorphic, either by static or dynamic
>> polymorphism based on the case at hand.
>> Concepts would not be limited to templates anymore. They would be the
>> best *uncompromising* way for creating interfaces.
>>
>> I'm very excited for the future of C++ and I think this might be it.
>> Please let me know what you think.
>>
>
> What you want would require a combination of a full concepts proposal as
> well as a full *reflection* proposal (by "full", I mean integration
> between reflection and concepts, as well as the ability to define new
> members and types based on reflection). After all, *something* is going
> to have to build these `any` objects with an interface based on a concept.
> That would have to be done via reflection over the concept and building a
> type based on that.
>
> Maybe for C++22.
>
--
---
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/?hl=en.
------=_Part_2446_1114473.1366073205572
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
You are correct.<div>I think that a library implementation of std::any woul=
d be best and that would require reflection and concepts.<div>Reflection an=
d concepts are currently being explored by people much more experience=
d than me.</div><div>Nonetheless I thought this issue would be worth b=
ringing up to help with shaping those features.</div><div><br></div><div>Th=
is is how I see C++'s future and I think many people would gain from C++ be=
ing this way.</div><div><br>On Tuesday, April 16, 2013 3:38:04 AM UTC+3, Ni=
col Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Monday, Apr=
il 15, 2013 3:48:04 PM UTC-7, <a>talz...@gmail.com</a> wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">There is a big problem in C++ and I want to bring=
it into awareness and *maybe* propose a solution to it.<div><br></div><div=
><b><u>The problem:</u></b></div><div>Today there is a war going on between=
static polymorphism and dynamic polymorphism.<br><div>For example, conside=
r the following piece of code:</div><div><br></div><div>void print_str=
(std::ofstream & os, std::string const& str) {<br></div><div> =
os << str;</div><div>}</div><div><br></div><div>(I'm not good=
at giving concrete examples)</div><div>It simply writes a std::string to a=
n std::ofstream.</div><div>Why is it that this operation involves a virtual=
function call? I'm using concrete types, and I didn't even ask for polymor=
phism of any kind.</div></div></blockquote><div><br>You used a `std::ofstre=
am &`, which is very much a polymorphic type. The compiler does not kno=
w that you will not derive from `ofstream` and that a user will not pass su=
ch a derived class to your function.<br><br>Also, remember that `std::ofstr=
eam` forwards all of its stuff to a `streambuf`, which may <i>not</i> be an=
`filebuf`.<br> </div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><di=
v>Why is it that I'm not given a <b>choice</b> of whether or not I want dyn=
amic polymorphism, but when using std::string for example I can only use</d=
iv><div>static polymorphism? Why is it chosen for me by the class writer. S=
urely, he/she doesn't know what my specific needs are.</div></div></blockqu=
ote><div><br>If you have specific needs that the class writer does not prov=
ide... get a <i>new class writer</i>. That's generally how things are done.=
If Tool X doesn't do what you need, you move on to Tool Y.<br><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div><div></div><div>C++ is about giv=
ing the user as much <b>choice</b> as possible to do what suits him/her.</d=
iv><div>I feel like the choice has been made for me by someone who doesn't =
know what suits me in my specific situation.</div><div><br></div><div>Let's=
look at it from a class writer's point of view:</div><div>I'm writing a ne=
w class and I want some sort of polymorphism. Do I need static or dynamic p=
olymorphism? And for which method/s?</div><div>No one can answer this quest=
ion because <b>it depends on the case</b>.</div><div>That is exactly why yo=
u should be able to choose when the case arrives.</div><div><br></div><div>=
<b><u>What I think is the solution to the problem:</u></b></div><div>In my =
opinion the solution is to have some sort of std::any class that receives a=
<b>concept </b>as its </div><div>template parameter and then provides=
us with type erasure based on that concept.</div><div>Much like std::funct=
ion can provide a single interface to all functor types based on signature,=
</div><div>std::any<std::Ostream> would be able to provide a si=
ngle dynamic interface to all std::Ostream models.</div><div><br></div><div=
>So I have a choice between the code example above and this:</div><div><br>=
</div><div>template <std::ForwardRange<char> Str></div><div>voi=
d print_name(std::any<std::<wbr>Ostream> & os, Str const&=
; str) {</div><div> os << str;</div><div>}</div><div><br=
></div><div>The first code example would use static polymorphism whereas th=
is one would use dynamic polymorphism for os and static for str.</div><div>=
Just as I asked from the compiler.</div><div>This way we can get dynamic/st=
atic polymorphism when we explicitly ask for it.</div></div><div>By the way=
, std::any<std::Ostream> would also be a model of std::Ostream which =
makes this solution very flexible and</div><div>makes this a whole lot more=
exciting in my opinion.</div></blockquote><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div>This solution is very similar to a proposed Boost library call=
ed Boost.TypeErasure.</div><div>It is a very interesting and exciting libra=
ry in my opinion, but I think that it needs to be able to work with core-la=
nguage concepts in order</div><div>to change the way we write code for the =
better.</div><div>Here's a link to <a href=3D"http://steven_watanabe.u=
sers.sourceforge.net/type_erasure/libs/type_erasure/doc/html/index.html" ta=
rget=3D"_blank">Boost.TypeErasure's docs</a>.</div><div><br></div><div><b><=
u>My vision:</u></b></div><div>C++ will be full of types and concepts. Type=
s would merely be implementations of generic concepts.</div><div>C++ would =
be totally polymorphic, either by static or dynamic polymorphism based on t=
he case at hand.<br></div><div>Concepts would not be limited to templates a=
nymore. They would be the best <b>uncompromising</b> way for crea=
ting interfaces.</div><div><br></div><div>I'm very excited for the future o=
f C++ and I think this might be it.</div><div>Please let me know what you t=
hink.</div></blockquote><div><br>What you want would require a combination =
of a full concepts proposal as well as a full <i>reflection</i> proposal (b=
y "full", I mean integration between reflection and concepts, as well as th=
e ability to define new members and types based on reflection). After all, =
<i>something</i> is going to have to build these `any` objects with an inte=
rface based on a concept. That would have to be done via reflection over th=
e concept and building a type based on that.<br><br>Maybe for C++22.<br></d=
iv></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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_2446_1114473.1366073205572--
.
Author: minchul park <summerlight00@gmail.com>
Date: Tue, 16 Apr 2013 10:46:29 +0900
Raw View
--f46d044788d9c074c504da7089d1
Content-Type: text/plain; charset=ISO-8859-1
I think structural type system is very desirable feature and I believe it's
the C++'s way to go. I don't think ostream is good example - component
based system in game industry would be practical example that shows its
demand.
http://scottbilas.com/files/2002/gdc_san_jose/game_objects_slides.ppt
http://www.gamearchitect.net/Articles/GameObjects1.html
But there are several difficulties about its implementation. Since compiler
doesn't know about every relation to interface-implementation on interface
compilation, dispatch table should be lazily constructed (affects
performance negatively), or compilation model change might to be required.
(Though link time code gen can build necessary dispatch table, dynamic
linking should be considered.)
IMO, it's very hard to implement it correctly/efficiently with library
approach - it should be tightly integrated into type system. Moreover,
since there are some more proposals related to type system (multi-method,
type switch ...), I expect some more extra consideration for them.
Below is a good article about implementation of interface in go lang. I
hope this helpful to interested people.
http://research.swtch.com/interfaces
On Tue, Apr 16, 2013 at 7:48 AM, <talzion12@gmail.com> wrote:
> There is a big problem in C++ and I want to bring it into awareness and
> *maybe* propose a solution to it.
>
> *The problem:*
> Today there is a war going on between static polymorphism and dynamic
> polymorphism.
> For example, consider the following piece of code:
>
> void print_str(std::ofstream & os, std::string const& str) {
> os << str;
> }
>
> (I'm not good at giving concrete examples)
> It simply writes a std::string to an std::ofstream.
> Why is it that this operation involves a virtual function call? I'm using
> concrete types, and I didn't even ask for polymorphism of any kind.
> Why is it that I'm not given a *choice* of whether or not I want dynamic
> polymorphism, but when using std::string for example I can only use
> static polymorphism? Why is it chosen for me by the class writer. Surely,
> he/she doesn't know what my specific needs are.
>
> C++ is about giving the user as much *choice* as possible to do what
> suits him/her.
> I feel like the choice has been made for me by someone who doesn't know
> what suits me in my specific situation.
>
> Let's look at it from a class writer's point of view:
> I'm writing a new class and I want some sort of polymorphism. Do I need
> static or dynamic polymorphism? And for which method/s?
> No one can answer this question because *it depends on the case*.
> That is exactly why you should be able to choose when the case arrives.
>
> *What I think is the solution to the problem:*
> In my opinion the solution is to have some sort of std::any class that
> receives a *concept *as its
> template parameter and then provides us with type erasure based on that
> concept.
> Much like std::function can provide a single interface to all functor
> types based on signature,
> std::any<std::Ostream> would be able to provide a single dynamic interface
> to all std::Ostream models.
>
> So I have a choice between the code example above and this:
>
> template <std::ForwardRange<char> Str>
> void print_name(std::any<std::Ostream> & os, Str const& str) {
> os << str;
> }
>
> The first code example would use static polymorphism whereas this one
> would use dynamic polymorphism for os and static for str.
> Just as I asked from the compiler.
> This way we can get dynamic/static polymorphism when we explicitly ask for
> it.
> By the way, std::any<std::Ostream> would also be a model of std::Ostream
> which makes this solution very flexible and
> makes this a whole lot more exciting in my opinion.
>
> This solution is very similar to a proposed Boost library called
> Boost.TypeErasure.
> It is a very interesting and exciting library in my opinion, but I think
> that it needs to be able to work with core-language concepts in order
> to change the way we write code for the better.
> Here's a link to Boost.TypeErasure's docs<http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/index.html>
> .
>
> *My vision:*
> C++ will be full of types and concepts. Types would merely be
> implementations of generic concepts.
> C++ would be totally polymorphic, either by static or dynamic polymorphism
> based on the case at hand.
> Concepts would not be limited to templates anymore. They would be the best
> *uncompromising* way for creating interfaces.
>
> I'm very excited for the future of C++ and I think this might be it.
> Please let me know what you think.
>
> Tal Zion
>
> --
>
> ---
> 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/?hl=en.
>
>
>
--
Min-chul Park (summerlight00@gmail.com / http://summerlight.tistory.com)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--f46d044788d9c074c504da7089d1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div style>I think structural type system is very desirabl=
e feature and I believe it's the C++'s way to go. I don't think=
ostream is good example - component based system in game industry would be=
practical example that shows its demand.</div>
<div style><br></div><div style><a href=3D"http://scottbilas.com/files/2002=
/gdc_san_jose/game_objects_slides.ppt">http://scottbilas.com/files/2002/gdc=
_san_jose/game_objects_slides.ppt</a><br></div><div style><a href=3D"http:/=
/www.gamearchitect.net/Articles/GameObjects1.html">http://www.gamearchitect=
..net/Articles/GameObjects1.html</a><br>
</div><div style><br></div><div style>But there are several difficulties ab=
out its implementation. Since compiler doesn't know about every relatio=
n to interface-implementation on interface compilation, dispatch table shou=
ld be lazily constructed (affects performance negatively), or compilation m=
odel change might to be required. (Though link time code gen can build nece=
ssary dispatch table, dynamic linking should be considered.)</div>
<div style><br></div><div style>IMO, it's very hard to implement it cor=
rectly/efficiently with library approach - it should be tightly integrated =
into type system. Moreover, since there are some more proposals related to =
type system (multi-method, type switch ...), I expect some more extra consi=
deration for them.</div>
<div style><br></div><div style>Below is a good article about implementatio=
n of interface in go lang. I hope this helpful to interested people.</div><=
div style><br></div><div style><a href=3D"http://research.swtch.com/interfa=
ces">http://research.swtch.com/interfaces</a><br>
</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">O=
n Tue, Apr 16, 2013 at 7:48 AM, <span dir=3D"ltr"><<a href=3D"mailto:ta=
lzion12@gmail.com" target=3D"_blank">talzion12@gmail.com</a>></span> wro=
te:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">There is a big problem in C++ and I want to =
bring it into awareness and *maybe* propose a solution to it.<div><br></div=
>
<div><b><u>The problem:</u></b></div><div>Today there is a war going on bet=
ween static polymorphism and dynamic polymorphism.<br><div>For example, con=
sider the following=A0piece of code:</div><div><br></div><div>void print_st=
r(std::ofstream & os, std::string const& str) {<br>
</div><div>=A0 =A0 os << str;</div><div>}</div><div><br></div><div>(I=
'm not good at giving concrete examples)</div><div>It simply writes a s=
td::string to an std::ofstream.</div><div>Why is it that this operation inv=
olves a virtual function call? I'm using concrete types, and I didn'=
;t even ask for polymorphism of any kind.</div>
<div>Why is it that I'm not given a <b>choice</b> of whether or not I w=
ant dynamic polymorphism, but when using std::string for example I can only=
use</div><div>static polymorphism? Why is it chosen for me by the class wr=
iter. Surely, he/she doesn't know what my specific needs are.</div>
<div><br></div><div>C++ is about giving the user as much <b>choice</b> as p=
ossible to do what suits him/her.</div><div>I feel like the choice has been=
made for me by someone who doesn't know what suits me in my specific s=
ituation.</div>
<div><br></div><div>Let's look at it from a class writer's point of=
view:</div><div>I'm writing a new class and I want some sort of polymo=
rphism. Do I need static or dynamic polymorphism? And for which method/s?</=
div>
<div>No one can answer this question because <b>it depends on the case</b>.=
</div><div>That is exactly why you should be able to choose when the case a=
rrives.</div><div><br></div><div><b><u>What I think is the solution to the =
problem:</u></b></div>
<div>In my opinion the solution is to have some sort of std::any class that=
receives a <b>concept </b>as its=A0</div><div>template parameter and then =
provides us with type erasure based on that concept.</div><div>Much like st=
d::function can provide a single interface to all functor types based on si=
gnature,=A0</div>
<div>std::any<std::Ostream> would be able to provide a single dynamic=
interface to all std::Ostream models.</div><div><br></div><div>So I have a=
choice between the code example above and this:</div><div><br></div><div>
template <std::ForwardRange<char> Str></div><div>void=A0print_n=
ame(std::any<std::Ostream> & os, Str const& str) {</div><div>=
=A0 =A0 os << str;</div><div>}</div><div><br></div><div>The first cod=
e example would use static polymorphism whereas this one would use dynamic =
polymorphism for os and static for str.</div>
<div>Just as I asked from the compiler.</div><div>This way we can get dynam=
ic/static polymorphism when we explicitly ask for it.</div></div><div>By th=
e way, std::any<std::Ostream> would also be a model of std::Ostream w=
hich makes this solution very flexible and</div>
<div>makes this a whole lot more exciting in my opinion.</div><div><br></di=
v><div>This solution is very similar to a proposed Boost library called Boo=
st.TypeErasure.</div><div>It is a very interesting and exciting library in =
my opinion, but I think that it needs to be able to work with core-language=
concepts in order</div>
<div>to change the way we write code for the better.</div><div>Here's a=
link to=A0<a href=3D"http://steven_watanabe.users.sourceforge.net/type_era=
sure/libs/type_erasure/doc/html/index.html" target=3D"_blank">Boost.TypeEra=
sure's docs</a>.</div>
<div><br></div><div><b><u>My vision:</u></b></div><div>C++ will be full of =
types and concepts. Types would merely be implementations of generic concep=
ts.</div><div>C++ would be totally polymorphic, either by static or dynamic=
polymorphism based on the case at hand.<br>
</div><div>Concepts would not be limited to templates anymore. They would b=
e the best=A0<b>uncompromising</b>=A0way for creating interfaces.</div><div=
><br></div><div>I'm very excited for the future of C++ and I think this=
might be it.</div>
<div>Please let me know what you think.</div><div><br></div><div>Tal Zion</=
div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r><div>Min-chul Park (<a href=3D"mailto:summerlight00@gmail.com" target=3D"=
_blank">summerlight00@gmail.com</a>=A0/ <a href=3D"http://summerlight.tisto=
ry.com/" target=3D"_blank">http://summerlight.tistory.com</a>)</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--f46d044788d9c074c504da7089d1--
.
Author: talzion12@gmail.com
Date: Mon, 15 Apr 2013 19:07:20 -0700 (PDT)
Raw View
------=_Part_2346_7408309.1366078040866
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, April 16, 2013 3:38:04 AM UTC+3, Nicol Bolas wrote:
> On Monday, April 15, 2013 3:48:04 PM UTC-7, talz...@gmail.com wrote:
>>
>> There is a big problem in C++ and I want to bring it into awareness and
>> *maybe* propose a solution to it.
>>
>> *The problem:*
>> Today there is a war going on between static polymorphism and dynamic
>> polymorphism.
>> For example, consider the following piece of code:
>>
>> void print_str(std::ofstream & os, std::string const& str) {
>> os << str;
>> }
>>
>> (I'm not good at giving concrete examples)
>> It simply writes a std::string to an std::ofstream.
>> Why is it that this operation involves a virtual function call? I'm using
>> concrete types, and I didn't even ask for polymorphism of any kind.
>>
>
> You used a `std::ofstream &`, which is very much a polymorphic type. The
> compiler does not know that you will not derive from `ofstream` and that a
> user will not pass such a derived class to your function.
>
> Also, remember that `std::ofstream` forwards all of its stuff to a
> `streambuf`, which may *not* be an `filebuf`.
>
I know that std::ofstream& is a polymorphic type and that is the point.
It shouldn't be a polymorphic type on it's own. We received polymorphic
behavior from it although we didn't ask for it.
I'm not saying that it should be changed because of deprecation issues, but
if everything wasn't virtual and you only got polymorphism through
std::any and templates then the user would have a choice whether or not
he/she wants polymorphism and also what kind of polymorphism.
>
>> Why is it that I'm not given a *choice* of whether or not I want dynamic
>> polymorphism, but when using std::string for example I can only use
>> static polymorphism? Why is it chosen for me by the class writer. Surely,
>> he/she doesn't know what my specific needs are.
>>
>
> If you have specific needs that the class writer does not provide... get a
> *new class writer*. That's generally how things are done. If Tool X
> doesn't do what you need, you move on to Tool Y.
>
What I mean is that tool X shouldn't contain whether it uses virtual
methods or not.
Tool X does what it does. If you want to refer to a generic tool that goes
by the same concept, you are free to choose if you want static or dynamic
polymorphism.
You decide it when you use it.
For example, if iostream wasn't polymorphic by default, with this proposal
you would be able to use it in both dynamic and static polymorphic ways.
With this proposal, if you want a dynamically polymorphic std::string you
don't have to write a whole new std::string class.
You can just use the current one with an std::any.
Why is std::string not a polymorphic type and std::ofstream is? std::string
is just an implementation of a general purpose string, not all string
implementations.
>
>
C++ is about giving the user as much *choice* as possible to do what suits
>> him/her.
>> I feel like the choice has been made for me by someone who doesn't know
>> what suits me in my specific situation.
>>
>> Let's look at it from a class writer's point of view:
>> I'm writing a new class and I want some sort of polymorphism. Do I need
>> static or dynamic polymorphism? And for which method/s?
>> No one can answer this question because *it depends on the case*.
>> That is exactly why you should be able to choose when the case arrives.
>>
>> *What I think is the solution to the problem:*
>> In my opinion the solution is to have some sort of std::any class that
>> receives a *concept *as its
>> template parameter and then provides us with type erasure based on that
>> concept.
>> Much like std::function can provide a single interface to all functor
>> types based on signature,
>> std::any<std::Ostream> would be able to provide a single dynamic
>> interface to all std::Ostream models.
>>
>> So I have a choice between the code example above and this:
>>
>> template <std::ForwardRange<char> Str>
>> void print_name(std::any<std::Ostream> & os, Str const& str) {
>> os << str;
>> }
>>
>> The first code example would use static polymorphism whereas this one
>> would use dynamic polymorphism for os and static for str.
>> Just as I asked from the compiler.
>> This way we can get dynamic/static polymorphism when we explicitly ask
>> for it.
>> By the way, std::any<std::Ostream> would also be a model of std::Ostream
>> which makes this solution very flexible and
>> makes this a whole lot more exciting in my opinion.
>>
> This solution is very similar to a proposed Boost library called
>> Boost.TypeErasure.
>> It is a very interesting and exciting library in my opinion, but I think
>> that it needs to be able to work with core-language concepts in order
>> to change the way we write code for the better.
>> Here's a link to Boost.TypeErasure's docs<http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/doc/html/index.html>
>> .
>>
>> *My vision:*
>> C++ will be full of types and concepts. Types would merely be
>> implementations of generic concepts.
>> C++ would be totally polymorphic, either by static or dynamic
>> polymorphism based on the case at hand.
>> Concepts would not be limited to templates anymore. They would be the
>> best *uncompromising* way for creating interfaces.
>>
>> I'm very excited for the future of C++ and I think this might be it.
>> Please let me know what you think.
>>
>
> What you want would require a combination of a full concepts proposal as
> well as a full *reflection* proposal (by "full", I mean integration
> between reflection and concepts, as well as the ability to define new
> members and types based on reflection). After all, *something* is going
> to have to build these `any` objects with an interface based on a concept.
> That would have to be done via reflection over the concept and building a
> type based on that.
>
> Maybe for C++22.
>
--
---
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/?hl=en.
------=_Part_2346_7408309.1366078040866
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tuesday, April 16, 2013 3:38:04 AM UTC+3, Nicol Bolas wrote:<br><div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On Monday, April 15, 2013 3:48:04=
PM UTC-7, <a>talz...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote"=
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">There is a big problem in C++ and I want to bring it into awareness =
and *maybe* propose a solution to it.<div><br></div><div><b><u>The problem:=
</u></b></div><div>Today there is a war going on between static polymorphis=
m and dynamic polymorphism.<br><div>For example, consider the following&nbs=
p;piece of code:</div><div><br></div><div>void print_str(std::ofstream &=
; os, std::string const& str) {<br></div><div> os <<=
str;</div><div>}</div><div><br></div><div>(I'm not good at giving concrete=
examples)</div><div>It simply writes a std::string to an std::ofstream.</d=
iv><div>Why is it that this operation involves a virtual function call? I'm=
using concrete types, and I didn't even ask for polymorphism of any kind.<=
/div></div></blockquote><div><br>You used a `std::ofstream &`, which is=
very much a polymorphic type. The compiler does not know that you will not=
derive from `ofstream` and that a user will not pass such a derived class =
to your function.<br><br>Also, remember that `std::ofstream` forwards all o=
f its stuff to a `streambuf`, which may <i>not</i> be an `filebuf`.</div></=
blockquote><div><br></div><div>I know that std::ofstream& is a polymorp=
hic type and that is the point.<div>It shouldn't be a polymorphic type on i=
t's own. We received polymorphic behavior from it although we didn't ask fo=
r it.</div></div><div>I'm not saying that it should be changed because of d=
eprecation issues, but if everything wasn't virtual and you only got polymo=
rphism through</div><div>std::any and templates then the user would have a =
choice whether or not he/she wants polymorphism and also what kind of polym=
orphism. </div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div> </div><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Wh=
y is it that I'm not given a <b>choice</b> of whether or not I want dynamic=
polymorphism, but when using std::string for example I can only use</div><=
div>static polymorphism? Why is it chosen for me by the class writer. Surel=
y, he/she doesn't know what my specific needs are.</div></div></blockquote>=
<div><br>If you have specific needs that the class writer does not provide.=
... get a <i>new class writer</i>. That's generally how things are done. If =
Tool X doesn't do what you need, you move on to Tool Y.</div></blockquote><=
div><br></div><div>What I mean is that tool X shouldn't contain whether it =
uses virtual methods or not.</div><div>Tool X does what it does. If you wan=
t to refer to a generic tool that goes by the same concept, you are free to=
choose if you want static or dynamic polymorphism.</div><div>You decide it=
when you use it.</div><div><br></div><div>For example, if iostream wasn't =
polymorphic by default, with this proposal you would be able to use it in b=
oth dynamic and static polymorphic ways.</div><div>With this proposal, if y=
ou want a dynamically polymorphic std::string you don't have to write a who=
le new std::string class.</div><div>You can just use the current one with a=
n std::any.</div><div>Why is std::string not a polymorphic type and std::of=
stream is? std::string is just an implementation of a general purpose strin=
g, not all string implementations.</div><div> </div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div> </div></blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div><div></div><div>C++ is about giving the user as much <b>choice</b>=
as possible to do what suits him/her.</div><div>I feel like the choice has=
been made for me by someone who doesn't know what suits me in my specific =
situation.</div><div><br></div><div>Let's look at it from a class writer's =
point of view:</div><div>I'm writing a new class and I want some sort of po=
lymorphism. Do I need static or dynamic polymorphism? And for which method/=
s?</div><div>No one can answer this question because <b>it depends on the c=
ase</b>.</div><div>That is exactly why you should be able to choose when th=
e case arrives.</div><div><br></div><div><b><u>What I think is the solution=
to the problem:</u></b></div><div>In my opinion the solution is to have so=
me sort of std::any class that receives a <b>concept </b>as its </div>=
<div>template parameter and then provides us with type erasure based on tha=
t concept.</div><div>Much like std::function can provide a single interface=
to all functor types based on signature, </div><div>std::any<std::=
Ostream> would be able to provide a single dynamic interface to all std:=
:Ostream models.</div><div><br></div><div>So I have a choice between the co=
de example above and this:</div><div><br></div><div>template <std::Forwa=
rdRange<char> Str></div><div>void print_name(std::any<std:=
:<wbr>Ostream> & os, Str const& str) {</div><div> o=
s << str;</div><div>}</div><div><br></div><div>The first code example=
would use static polymorphism whereas this one would use dynamic polymorph=
ism for os and static for str.</div><div>Just as I asked from the compiler.=
</div><div>This way we can get dynamic/static polymorphism when we explicit=
ly ask for it.</div></div><div>By the way, std::any<std::Ostream> wou=
ld also be a model of std::Ostream which makes this solution very flexible =
and</div><div>makes this a whole lot more exciting in my opinion.</div></bl=
ockquote><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div>This solution is very=
similar to a proposed Boost library called Boost.TypeErasure.</div><div>It=
is a very interesting and exciting library in my opinion, but I think that=
it needs to be able to work with core-language concepts in order</div><div=
>to change the way we write code for the better.</div><div>Here's a link to=
<a href=3D"http://steven_watanabe.users.sourceforge.net/type_erasure/=
libs/type_erasure/doc/html/index.html" target=3D"_blank">Boost.TypeErasure'=
s docs</a>.</div><div><br></div><div><b><u>My vision:</u></b></div><div>C++=
will be full of types and concepts. Types would merely be implementations =
of generic concepts.</div><div>C++ would be totally polymorphic, either by =
static or dynamic polymorphism based on the case at hand.<br></div><div>Con=
cepts would not be limited to templates anymore. They would be the best&nbs=
p;<b>uncompromising</b> way for creating interfaces.</div><div><br></d=
iv><div>I'm very excited for the future of C++ and I think this might be it=
..</div><div>Please let me know what you think.</div></blockquote><div><br>W=
hat you want would require a combination of a full concepts proposal as wel=
l as a full <i>reflection</i> proposal (by "full", I mean integration betwe=
en reflection and concepts, as well as the ability to define new members an=
d types based on reflection). After all, <i>something</i> is going to have =
to build these `any` objects with an interface based on a concept. That wou=
ld have to be done via reflection over the concept and building a type base=
d on that.<br><br>Maybe for C++22.<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_2346_7408309.1366078040866--
.