Boost logo

Boost :

From: helmut.zeisel_at_[hidden]
Date: 2001-07-26 00:00:12


--- In boost_at_y..., "Vesa Karvonen" <vesa.karvonen_at_h...> wrote:
> From: "Fernando Cacciola" <fcacciola_at_g...>
> > From: Jeremy Siek <jsiek_at_r...>
>
>
> > The range interface is a *very* powerful abstraction, much much
better than
> > the abstraction of an (encapsulated) container.
>
...
>
> > IMHO, the decision to shortcut from (c.begin(),c.end()) to (c)
should be
> > done consciously, not as the default practice; otherwise, a
program might
> > end up stuck in a design that cannot exploit the flexibility of
the range
> > abstraction.
>

>
> As related issue, it is possible to write functions that return an
object that
> has a container-like interface (has begin() and end()), but refers
to the
> elements of the container differently.

Do you mean something like

template<typename Iterator> struct range
{
  Iterator m_begin;
  Iterator m_end;
  range(Iterator begin, Iterator end): m_begin(begin), m_end(end) {}
  Iterator begin() const {return m_begin;}
  Iterator end() const {return m_end;}
};

template<typename Iterator> range<Iterator>
make_range(Iterator begin, Iterator end)
{
  return range<Iterator>(begin,end);
}

Then a container has a range interface,
and it is easy to construct a range interface from two iterators.

You might ending in writing

vector<int> v;
sort(v); // equivalent to sort(make_range(v.begin(),v.end()));

This is a bit like coding theory:
the frequent things are short, the less frequent things become longer.

Helmut


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