From: David@f1.n100.z60.wlink.nl (David)
Newsgroups: comp.std.c++
Subject: Templates
Date: Fri, 09 Oct 1992 18:43:01 -0100

Organization: MAXTAL P/L C/- University Computing Centre, Sydney

I'm posting this for David Shang, whose News Server is down:

In article <23835@alice.att.com> ark@alice.att.com (Andrew Koenig)  
writes:
> In article <1992Oct7.150501.23910@cadsun.corp.mot.com>  
shang@corp.mot.com  

writes:
> 

> > I soppose f is defined as:
> 
> >      <class T[Foo]> void f(T t) { t.mem(0); };
> 
> > where keyword template is not necessary, because "f" can be  called
> > directly without any instantiation.
> 
> Then why not just write
> 
>       void f(T& t) { t.mem(0); }
> 
> ?  Why bother with templates at all if that's what you want?
> 

This is NOT the example I gave originally. I don't think template 
has a big deal for this case either. It proves that template is
unnecessary for this example, not that contrained parameter is 
unnecessary. Why bother with templates to play the trick of the 
name?? Why cann't we use virtual functions?

> > I suppose "mem" defined in Foo is a virtual function, otherwise  
"t.mem(0)" 
> > will always call the "mem" defined in Foo.
> 

> No; if it's virtual then you don't need templates.  The purpose of
> templates is to allow compile-time polymorphism between types that
> have members with the same names.
> 

I don't think so. If the purpose of template is to allow compile-time 
polymorphism between types that have members with the same name, why 
bother with templates? Just for run-time speed? No. Dynamic binding 
is not a significant overhead in C++.

Parameterization is used for a structure in which some component's 
type is unknown or patially known at the time the paramerterized 
feature is written. For example,

   class Vector < class MemberT, int size >
   {  MemberT members[size];
     public:
      MemberT & operator[] (int index) { return members[index]; };
      ...
   };

As MemberT is unknown to Vector, we SHOULD NOT assume any members  with 
some name defined in MemberT. If MemberT becomes partially known in a
derived Vector class, we should constrain it:

    class NumVector: public Vector < class MemberT[Number] >
    { public:
       thisclass& operator+ (thisclass & other)
       { for (int i=0; i<size; i++) members[i] += other[i];
         return *this;
       };
       ...
    };

where += may be a virtual operator defined in Number.

If somebody says that this can be achieved without parameterization, 
PLEASE GIVE me an example. The following example is what I can think 
about:

   class Vector
   {  int    size;     // unnecessary overhead in object code
      int    ele_size; // unnecessary overhead in object code
      void * members;  // unnecessary indirection
     public:
      void * operator[] ... // untyped output
   };
   class NumVector: public Vector
   { public:
      NumVector& operator+ (NumVector & other)
      {  for (i=...)
             ((Number*)members[i]) += ((Number*)other[i]);
             // unsafe downcast here!!
         ...
      };
   };

Remember the code I give? I don't think you'll like it:

   ((DDDD*)(((DDD*)(((DD*)(((D*)d)->dd)))->ddd)->dddd)
   ->func(((DDDD*)(((DDD*)(((DD*)(((D*)d)->dd)))->ddd)->dddd)->data);

> > Not necessarily. Constrained parameterized function is not a  template 
> > function. It does not necessarily act exactly like a template,  
just as a
> > template function does not necessarily act exactly like a macro 
> > definition.
> 

> If you're proposing yet another brand new language mechanism, you  had
> better describe it in detail.  It isn't enough to say `it's just  like
> templates except for type constraints' because that's just not  true.
> -- 

>                               --Andrew Koenig
>                                 ark@europa.att.com


I didn't say constrained parameterized class "is just like template 
except for type constrains". That's not true -- you are correct. A
complete description of constrained parameterized class is not a  
simple
work, however. At least it is not so simple that can be clarified in 
a few newsgroup posts.

David Shang


Reply-To: shang@corp.mot.com

In article <1992Oct8.035346.2860@ucc.su.OZ.AU>  
maxtal@extro.ucc.su.OZ.AU (John  

MAX Skaller) writes:
> 

>       We already have abstract classes that are precisely what
> you want. 


I don't think the current abstract classes can offer 

what I want.

> A generic class even with constraints CANNOT generate
> actual code until instantiated.

Not true. A language named Cluster does generate actual codes
for constrained parameterized classes and functions. Does Effeil?
I'm not sure. But it seems possible, thought its implementation
may not.

> But it CAN be type checked at compile time.
> 


Yes. But this is not the only purpose of a constrained parameterized 

class.

>       Restricting a generic parater to a Base class is pointless.
> It only allows you to generate actual code in precisely those
> cases where you didn't need a template in the first place.
>

Really? Read my response to article <23835@alice.att.com>
(ark@alice.att.com), and give me an example to prove that 

parameterization is not necessary for the example I gave.
 

David Shang


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------