------- Comment #14 from pcarlini at suse dot de 2006-04-20 09:37 ------- (In reply to comment #12) > I don't think that the problem is in the STL. The STL can be as tricky as it > wants, including use of operator,(). It should not be possible for the actual > operator,()s I declared to hijack the STL the way that happened, because 1) my > declarations were out of scope for the STL code and 2) their signatures did > not > match the STL call site. This suggests a compiler bug to me, not an STL > mis-design.
Actually, I'm not at all sure, given: 1- our vector<>::iterator not being a built-in type; 2- ADL rules. 3- The nature of fill_n (templated on *both* _Size and _OutputIterator). Again, I'm not a language lawyer, but I think that, strictly speaking, the compiler may legally find and match your operator, I can certainly patch fill_n to avoid the operator, no big deal, my question is more general, whether, given our class-type vector<>::iterator, given the "unrestrictedness" of many <algorithm> templates, given current ADL rules, whether it makes sense for us to go that route trying piecewise to "improve" now the library, in the current C++03 framework. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
