This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/12357] Fails to find overload (or maybe very bad error message)
- From: "bangerth at dealii dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 23 Sep 2003 00:03:14 -0000
- Subject: [Bug c++/12357] Fails to find overload (or maybe very bad error message)
- References: <20030921215241.12357.igodard@pacbell.net>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
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)