|
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