https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59508
--- Comment #7 from Jonathan Wakely ---
(In reply to Oleg Endo from comment #6)
> Right. If, then std::find should not invoke std::set::find (or
> std::map::find etc) but the library's internal function to search the rb
> tree.
If that internal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59508
--- Comment #6 from Oleg Endo ---
(In reply to Jonathan Wakely from comment #5)
> Users can specialize std::set::find to do something
> different, e.g. write to a file, and it must not do that if they call
> std::find.
>
> It's not a matter of wh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59508
--- Comment #5 from Jonathan Wakely ---
Users can specialize std::set::find to do something different,
e.g. write to a file, and it must not do that if they call std::find.
It's not a matter of whether the type is the library's iterator type or n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59508
--- Comment #4 from Oleg Endo ---
(In reply to Daniel Krügler from comment #3)
> (In reply to Oleg Endo from comment #2)
> > Could you please elaborate?
>
> My response was referring to the generic code that you provided, because
> that would als
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59508
--- Comment #3 from Daniel Krügler ---
(In reply to Oleg Endo from comment #2)
> Could you please elaborate?
My response was referring to the generic code that you provided, because that
would also be applied to user-provided specializations of l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59508
--- Comment #2 from Oleg Endo ---
(In reply to Daniel Krügler from comment #1)
> A conforming implementation cannot do that, unless the difference weren't
> observable by the user (modulo the performance difference), i.e. it would
> only be possib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59508
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
