--- Comment #7 from Zarathustra at gentlemansclub dot de 2007-05-17 13:27
---
According to my current understanding, the compiler is right not to accept the
given example code:
Name resolution at the point of instantiation does only work for dependent
names.
Given a expression which lo
--- Comment #6 from Zarathustra at gentlemansclub dot de 2007-03-09 12:35
---
(In reply to comment #5)
> So, the way I read this is that gcc3.3 and icc9.0 agree that the call is
> ambiguous. I must admit that I don't know whether this is the correct
> behavior.
Also the SunCC yields the
--- Comment #5 from bangerth at dealii dot org 2007-03-09 04:14 ---
Here's a reduced code:
-
struct cons_end {};
template struct cons {
U elem;
V tail;
};
template
void foo(U elem, V tail)
{
foo(tail.elem,tail.tail);
}
template
void foo(U elem, cons_end tail)
--- Comment #4 from Zarathustra at gentlemansclub dot de 2007-02-21 10:16
---
Now the code was also compiled with 4.3.0 and produced the same error message.
I can make the actual failure more specific: The following code compiles fine:
template class TOperator,typename TElement>
void
--- Comment #3 from Zarathustra at gentlemansclub dot de 2007-02-21 07:44
---
The same problem appears with gcc 4.1.2 20061115 (prerelease) (SUSE Linux)
--
Zarathustra at gentlemansclub dot de changed:
What|Removed |Added
-
--- Comment #2 from Zarathustra at gentlemansclub dot de 2007-02-16 16:35
---
I know the rules for template function name lookup are complicated, and I do
not claim that I understand them completely. But I am pretty sure that the
order of the definitions should not matter. There is a pa
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-16 15:47 ---
// now the order changed and the compiler complains!
I think GCC 4.1.x and above are doing the correct behavior with respect of the
C++ standard. The C++ standard has specific rules about namelookup in
templates wh
