on Sat Dec 27 2008, Arno Schödl <aschoedl-AT-think-cell.com> wrote:
Furthermore, if you publish the type of the function object used, people can still customize all of those individual variants if they're crazy enough to want to do that.
I don't understand what you mean.
The customizer simply writes a partition_point overload where the function object type is specific, e.g. something like binder2nd<std::less<T>, T> (I forget the real signatures)
Ah, ok. We may want to turn the bind function objects into C++0x lambdas later. I am not sure you can overload on lambda types.
O.k., I am happy we finally have agreement:-) I will send out the new version. Do you want to include it into Boost.Iterator (my preference), or as a separate library?
I'm sorry, but what component(s) are you proposing should be included into Boost.Iterator? Not the default partition_point, boost::lower_bound, et. al.?
Yes, that was the idea, to have all tools to implement a new iterator in one place.
You *generally* don't need to customize partition_point in order to implement a new iterator.
If you don't like that, how do you want to do it? Separate library "partition_point" with
- algorithms.hpp for default partition_point and lower_bound et. al.,
and
- transform_iterator.hpp - ...
for the various partition_point overloads?
Something like that seems likely. I'm still having trouble understanding how you can implement a specialization for transform_iterator without knowing more than actually possible about the semantics of the transformation function.
Or only have the default implementation in a separate library and implement the partition_point overloads in Boost.Iterator/Boost.MultiIndexContainer's iterator-specific header files, such as transform_iterator.hpp?
I'm getting confused, sorry. -- Dave Abrahams BoostPro Computing http://www.boostpro.com