------- Comment #8 from bangerth at dealii dot org 2006-04-20 04:13 -------
Thinking about it some more, I can come up with something. Take this
code here:
---------------------
class specReg{};
template<typename T>
int operator,(int i, T t) { abort(); return i; }
#include <vector>
int main()
{
std::vector<int> v;
v.resize(1);
return 0;
}
----------------------
When compiled, I indeed get a reference to the operator, :
g/d> c++ -c x.cc
g/d> nm -C x.o | grep operator,
00000000 W int operator,<__gnu_cxx::__normal_iterator<int*, std::vector<int,
std::allocator<int> > > >(int, __gnu_cxx::__normal_iterator<int*,
std::vector<int, std::allocator<int> > >)
I guess it is a question to the libstdc++ people if this is what they want.
By tracing the abort() in the debugger, I can see where it comes from, namely
from std::fill_n().
I think this place is harmless: we're in a for-loop and the comma-separated
expressions return something that is unused. Since both expressions used
as arguments are evaluated completely before the call, nothing bad can happen.
The only place I can possibly conceive it matters is in something like this:
a = (b,c);
and with a definition of operator, (taken from your code) that is admittedly
pretty much asking for trouble:
template<typename T>
hide::inv operator,(specReg r, T t) { return t, r(); }
With such a definition, you make sure that after the assignment a==c, not
a==b. I think you're already pretty much shooting yourself in the foot with
defining an operator, that takes a template argument, and I must admit I have
very little sympathy for then even exchanging the values.
That said: Why do you think this is a bug? In the short example I posted,
why should ::operator, not be called?
W.
--
bangerth at dealii dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Component|c++ |libstdc++
Resolution|WORKSFORME |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
