No subject

of thinking about problems.  The downside is that
virtual functions introduce a runtime overhead.  If
these functions need to be called in tight loops,
then this becomes a serious cost.  I'm not sure
exactly how significant this cost is, but from what
people have written on this list, it sounds like
virtual functions are a no-no where speed is an 
issue.

This is where generic programming comes in.  STL 
avoids virtual functions and uses template 
mechanisms to do things instead.  Things which
have to be done at runtime using traditional OO
approaches, are done at compile time.

I'm still trying to work out how generic programming
can be used as a paradigm instead of OO inheritance.
I'm still a bit unsure about it.

My guess is that it works as follows.

Instead of having a base class, have a template
parameter which represents (conceptually) the same 
thing.  I think STL talks about this as a "concept".
The abstract "concept", not defined in the code
anywhere --- it's just defined on paper, or in ones
head or something --- says that any "instance" 
(STL calls it a "model") of this concept has to have
certain functionality.  Eg perhaps it needs to have
"operator()" and "operator=" defined.  Perhaps it
requires a type "iterator" associated with it.  Perhaps
it needs to have a function "size()".  Our concept
specifies all these kind of things.  Using the OO 
inheritance approach, instead of this "concept",
we would have a base class with "operator()", "operator="
and "size()" defined as pure virtual functions.

With OO, you would then form a derived class, inheriting
the base class and implementing all the functions.  Whereas
with generic programming, you would simply implement a class
satisfying all the requirements of the "concept".  In a
sense you are inheriting from the "concept" instead of
from a base class.  But because the "concept" is in ones
head instead of actually part of the code, this pseudo
inheritance can't actually be seen in the code.

Using the OO approach you can write algorithms which
take a pointer to the base class as an argument.  You
can then make use of base class functionality to
implement an algorithm which will apply to _any_
class inherited from the base class.  This gives
the algorithm a "generic" quality.

Using the generic programming approach you write
algorithms which take a template parameter as an
argument.  By assuming this parameter is a model
of our "concept", we can implement an algorithm
which will apply to _any_ class "inherited" from
our "concept".  We thereby get a generic algorithm.
Ie, we get the same result as with the OO approach,
except without the runtime overhead.

The downside is that with generic programming it
would seem that the compiler can't do error checking
nearly as well.

So in conclusion, it seems to me that you can use
either OO inheritance, or generic programming, to do
similar things.  The former is "nicer" in that the
base class functionality appears in the code.  The
latter produces faster runtimes.

Am I thinking about these ideas correctly?  Or are there
issues I am missing?

Thanks,

Mark.