"Daniel Walker" <daniel.j.walker@gmail.com> writes:
On 4/11/06, David Abrahams <dave@boost-consulting.com> wrote:
Thorsten Ottosen <thorsten.ottosen@dezide.com> writes:
cannot have overloads (in C++98) taking containers/ranges:
fn( Iterator first, Iterator last ) fn( Iterator first, Iterator last, Functor f ) fn( Range rng ) fn( Range rng, Functor f )
as the last overload is ambiguous. Concepts will allow this to be resolved as a Functor will not match the Iterator requirements :).
you can use enable_if on the latter and disable it the two types are the same.
Not if you happen to have a type that is both a valid range and a valid function object.
Yes, that's a corner case, but it's the corner of a large floating block of ice.
For this idiom, I use boost::iterator_range like so,
fn( Iterator first, Iterator last ) fn( Iterator first, Iterator last, Functor f ) fn( boost::iterator_range<Iterator> rng ) fn( boost::iterator_range<Iterator> rng, Functor f )
This is not generic. Now you can't pass other valid Ranges (e.g. std::vector<T>) as the first argument to fn.
This is basicly the same thing as section 18.3.1 of Stroustrup's The C++ Programing Language. When calling fn() from templates with parameterized range types, I do something like ...
template<typename ForwardRange> void some_other_function(const ForwardRange& x) { using namespace boost; function_requires< ForwardRangeConcept<ForwardRange> >(); // ... fn(make_iterator_range(x), f); }
The call to make_iterator_range() is a hassle.
Right.
And this is just a work-around for the specific iterator/functor/range overload resolution problem. I think in-language support for concepts could deffinitely clean up this code and make life easier.
Bigtime. -- Dave Abrahams Boost Consulting www.boost-consulting.com