[Patch] First bits of the algo merge

[Howard Hinnant]

On Dec 14, 2005, at 12:49 PM, chris jefferson wrote:

> 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...

Right.

> Like I said, I don't /think/ you'll fail any conformance tests with  
> this one.  But you may alienate a customer or two.

This should be considered an extension.  If we don't want to extend  
functionality in this way, that's cool too.  Just if we want to, this  
is how it might be done.

-Howard