Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!purdue!decwrl!labrea!polya!shap
From: shap@polya.Stanford.EDU (Jonathan S. Shapiro)
Newsgroups: comp.lang.c++
Subject: Re: Generic functions -- a step toward polymorphism
Message-ID: <5031@polya.Stanford.EDU>
Date: 13 Nov 88 18:09:15 GMT
References: <6403@june.cs.washington.edu>
Reply-To: shap@polya.Stanford.EDU (Jonathan S. Shapiro)
Organization: Stanford University
Lines: 50

In article <6403@june.cs.washington.edu> david@uw-june.UUCP (David Callahan) writes:
>
>So, the "list<T>" class is generic but the "vector<T>" 
>class is polymorphic.

Uh, sorry, but it isn't.  The fact that the member types have
supertypes simply means that you are confining yourself to the
supertype. While that is in some very weak sense polymorphic, in that
anything derived from the same supertype has the same implementation,
it isn't fully polymorphic.  The point of parameterized types is to be
able to build truly generic objects.  Further, the current C++
language can already do what you suggest.

The real issue with C++ parameterized types will be proliferation of
copies of the same code [as you suggest] and the library management
involved in the proliferation.

With regard to the proliferation of copies problem, there is a simpler
solution than the one you propose.  Given a class (forgive me the
syntax, it has been some time since I read the paper):

	class Stack <T> {
		T *box;
	public:
		T& operator<<(T&);
		T& operator>>();
		...
	} ;

The issue is can we show that for some set of needed types T the
implementations of the functions are the same.  The simplest way to
determine this is to generate the functions for both cases and see if
they are the same code modulo name substitution.  This could be done
in the code tree easily.

In this case, if the idea is to resize Stack::box each time, then both
functions would need to know sizeof(T), so they are not equivalent.
This could be eliminated by adding a private variable size and filling
it in in the constructor, which would make the constructor type
dependent and the other function implementations type independent.
This optimization might even be done (or at least suggested)
automatically.

The harder problem is making it work across object files.  Essentially
the problem here is that an object file is an inappropriate scoping
constraint with respect to this issue.  Unfortunately, to do the
problem right implies some fairly sophisticated project management and
compilation tools.

Jon Shapiro