Re: [boost] range_ex: status?

From: Rogier van Dalen (rogiervd_at_[hidden])
Date: 2008-07-30 19:14:35

On Sun, Jun 29, 2008 at 19:43, Neil Groves <neilgroves_at_[hidden]>wrote:

> An update to the Boost.RangeEx proposal has been uploaded to the vault.
> Please take note that Eric has moved his older version of Boost.RangeEx
> (upon which much of the later work is based). I have therefore placed the
> new version in the Algorithms folder of the vault and removed the version in
> the root.
>
> The updated code is to allow make_***_range as requested by a few users of
> RangeEx.
>
> Feedback is welcomed.
>

Dear Neil,

I've got a couple of questions. They might just highlight my ignorance. I'm
sorry if I have missed available documentation and would be happy to be
pointed to it where I have.

What's the good thing about output iterators? I always regarded them as a
clumsy way of returning a range. For example, shouldn't generate_n() just
return a lazy range?

If I understand correctly, the pipe operator is the main modus operandi.
Why? "range | filtered(pred)" does not look as familiar to C++ readers as
"filter(range, predicate)". The functional form also allows for operations
on two ranges, like "merge(range1, range2)". I have found this useful in the
past. (I would be happy to contribute an implementation of this "merge" that
I have lying around.)

If operator| is so cute it needs to be provided (which is a valid argument),
is it possible to turn it into something more general? I can now get an
iterator to the last element of a vector v with "prior(end(v))". Why not "v
| end | prior"?

Cheers,
Rogier