Boost logo

Boost :

From: Pavol Droba (droba_at_[hidden])
Date: 2003-11-19 07:23:45


On Wed, Nov 19, 2003 at 10:28:50PM +1100, Thorsten Ottosen wrote:
> "Brian McNamara" <lorgon_at_[hidden]> wrote in message
> news:20031119100449.GA16839_at_lennon.cc.gatech.edu...
>
> >
> > You may be interested to read
> >
> >
> http://groups.google.com/groups?q=brian+mcnamara+range+group:comp.lang.c%2B%2B.moderated+group:comp.lang.c%2B%2B.moderated&hl=en&lr=&ie=UTF-8&group=comp.lang.c%2B%2B.moderated&selm=8gm2i6%24gbt%241%40news-int.gatech.edu&rnum=5
> >
> > and other messages in-that-thread/of-mine from that time period.
>
> >From thead:
> -------------
> class interval { // a "single iterator" type (and a "concept")
> // conceptually this encapsulates a pair of iterators, first & last
> operator++ // advance (e.g. first++)
> operator* // get element (*first)
> bool isEnd() // the "first==last" concept, easier for
> InputIters
> stl_iterator first() // probably unnecessary
> stl_iterator last() // the lynchpin--see below
> }
>
> I find the idea of having Pavol's iterator_range augemented with
> operator*() and operator++ quite nice. isEnd() is equal to
> empty() which should be equal to operator bool-something();
>
> It might also be nice with a
> constructor that can limit the stored range in some way, eg.
>
> vector<int> v;
> iterator_range< ... > r( v ); // [begin(), end() )
> iterator_range< ... > r( v, 5, 5 ); // [begin() + 5, end() - 5)
>
> or something

I have already expressed my opions about range library to John in private mails.

I'm not in favor to extending iterator_range too much. If has sufficient interface already.

I like to idea of range_iterator. It seems to be interesting concept, but see no
reason to mix it with other concepts like container algorithms or range.

Usualy it is better to strip the problem to small pieces then to create one omnipotent class.

Given the fact, that there are already tools like container_traits, container alorithms,
iterator_range it is IMHO better to provide only the fuctionality that is missing and not
to try to reinvent the wheel.

Regards,

Pavol.


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