Topic: template" keyword unnecessary


Author: h.b.furuseth@usit.uio.no (Hallvard B Furuseth)
Date: 1995/07/27
Raw View
In article <DC0FsM.FKJ@aisb.ed.ac.uk> andrewfg@dai.ed.ac.uk (Andrew Fitzgibbon) writes:
> One could try
>
> 1) class <T> find_next<T>(T);
> 2) class T find_next<T>(T);

Or simply remove "template" but otherwise keep the current syntax:

 <class T> class list { T *next; ... };
 <class T> T *find_last (T *);
--
Regards,

Hallvard





Author: s5vijen@portland.watson.ibm.com (Anil Vijendran)
Date: 1995/07/18
Raw View
There are problems with this approach. I read about it somewhere but I
forget where.

How'd you handle a function template which returns a pointer or
reference of its type parameter?

Assuming the syntax would be something like f<T>:

 T f<class T>
         {
           ...
  }

how would the parser know what T is, which T it binds to etc?

Also, D&E talks about this in p 342 first few lines.

>>>>> On Tue, 18 Jul 1995 12:55:35 GMT, andrewfg@dai.ed.ac.uk (Andrew
Fitzgibbon) said:

    Andrew> With all the palaver about how we hate new keywords, why was template
    Andrew> introduced?  The obvious alternative (decl matches use)

    Andrew>  class list<class T> {};

    Andrew> is as easy if not easier to parse, and to my mind, noticeably clearer to
    Andrew> read than the existing syntax.

    Andrew>  template <class T> class list {};

    Andrew> Similiarly
    Andrew>  bool max<class T>(T, T);
    Andrew> is an easy read.

    Andrew> A.

    Andrew> --
    Andrew> Andrew Fitzgibbon (Research Associate),                     andrewfg@ed.ac.uk
    Andrew> Artificial Intelligence, Edinburgh University.               +44 031 650 4504
    Andrew> <a href=http://www.dai.ed.ac.uk/staff/personal_pages/andrewfg> Home Page </a>
    Andrew>                          "Never say there is no way" -- me.
--
Peace.... +<:-)

Anil
akv@cacs.usl.edu
s5vijen@watson.ibm.com





Author: heliotis@xerox.com (Jim Heliotis)
Date: 1995/07/19
Raw View
In article or@aisb.ed.ac.uk, andrewfg@dai.ed.ac.uk (Andrew Fitzgibbon) writes:
>With all the palaver about how we hate new keywords, why was template
>introduced?  The obvious alternative (decl matches use)
>
> class list<class T> {};
>
>is as easy if not easier to parse, and to my mind, noticeably clearer to
>read than the existing syntax.
>
> template <class T> class list {};
>
>Similiarly
> bool max<class T>(T, T);
>is an easy read.

I completely sympathize with your feelings on this. I, too, wish that
nasty syntax were unnecessary. Here is the one reason I recall. How would
you handle

template < class T > T find_next( const T& );

? The problem is that the return type would show up before the compiler
knew it was a template:

T find_next< class T >( const T& );

I think some actually considered changing the C syntax to allow this!:

find_next< class T >( const t& ) returns T;



============================================================================
Jim Heliotis
Xerox Corporation                                  Voice Phone: 716-383-7383
Mail Stop: 803-01A                                  FAX Phone:  716-383-7395
435 W. Commercial St.                 Electronic Mail: JEH.ROCH803@Xerox.COM
East Rochester, NY 14445
============================================================================







Author: andrewfg@dai.ed.ac.uk (Andrew Fitzgibbon)
Date: 1995/07/20
Raw View
Jim Heliotis (heliotis@xerox.com) wrote:
< In article or@aisb.ed.ac.uk, andrewfg@dai.ed.ac.uk (Andrew Fitzgibbon) writes:
< > class list<class T> {};
< >is as easy if not easier to parse, and to my mind, noticeably clearer to
< >read than the existing syntax.
< > template <class T> class list {};

< I completely sympathize with your feelings on this. I, too, wish that
< nasty syntax were unnecessary. Here is the one reason I recall. How would
< you handle
< template < class T > T find_next( const T& );
< ? The problem is that the return type would show up before the compiler
< knew it was a template:

One could try

1) class <T> find_next<T>(T);
2) class T find_next<T>(T);

The code to parse (2) is similar to that used to parse anonymous structs.
This compiles in g++:
 class T f(class T);

OK, so the compiler still doesnt know it's a template until the function
name, but it does know it's a type, and thus the *parsing* ambiguities are
gone.

A.

--
Andrew Fitzgibbon (Research Associate),                     andrewfg@ed.ac.uk
Artificial Intelligence, Edinburgh University.               +44 031 650 4504
<a href=http://www.dai.ed.ac.uk/staff/personal_pages/andrewfg> Home Page </a>
                         "Never say there is no way" -- me.





Author: andrewfg@dai.ed.ac.uk (Andrew Fitzgibbon)
Date: 1995/07/18
Raw View
With all the palaver about how we hate new keywords, why was template
introduced?  The obvious alternative (decl matches use)

 class list<class T> {};

is as easy if not easier to parse, and to my mind, noticeably clearer to
read than the existing syntax.

 template <class T> class list {};

Similiarly
 bool max<class T>(T, T);
is an easy read.

A.

--
Andrew Fitzgibbon (Research Associate),                     andrewfg@ed.ac.uk
Artificial Intelligence, Edinburgh University.               +44 031 650 4504
<a href=http://www.dai.ed.ac.uk/staff/personal_pages/andrewfg> Home Page </a>
                         "Never say there is no way" -- me.





Author: herbs@interlog.com (Herb Sutter)
Date: 1995/07/18
Raw View
In article <DBwx8n.or@aisb.ed.ac.uk>,
   andrewfg@dai.ed.ac.uk (Andrew Fitzgibbon) wrote:
>With all the palaver about how we hate new keywords, why was template
>introduced?  The obvious alternative (decl matches use)
>
> class list<class T> {};
>
>is as easy if not easier to parse, and to my mind, noticeably clearer to
>read than the existing syntax.
>
> template <class T> class list {};
>
>Similiarly
> bool max<class T>(T, T);
>is an easy read.

FAQ: See D&E section 15.7.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Herb Sutter                 2228 Urwin, Ste 102         voice (416) 618-0184
Connected Object Solutions  Oakville ON Canada L6L 2T2    fax (905) 847-6019