Re: [boost] Report from Berlin C++ Standards Committee meeting

From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2006-04-14 14:18:19

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

Daniel Walker