🚀 go-pugleaf

Matt Austern wrote:
> 
> In article <31741E6C.53CA@cs.tu-berlin.de> Roman Lechtchinsky
> <wolfro@cs.tu-berlin.de> writes:
> 
> > sorry for being curious but I'm only human... My question is: when declaring
> > templates, why isn't it required to declare what one expects of the
> > template's parameters? Let's create a template function:
> >
> > template<class T> bool equal( const T& t1, const T& t2 )
> > {
> >   return t1==t2;
> > }
> >
> > Now, personally I would prefer to write something like:
> >
> > template<class T { bool operator==( const T& t ) const; }> ...
> 
> Specifying something like this correctly turns out to be extremely
> difficult: it's very hard to come up with syntax that neither
> overspecifies nor underspecifies the constraints.  In this particular
> case, for example: do you really care whether operator== takes a const
> T&, as opposed to a T?  

Sure I do. If it takes a T the template needs access to the copy constructor. 
This is something one tends to forget about - the compiler wouldn't let you 
if you had to declare this fact.

> Does it matter that it returns bool, instead
> of something (like int) that is freely convertable to bool?  

It depends on what this something is and whether you really want it to be 
converted to bool or not ( in the case of operator== you almost certainly do; 
maybe it's a bad example ). No problem if it is really int. If it is a class 
which can be converted to bool or to int or even to a pointer then the 
programmer should at least know which conversions might occur. Usually 
templates are not documented that good.
As a matter of fact, my definition could accept an operator== with a 
different return type. When calling it the return value would be converted to 
bool prior to any other conversions which would give the programmer at least 
some control.

> Does it
> matter whether this is T::operator==(T), or ::operator==(T,T), or any
> of a dozen other minor variations?

Note that this problem occurs only with operators. Again, the two operators 
you mention have different semantics: the second one copies two objects 
whereas the first one copies only one. 

> 
> More realistic cases are even harder to deal with.  Consider, for
> example, the for_each algorithm from STL:
> template <class InputIterator, class Function>
> Function for_each(InputIterator first, InputIterator last, Function f) {
>     while (first != last) f(*first++);
>     return f;
> }
> 
> The constraints are as follows:
>   There must be either a built-in operator!=, or a global operator!=,
>     or a member function InputIterator::operator!=, such that applying
>     operator!= to two InputIterators is well-defined and yields something
>     that's convertable to bool.
>   Operators ++ and * are defined such that *InputIterator++ yields an
>     rvalue of some type.
>   An object of type Function has an operator() that takes an argument
>     of the type returned by *InputIterator++, or at least a type to
>     which the return value of *InputIterator++ can be converted.
>     The return value of operator() is unimportant.
> 
> Notice what's tricky here: the important constraints are relationships
> between different types, some of which (like the return value of
> InputIterator++, and the return value of *InputIterator++) aren't
> named as template parameters.  This rapidly becomes a problem in
> formal specification.

Yes, sure. I could try to design a class  which messes the whole thing up 
even though it provides everything the function needs. This rapidly becomes a 
problem in application development :-) Essentially, templates are macros. One 
can do a lot of things with macros. But should they be done? Maybe STL the 
design of STL would be clearer if everything had to be declared...

> 
> This issue is something that has been thought about, and there's some
> discussion of it in D&E.

Yes, there is ( I think so, at least; I don't remember who has my copy but 
its not me ). However, in many threads about templates I've read something 
like "now the semantics of templates are better understood". I'd like to hear 
what people think about them in the light of this new understanding.

Bye

Roman


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]