Boost logo

Boost :

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

> 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

Dave Abrahams
BoostPro Computing

Boost list run by bdawes at, gregod at, cpdaniel at, john at