[LC++]Generic programming vs OO inheritance

Dan hursh hursh at sparc.isl.net
Wed Aug 15 07:39:13 UTC 2001


Mark,

	Just to play devil advocate, I'm going to diagree with you're
statement that "you can use either OO inheritance, or generic programming,
to do similar things" if you mean they are functionally interchangable.  I
think I'll also disagree with the statement "that with generic programming
it would seem that the compiler can't do error checking nearly as well."

	I'll start with the second statement first.  The compiler does all
of the error checking possible with generic programming because it can.
(Unless of course you have a delinquent compiler.)  The error messages are
usually as friendly as we might like, but all of they check are done and
done at compile time.  With OO inheritance, some checks cannot be made
until runtime.  The compiler can't be certain what you are going to point
a base pointer at or at least if it can be certain, then you didn't need
inheritance in the first place.  

	As far as the functional equivalence of generic programming and OO
inheritance, I don't think you can get the runtime behavior of OO
inheritance with gernerics without also use base-classes or implementing
you're own vtable-like structures.  I also wouldn't say that single
inheritance inside a tight loop isn't a bad thing if done right.  It
wouldn't be any different than useing a vtable.  Let the compiler do the
work for you.
	Assuming you don't need the runtime behavior though, they both can
get you the same functionality with different trade offs.

Dan

On Tue, 14 Aug 2001, Mark Phillips wrote:

> The object oriented way of doing things seems to be:
> 
> define a base class with pure virtual functions in it, and
> then define various inherited versions of this base class
> which implement the functionality of the base class in
> various different ways.
> 
> >From a theoretical point of view, this is a nice way 
> 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.
> _______________________________________________
> This is the Linux C++ Programming List
> : http://lists.linux.org.au/listinfo/tuxcpprogramming List
> 




More information about the tuxCPProgramming mailing list