Path: utzoo!attcan!uunet!husc6!mailrus!cornell!uw-beaver!uw-june!david
From: david@june.cs.washington.edu (David Callahan)
Newsgroups: comp.lang.c++
Subject: Re: Generic functions -- a step toward polymorphism
Message-ID: <6416@june.cs.washington.edu>
Date: 14 Nov 88 06:00:39 GMT
References: <6403@june.cs.washington.edu> <5031@polya.Stanford.EDU>
Reply-To: david@uw-june.UUCP (David Callahan)
Organization: U of Washington, Computer Science, Seattle
Lines: 74


In article <5031@polya.Stanford.EDU> shap@polya.Stanford.EDU (Jonathan S. Shapiro) writes:
;>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.  

Perhaps my use of "polymorphic" was imprecise, that is why I gave
a definition in the article. My intent was to characterize the
difference between "list<T>" which can be implemented once
for all T and "vector<T>" which can not because of the internal
use of type attributes. If you would prefer different terms,
please define them and we can use them. Based on this characterization,
I wanted to provide language support for "generic" classes that
worked with the strongly-typed nature of C++. By this I mean
that the programmer must make assumptions about the type
parameter explicit and the compiler enforces these assumptions both
in the class and at points of use. Beyond that, I outlined how a 
smart compiler could provide a "polymorphic" implementation of 
general parameterized class specified with a "template".

; ...
; Given a class ... :
;
	[ parameterized stack<T> class, deleted ]
;
; 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.

Simplicity must also be in the eye of the beholder. Won't this approach
have complexity exponential in the number of needed types? What if not
all types are known? My suggestion was to examine the text and have the 
compiler extend the interface specification and, at the point of use,
have the compiler added extra parameters to satisfy that specification.
A compile-time type fault would occur if the compiler could not satisfy
the specification.

; 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.

Won't they also need a pointer to the "initialization from a reference"
constructor for T (typed: T (T&)), if one exists?

; 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.

The point of the "generic" class was to make this operation easy
for the current generation of separate-compilation-is-god compilers.

; 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.

I agree mostly, I'm not sure how "sophisticated" the tools really
need to be to be sufficient.

; Jon Shapiro

David Callahan,  Tera Computer Co.   Seattle, WA.