🚀 go-pugleaf

Distribution:
In article <MATT.95Aug16101930@physics2.Berkeley.EDU>,
Joe Buck <jbuck@Synopsys.COM> wrote:
>Distribution:
>maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
>>	The STL definitions were in fact quite wrong and
>>completely unnacceptable until overloading of function templates by
>>partial specialisation was introduced into the C++ language.
>>
>>	Now the definitions in STL remain wrong, but they are
>>only defaults which can be overriden.
>
>Not true; you can't change the return type (so that, for example,
>< on two arrays of reals returns an array of bools as in APL).

	Not true. You CAN.  The return type of a  
FUNCTION TEMPLATE is part of it's signature. (Unlike ordinary
functions!) 

	Lets be clear: we're talking about OVERLOADING and 
NOT specialisation.  You CAN'T specialise a function template 
as I understand it.

	The "specialisation" rules for functions are rules
of overload resolution. For example:

	template<class T, class U> void f(T,U); //#1
	template<class T, class U> int f(T,U);  //#2
	template<class T, class U> int f(U,T);  //#3
	template<class T> T f(T,T);             //#4
	f(1,1); // FINE! #4 
	f<float,int>(1, 1.0); // FINE! #3 is best match

These are distinct templates.  The first 3 would always
be ambiguous if used without explicit parameter binding.


	template<class T> class APLarray { .. };
	template<class T> APLarray<bool> 
	operator == (APLarray<T> const&, APLarray<T> const&);
	template<class T> APLarray<bool> 
	operator != (APLarray<T> const&, APLarray<T> const&);

is perfectly OK in the presence of the STL globals.
Note the container would NOT be STL compliant.

In fact:

	template<class T> T operator != (T const&,T const&);

is perfectly viable too because the return type is different. 
(Use would be ambiguous with STL != in reach as well, however)

[BTW: I was surprised at this resolution myself. I'd not have
made the return type part of the signature]

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
	Maxtal Pty Ltd,		    
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21 
        NSW 2037, AUSTRALIA	    Phone: 61-2-566-2189


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]