From 2032110368839578732
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 109fba,109af18a94b8a35c
X-Google-Attributes: gid109fba,public
X-Google-Thread: f78e5,e5cae9ffbf1dd57e
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1992-10-07 07:39:20 PST
Xref: sparky comp.lang.c++:14680 comp.std.c++:1340
Newsgroups: comp.lang.c++,comp.std.c++
Path: sparky!uunet!ftpbox!motsrd!news
From: shang@corp.mot.com (David (Lujun) Shang)
Subject: Re: The concept of templates considered ill designed
Message-ID: <1992Oct7.155329.24107@cadsun.corp.mot.com>
Sender: news@cadsun.corp.mot.com
Reply-To: shang@corp.mot.com
Organization: Motorola, Inc., Software Research and Development, Rolling Meadows, IL. 60008
References: <1992Oct6.174129.10404@genghis.borland.com>
Date: Wed, 7 Oct 92 15:53:29 GMT
Lines: 61

In article <1992Oct6.174129.10404@genghis.borland.com> pete@genghis.borland.com  
(Pete Becker) writes:
> 	I seem to have not made myself clear.  What I was responding to was
> the claim that constrained parameters ALLOW THE TEMPLATE DEFINITION TO BE
> COMPILED INDEPENDENTLY OF ANY PARTICULAR INSTANTIATION.  While that's
> certainly true, it offers very little beyond what's currently available
> without using templates, precisely because the compiler knows nothing about
> the actual types of the template parameters.

I'm afraid I misunderstand what you claimed here. I can't understand 
this statement: "it offers very little beyond what's currently available
without using templates, precisely because the compiler knows nothing 
aboutthe actual types of the template parameters", would you offer an 
example? I refer "it" in your statement to a constrained parameterized 
class (template). If the class parameter is constrained, the compiler 
should know a partial interface of the parameter, and all the usage of 
the parameter should obey the protocol described in the partial interface. 
If you need to know the further detail about the interface, you can 
re-constrain (narrow) the parameter in the derived classes. That is the 
specialization, which I view a mechanism as useful as inheritance.

Constrained parameterized classes offer much more than separate 
compilation. I just list a few more points here:

1. It supports specialization and covariant specification;
2. It supports polymorphism (dynamic binding) based on parameterization;
3. It supports more precise interface specification (type dependency);
4. It supports code reuse not only at the source level, but also at the 
   machine code level.

> 	If you want constrained templates AND independent compilation of
> template definitions, you've already got it.  But don't call it a template.
> Call it a forwarding class.

Exactly. See, I call it a constrained parameterized class and never 
call it a template. In fact, a constrained parameterized class IS a 
class, it can be used anywhere as an abstract class is used. Therefore, 
it is NOT a template. For exmaple:

  class < class MemberT[GroupMember] > Group {...};

You can use Group to declare a pointer or a function argument:

  Group * group;
  group = new Group <class MemberT=SomeMemberType> (...);

or,

  void foo (Group & group);

You cannot use template this way.

The same case with constrained parameterized function:

  <Group GT> GT.MemberT select_one (const GT & group);

and "select_one" can be called directly: "select_one(aDogGroup)" will return a  
dog; "select_one(aCatGroup)" will return a cat.

David Shang