Subject: [boost] RangeEx review
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2009-03-10 10:51:22
Here is a quick review of RangeEx.
> - Do you think the library should be accepted as a Boost library?
Yes, assuming issues raised in the recent discussions are addressed, and
that people agree on the naming.
> - What is your evaluation of the design?
It is nice and pretty. Here are a few comments:
- I am unsure about the syntax of the unified return type system. It's
very practical, however, but not so pretty.
- Fusion of the function syntax and pipe syntax for adaptors would be
useful, so that both range | transformed(f) and transformed(range, f)
may be written.
- Relying on standard algorithms means that the functors have to provide
a result_type. I would like the functors to be automatically wrapped so
that boost::result_of can be used instead. I don't know if
Boost.Iterator needs it too.
- In the sandbox version, find(range) used to call range.find() if range
had a find member (the has_find meta-function had a poor implementation,
but that could have been solved). I don't know why this feature was
removed, but I personally liked that better.
- I would like to library to also provide lazy range generators,
potentially defining an infinite range recursively.
- Adaptors for type filtering within heterogeneous sequences (sequences
of "potentially smart" pointers, sequences of variants, sequences of
any...) would also be a plus.
It's basically a filter+transform at the same time.
I found such an adaptor primitive very practical when dealing with
trees, for example.
> - What is your evaluation of the implementation?
It seems good. It's mostly just forwarding things to standard algorithms
or Boost.Iterator for adaptors, nothing much to say.
> - What is your evaluation of the documentation?
Simple, but doesn't necessarily need to be more complicated.
> - What is your evaluation of the potential usefulness of the library?
Huge. I deal with sequences (or ranges) of objects everyday, and being
able to express operations directly on them would make my code simpler
> - Did you try to use the library? With what compiler? Did you have
I used an old version from the sandbox, with a few custom modifications,
less than a year ago to code some experimental proof-of-concept C++
wrapper over a hierarchical thread scheduler written in C (a component
which mapped trees of tasks to trees of processors) so as to see how it
could make the code more high-level.
This was done with GCC 4.2. I didn't have problems except making it work
with a lambda DSEL (I actually cheated and used typeof for return type
deduction everywhere at the time).
> - How much effort did you put into your evaluation? A glance? A quick
- reading? In-depth study?
I only quickly read the documentation and gave a glance at the version
under review; but I did study the sandbox version more in-depth.
> - Are you knowledgeable about the problem domain?
I know about ranges, iterators, functional programming, and lazy
sequences fairly well.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk