On Sun, Jun 29, 2008 at 19:43, Neil Groves <neilgroves@googlemail.com>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