------- Comment #28 from igodard at pacbell dot net 2006-04-21 04:07 -------
Wolfgang: the whitspace paper is wonderful! Actually, Bjorne explains why
operator,() was overloadable in the Rationale.
I still think that there is a problem here. If you try to overload other
built-in operators in a way that intercepts the normal meaning you get:
"foo1.cc:2: error: 'int operator+(int, int)' must have an argument of class or
enumerated type", so maybe the compiler should have flagged my declarations.
But I think that the actual error is that *in my actual code* every one of my
operator,() declarations had a local class as one or the other or both
argument.
However, the intercepted usage was (int&, <some iterator class>&). Consequently
the usage should have failed to identify my declarations and so should not have
intercepted.
Note that #18 simplifies all the arguments to "int", but that was not the
original case. If you change #18 to what actually happened:
#include <iostream>
namespace mine1
{
template<typename U>
struct mini_iter
{
mini_iter(U* p)
: _M_current(p) { }
U&
operator*() const
{ return *_M_current; }
mini_iter&
operator++()
{
++_M_current;
return *this;
}
private:
U* _M_current;
};
}
namespace mine2
{
template<typename _OutputIterator, typename _Size, typename _Tp>
_OutputIterator
fill_n(_OutputIterator __first, _Size __n, const _Tp& __value)
{
for (; __n > 0; --__n, ++__first)
*__first = __value;
return __first;
}
template<typename W>
void f(W* p) { fill_n(mine1::mini_iter<W>(p), 1, *p); }
}
struct bar{ int i;};
template<typename T>
T operator,(bar i, T t) { std::cerr << "interceptor\n"; return i; }
int main()
{
bar arr[1];
mine2::f(arr);
}
then the declaration does *not* intercept the STL, i.e. it does not fail. Yet i
my actual (more complicated) case it still did.
So we have a test case (#18) that shows the problem but is correct behavior; a
test case (this one) that doesn't fail; and my original code that looks like
the
second but fails like the first, but which I cannot provide to you.
I think there's a bug here, but I agree that we don't have enough to
demonstrate
its existance much less fix it. So let's close the ticket and hope somebody
else
reports it (if bug it is) in something that is small enoughh to manage.
Thanks for your help and the useful discussion.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
