Re: [boost] [Iterator][MultiIndex]iterator-specificpartition_point-relatedfunctions

Subject: Re: [boost] [Iterator][MultiIndex]iterator-specificpartition_point-relatedfunctions
From: David Abrahams (dave_at_[hidden])
Date: 2008-12-18 19:29:59

on Mon Dec 01 2008, Arno Schödl <aschoedl-AT-think-cell.com> wrote:

>>> Specifically for my application, you (as maintainer of
>>> boost.Iterator?) would have to change
>>> boost::transform_iterator/filter_iterator and Joaquin
>>> multi_index_container. If we can agree on that, I will change the code
>>> to CRTP.
>
>> I am willing to consider such changes.
>
> CRTP it is.
>
>>> How is that clever? It follows the same pattern as the one for a custom swap:
>>>
>>> using std::swap;
>>> CustomType tA, tB;
>>> swap( tA, tB );
>>>
>>> What do you propose instead?
>
>> I think if you want to call lower_bound in the most efficient way, it
>> should be possible to do so with qualification.  If the algorithm in
>> std:: isn't sufficiently "hookable," one should create a different one
>> that is.  The universe of names to be found by ADL should be limited to
>> fundamental operations like swap, since ADL reserves names "globally."
>
> Hmmm. I see it this way: std::lower_bound has well-defined semantics,
> and we don't change them. We merely provide an implementation for a
> particular iterator.

But we have no way to provide an implementation of std::lower_bound.  We
can only provide an implementation of lower_bound (unqualified).

> If that would be the end of the story, you would probably agree that
> ADL is the way to go and
>
> using std::lower_bound;
> lowerbound(customIt, customIt, ...); // unqualified
>
> is the right way to call the custom lower_bound.

Like I said, whether or not that is the right way to go IMO depends
largely on whether lower_bound should be considered a fundamental
operation akin to swap.

> Now it happens that for some class of iterators, lower_bound/... can
> be implemented on top of partition_point. 

Sorry, what is partition_point?  Oh, it appears to be essentially
std::lower_bound.

> I consider this an implementation detail, which you specify by
> deriving this iterator from a particular base class. I think the
> situation is really the same as in Boost.Operators that implements
> operator+ via operator+=.

Unless I'm missing something, I think, in that case, that the
fundamental operation is partition_point and not lower_bound or
upper_bound.  Can't the latter two be implemented in terms of
partition_point?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com