Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2006-04-15 09:29:17


"Daniel Walker" <daniel.j.walker_at_[hidden]> writes:

> On 4/11/06, David Abrahams <dave_at_[hidden]> wrote:
>> Thorsten Ottosen <thorsten.ottosen_at_[hidden]> 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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk