[Bug libstdc++/26974] hidden declarations klobber STL

[gdr at integrable-solutions dot net]

------- 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" <gcc-bugzilla@gcc.gnu.org> 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