------- Comment #32 from gdr at integrable-solutions dot net 2006-05-01 18:59 ------- Subject: Re: hidden declarations klobber STL
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | ------- 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, Yes. | 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. I believe it makes sense to do so the extent we can -- we (e.g. *you*) did patch the library so that qualified call where OK, e.g. std::copy, where we did so only for implementation details. The use of operator, in this case is no different. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
