This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/12357] Fails to find overload (or maybe very bad error message)


PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12357


bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


------- Additional Comments From bangerth at dealii dot org  2003-09-23 00:03 -------
Well, I stand by my decision. Let me clarify this:

1. The ruling argument is Nathan's that default arguments are not used for
template type deduction. The normative statement is the standard is
14.8.2.4/17, which reads "A template type-parameter cannot be deduced
from the type of a function default argument." Why that is part of the
standard is certainly another matter, but the compiler should stick to it.

2. Above is the reason your type parameter C cannot be deduced. My
argument with operator< was wrong here.

3. Why the compiler doesn't warn you at the point of declaration that it
won't be able to deduce the type of C: because you may want to
specify the type of C explicitly. After all you may call Lss like in
   Lss<int,SomeType>(1,2);

4. Why the compiler doesn't say something when it can't match a function --
this actually considered a feature, not a bug. It's called SFINAE, or
substition failure is not an error. I won't go to length in explaining it,
but there are contexts where you want this to be so, i.e. you want the 
compiler to simply say nothing, because it may then use other paths to
make the program valid. That's certainly a well-known thing in C++ now and
not going to change.

Sorry for this rather dismissive statement, but I don't think we'd want
to change much about the above.

W.

BTW: The edg frontend produces basically the same errors as does gcc, no
further clues. Here's gcc 3.4:
g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c x.cc
x.cc:4: error: `operator<' not defined
x.cc:4: error: `operator<' not defined
x.cc: In function `int main()':
x.cc:13: error: no matching function for call to `Lss(int, int)'

and here's icc:
g/x> icc -c x.cc -Xc -ansi
x.cc(4): error: identifier "operator<" is undefined
  T Lss(T t1, T t2, C c = operator<) {
                          ^

x.cc(13): error: no instance of function template "Lss" matches the argument list
            argument types are: (int, int)
          Lss(1, 2);
          ^

compilation aborted for x.cc (code 2)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]