This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] First bits of the algo merge


Howard Hinnant wrote:
> On Dec 14, 2005, at 12:01 PM, Howard Hinnant wrote:
>
>> I don't get it either.  I just noticed my bug too. Sorry for the
>> noise.  Back to work on the test...
>
> Ok, I think I've got it this time.  I had forgotten how subtle the
> breakage was.  I originally stumbled over this only because of a use
> case with a proxy iterator in a far more complicated situation. 
> Modified (and hopefully debugged) test case below.  The actual use
> case involved some implicit conversions (never a good thing) and I
> hope I've recreated enough of that context below.  In main I call
> equal two times:  Once with pointers, and once with the pointers
> wrapped in the proxy iterators.  METHOD A allows the former but not
> the latter.  METHOD B allows both.  Thanks in advance for your
> patience with this.
>
While making this work could very well be a reasonable goal, I notice
that if I replace the calls to equal with std::equal, defined in the
obvious way:

template<typename _InputIterator1, typename _InputIterator2>
    inline bool
    equal(_InputIterator1 __first1, _InputIterator1 __last1,
          _InputIterator2 __first2)
    {
      for (; __first1 != __last1; ++__first1, ++__first2)
        if (!(*__first1 == *__first2))
          return false;
      return true;
    }

Then this proxy iterator doesn't work, so we aren't breaking anything
that worked before...

Chris


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]