Re: Polymorphism and inheritance
On Sep 9, 5:09 pm, tony_in_da...@yahoo.co.uk wrote:
On Sep 9, 4:56 pm, James Kanze <james.ka...@gmail.com> wrote:
[...]
For example...
a = x + y
...is valid code whether a, x and y are ints or doubles. This
relies on compile-time polymorphism provided by the compiler
itself. A good test for polymorphic language features is can
they be used to write...
is_less_than(x, y)
...where x and y are not both locked in to one specific type.
C++ mechanisms that allow this include:
- preprocessor macros
- overloading
- virtual dispatch
- templates
And by providing different implementations in different object
files, the user choosing at link time. (And what about
providing different implementations in dynamically linked object
files:-)? Runtime polymorphism? Certainly not what most people
would understand by it.)
These don't resemble the mechanisms I describe in that they
not automated. You may think the linker is automated, but not
for performing a polymorphic task. Switching between
implementations for the same type differs from generating or
switching between code based on data types.
How is this really any different from invoking a virtual
function through a pointer to base? The actual type referred to
in the source code is the same; the function called has a
different implementation. In many ways, this is closer to
traditional polymorphism than are templates. Traditional
polymorphism is common interface, different implementation,
where as templates are different interface, common
implementation.
If the app side has precompiled code for a specific type, and
it's calling a library function, they'll typically be matched
on the type-encoded mangled name. Any polymorphism involved
may have happened earlier during the resolution to a mangled
name. Even for extern "C" functions, the linker doesn't
choose based on type... unless you imagine someone manually
linking calls ala `extern "C" fn(void*); fn(&X());' to an
implementation customised for type X. That would be perverse,
and as you say, not what most people understand as
polymorphism.
What most people understand by polymorphism, most of the time,
is that calls through a type base resolve to different
implementations.
All these mechanisms are polymorphic.
Still, the test isn't perfect: you could write an
is_less_than(x, y) implementation using memcmp() and sizeof
that produced results that were meaningful only in the sense
that they were consistent (at least for types without
structure padding), and therefore useful for sorting/
searching, but it wouldn't actually be polymorphic because
there hasn't been type-driven code generation. That's more in
line with C- style generic programming ala the bsearch() or
qsort() functions common on UNIX platforms.
The point about polymorphism is that the implementation isn't
fixed by the function call itself.
A function pointer allows that, but is in no way polymorphic.
Sure it is. At the lowest level, it's the only mechanism
available for runtime polymorphism, and when you implement a
polymorphic system in C, it's what you use. (It's also what the
compiler uses to implement polymorphism in C++.)
It's the ability to vary the types and get custom behaviour
that defines polymorphism.
It's the ability to get different behavior from the same
source code function call which defined polymorphism.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34