

The Four Polymorphisms in C++ - pkrumins
http://www.catonmat.net/blog/cpp-polymorphism

======
vog
That's a great summary!

I'm always disappointed if people only know one kind of polymorphism and apply
that rigorously to all problems. Overviews like this might help people to make
a _conscious_ decision on which language construct would be a good fit for
their actual design problem.

~~~
obiterdictum
It may be a good summary, but I completely disagree with author's (implied)
assertion that all these should be lumped under one term. All these concepts
are different in their mechanics, which is the reason we have different
terminology to describe them. Just call overloading overloading. C++ does not
need more ambiguity, it needs less.

~~~
pkrumins
I never implied that they should lumped under one term. On the contrary. I
wrote out all the meanings the term can have to disambiguate it.

~~~
seliopou
The blog post is titled "The Four Polymorphisms in C++."

~~~
pkrumins
Yes, the four polymorphisms you can find in C++. Am I missing something?

~~~
dkarl
You're missing the fact that "polymorphism" has an established meaning in C++
which excludes two of your examples. You're using a definition of polymorphism
that is independent of C++ and applying it to C++, which is certainly a valid
exercise, but you haven't bothered to tell us what your definition is or
explain why it applies to each example. If I assume that by "polymorphism" you
mean when a single name can be used to refer to different things, then
consider the following:

    
    
      void foo(float f);
    
      int main()
      {
        foo(1);
        return 0;
      }
    

What name is polymorphic here? I suppose you can say that foo is polymorphic
if you attribute the coercion operation to foo, but that's not the way I think
about it. foo is called after the coercion. The coercion is caused by the
relation of the type of 1 with the type of the function parameter f.

In your blog post it would have made things much clearer if you had
acknowledged the conventional usage of the term in the context of C++ and
explained the different definition you were using.

------
bmm6o
I know it's just a blog post, but the section on "Parametric Polymorphism"
says that the same code executes for any type. But in the example given, "a >
b" will evaluate to entirely different operations depending on the type, and
in fact only works because of the other types of polymorphism. Since this is
such a common situation, I might not make it a first class citizen in the
taxonomy.

~~~
pkrumins
In that example I only wanted to illustrate parametric polymorphism on type T
(and ignore the overloading on operator > that happens).

------
seliopou
Coercion is not a form of polymorphism. In all the other forms, dispatch
depends on the type of a value. When there's coercion going on, be it explicit
or implicit, the same code is being executed regardless of the value being
coerced. The only code that one might say "changes" is any code that's
executed to perform the cast. But that change in casting is basically ad-hoc
polymorphism.

~~~
pkrumins
This paper [1] says coercion is a kind of ad-hoc polymorphism.

[1] "On Understanding Types, Data Abstraction, and Polymorphism"
<http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf>

------
ioquatix
Since we are talking about polymorphism, here are several blog posts I wrote
on this topic:

[http://www.oriontransfer.co.nz/blog/2009-05/what-is-
abstract...](http://www.oriontransfer.co.nz/blog/2009-05/what-is-abstraction)

[http://www.oriontransfer.co.nz/blog/2009-05/run-time-
polymor...](http://www.oriontransfer.co.nz/blog/2009-05/run-time-polymorphism)

[http://www.oriontransfer.co.nz/blog/2009-05/compile-time-
pol...](http://www.oriontransfer.co.nz/blog/2009-05/compile-time-polymorphism)

If you find it interesting that is great. I enjoyed this blog post.

------
Figs
This was also posted in Reddit, and there are some other comments over there,
apparently:

[http://www.reddit.com/r/programming/comments/cgckf/the_four_...](http://www.reddit.com/r/programming/comments/cgckf/the_four_polymorphisms_in_c/)

------
shasta
Where do macros fit into this taxonomy?

~~~
jpr
I would say "outside".

~~~
shasta
You want to offer a working definition of "polymorphism", then?

Macros certainly allow you to write code that's applied to differently typed
arguments.

~~~
zeugma
Indeed :

FOO.hxx:

TYPE FOO_TEMPLATE () {

    
    
      TYPE foo;
      /*...*/
      return foo;

}

Foo.h:

#DEFINE FOO_TEMPLATE foo_int

#DEFINE TYPE int

#include "Foo.hxx"

#DEFINE FOO_TEMPLATE foo_float

#DEFINE TYPE float

#include "Foo.hxx"

It's a kind of weird and ugly macro trick, bug it can be useful in C when
one's need polymorphism and performance (and cannot use C++ at all, which is a
far better solution).

[Edit:] I realize now it's not polymorphism like said in the article, because
the caller had to tell explicitly which foo_xxx to call. But it did provide
"polymorphic" code in Foo.hxx (so only one implementation, no repetition).
That said, a cast is also explicit.

