explicit function template qualification

explicit function template qualification

[Jason Merrill]

I just checked in a patch from Mark to implement explicit specification of
template parameters to function templates.  In other words,

  template<class T>
  T min (T a, T b) { return a<b?a:b; }

  main ()
  {
    return min<int>(5, 8.0);
  }

A couple of side effects that may bite you:

1) Mangling of template instantiations now depends on the template they
   came from; in particular, template instantiations are no longer mangled
   like a non-template function.

2) Guiding decls are no longer supported.  So code like

     struct A {
       friend int operator== (const A&, const A&);
       A (int) { }
     };

     template <class T> int
     operator== (const T&, const T&)
     {
       return 0;
     }

     main ()
     {
       A a (1);
       return a == 1;
     }

   will now fail with an undefined symbol, because the friend refers to a
   normal function, not a template instantiation.  The complex and iomanip
   classes in libstdc++, for instance, had to be changed.  If the friend
   really needs to be a friend, you can add <> after the declarator (so
   operator==<>, in this example) to make it refer to a template
   instantiation.  If you had the friend decl in a template for overloading
   purposes, you're out of luck; you'll need to define any forwarding
   functions.  This is the way the language works now, sorry.

Both of these side effects can be reverted with -fguiding-decls, but that
will cause mangling clashes in some cases of explicit qualification, and
should not be used with new code.

Thanks again, Mark!

Jason

Re: explicit function template qualification

[Mumit Khan]

Jason Merrill <jason@cygnus.com> writes:
> I just checked in a patch from Mark to implement explicit specification of
> template parameters to function templates.  
> 
> 2) Guiding decls are no longer supported.  So code like

Ouch! This unfortunately breaks lots of my code (easily fixable however) 
and a few others floating around the net (eg., octave breaks miserably).
But that's how the language works ...

Jason, I tried out your example with operator==<>:

    template <class T> int
    operator== (const T&, const T&)
    {
       return 0;
    }

    struct A {
      A (int) { }
      friend int operator==<> (const A&, const A&);
    };

    main ()
    {
      A a (1);
      return a == 1;	// << rhs doesn't match A(int)!
    }

And I get the following with egcs-970929 (haven't built the latest fsf
snapshot, so can't comment on that) on i386-linux-gnulibc1:

    % c++ -c tmpl3.cc
    tmpl3.cc: In function `int main()':
    tmpl3.cc:15: no match for `A & == int'

Looks like the user-defined conversions are ignored (A::A(int)). If I now
use the following, everything works out.

    return a == A(1);	// << force rhs match A(int)!

I'm hoping this is just a bug, and not by design. fyi, I've already
reported something similar for 970929 where the implicit conversions are
also botched (eg., ``complex<double> + 1'' doesn't work, but 
``complex<double> + 1.0'' works).

Regards,
Mumit -- khan@xraylith.wisc.edu
http://www.xraylith.wisc.edu/~khan/

Re: explicit function template qualification

[Mark Mitchell]

>>>>> "Mumit" == Mumit Khan <khan@xraylith.wisc.edu> writes:

    Mumit> Jason Merrill <jason@cygnus.com> writes:
    >> I just checked in a patch from Mark to implement explicit
    >> specification of template parameters to function templates.
    >> 
    >> 2) Guiding decls are no longer supported.  So code like

    Mumit> Ouch! This unfortunately breaks lots of my code (easily
    Mumit> fixable however) and a few others floating around the net
    Mumit> (eg., octave breaks miserably).  But that's how the
    Mumit> language works ...

    Mumit> Jason, I tried out your example with operator==<>:

    Mumit>     template <class T> int operator== (const T&, const T&)
    Mumit> { return 0; }

    Mumit>     struct A { A (int) { } friend int operator==<> (const
    Mumit> A&, const A&); };

    Mumit>     main () { A a (1); return a == 1; // << rhs doesn't
    Mumit> match A(int)!  }

    Mumit> And I get the following with egcs-970929 (haven't built the
    Mumit> latest fsf snapshot, so can't comment on that) on
    Mumit> i386-linux-gnulibc1:

    Mumit>     % c++ -c tmpl3.cc tmpl3.cc: In function `int main()':
    Mumit> tmpl3.cc:15: no match for `A & == int'

The language doesn't quite work the way that you expect.  The friend
declaration has no impact, so your code is just like:

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

struct A { A(int); }

main() 
{
  A a;
  a == 1;
}

which has never worked, to my knowledge.

    Mumit> Looks like the user-defined conversions are ignored
    Mumit> (A::A(int)). If I now use the following, everything works
    Mumit> out.

    Mumit>     return a == A(1); // << force rhs match A(int)!

    Mumit> I'm hoping this is just a bug, and not by design. fyi, I've
    Mumit> already reported something similar for 970929 where the
    Mumit> implicit conversions are also botched (eg.,
    Mumit> ``complex<double> + 1'' doesn't work, but ``complex<double>
    Mumit> + 1.0'' works).

    Mumit> Regards, Mumit -- khan@xraylith.wisc.edu
    Mumit> http://www.xraylith.wisc.edu/~khan/

-- 
Mark Mitchell		mmitchell@usa.net
Stanford University	http://www.stanford.edu