[Review] Reminder: Boost.RangeEx review is going on
Dear Developers and Users, The review of Neil Groves' RangeEx library lasts until March 3, 2009. Please find the time to do a review if you are interested in this library. The discussion so far may be found here: http://archives.free.net.ph/message/20090220.122836.73bdbd04.en.html Below you will find a description of the library and information on how to write a review. best regards Thorsten, review manager What is it? +++++++++++ The library provide two very useful extensions to the range library 1. Range-based algorithms. E.g. boost::sort( rng ); which is a convenient wrapper of instead of std::sort( boost::begin(rng), boost::end(rng) ); But the new interface also allows for more expressive code because (on the fly) composition of algorithms suddenly is possible. 2. Range adaptors. E.g. std::vector<int> vec = ...; boost::copy( vec | boost::adaptors::reversed, std::ostream_iterator<int>( std::cout ) ); where the expression "vec | boost::adaptors::reversed" wraps the iterators of the range on the left in reverse iterators. The library provides a wide range (no pun intended) of Range adaptors, and they are a powerful way to create ranges on the fly and pass them to algorithms. Getting the library +++++++++++++++++++ The library may be downloaded from http://www.cs.aau.dk/~nesotto/boost/range_ex.zip or from the Boost vault under "Algorithms". The docs may be browsed online here http://www.cs.aau.dk/~nesotto/boost/libs/range/ Please note that the documentation is integrated with the current Range ilbrary. Therefore the relevant sections for the review is http://www.cs.aau.dk/~nesotto/boost/libs/range/doc/adaptors.html and http://www.cs.aau.dk/~nesotto/boost/libs/range/doc/algorithms.html The code may be browsed here: http://www.cs.aau.dk/~nesotto/boost/boost/range/ Notice the library is header only (exception: the adaptor tokenized() depends on Boost.Regex). Writing a review ++++++++++++++++ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager. Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick - reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Special considerations ++++++++++++++++++++++ Various RangeEx like libraries have been implemented in the past. You might want to compare with those libraries when you form your oppinion: 1. John Torjo's range lib http://rangelib.synesis.com.au/libs/boost-rangelib-20040913.zip http://torjo.com/rangelib/index.html 2. Adobe's ASL libraries include range-based algorithms: http://stlab.adobe.com/group__algorithm.html I'm looking forward to your review. best regards Thorsten, Review Manager
Hi, why do we need two overloading for the non mutating algorithms? I understand the issue for mutatong algorithms, but the parameter is not always const for non mutating ones? template<class ForwardRange> typename range_iterator<ForwardRange>::type adjacent_find(ForwardRange& rng); template<class ForwardRange> typename range_iterator<const ForwardRange>::type adjacent_find(const ForwardRange& rng); Vicente
AMDG vicente.botet wrote:
why do we need two overloading for the non mutating algorithms? I understand the issue for mutatong algorithms, but the parameter is not always const for non mutating ones?
template<class ForwardRange> typename range_iterator<ForwardRange>::type adjacent_find(ForwardRange& rng);
template<class ForwardRange> typename range_iterator<const ForwardRange>::type adjacent_find(const ForwardRange& rng);
For the same reason that we have const and non-const overloads of begin(), end(), operator[], etc. We may need mutating access through the result. In Christ, Steven Watanabe
----- Original Message ----- From: "Steven Watanabe" <watanabesj@gmail.com> To: <boost@lists.boost.org> Sent: Monday, March 02, 2009 4:32 PM Subject: Re: [boost] [Review] Reminder: Boost.RangeEx review is going on
AMDG
vicente.botet wrote:
why do we need two overloading for the non mutating algorithms? I understand the issue for mutatong algorithms, but the parameter is not always const for non mutating ones?
template<class ForwardRange> typename range_iterator<ForwardRange>::type adjacent_find(ForwardRange& rng);
template<class ForwardRange> typename range_iterator<const ForwardRange>::type adjacent_find(const ForwardRange& rng);
For the same reason that we have const and non-const overloads of begin(), end(), operator[], etc. We may need mutating access through the result.
Thanks Steven, I have not chooen the good example. Should we have two overloadings for count? template< class SinglePassRange, class Value > inline BOOST_DEDUCED_TYPENAME range_difference<SinglePassRange>::type count(SinglePassRange& rng, const Value& val) { boost::function_requires< SinglePassRangeConcept<SinglePassRange> >(); return std::count(boost::begin(rng), boost::end(rng), val); } /// \overload template< class SinglePassRange, class Value > inline BOOST_DEDUCED_TYPENAME range_difference<SinglePassRange const>::type count(const SinglePassRange& rng, const Value& val) { boost::function_requires< SinglePassRangeConcept<SinglePassRange> >(); return std::count(boost::begin(rng), boost::end(rng), val); } Vicente
vicente.botet wrote:
Should we have two overloadings for count?
Would it harm to have more than one overload ? In template programming symmetry is useful, when there are no special cases. If for_each, accumulate, and count need two overload, why make an exception for count. It may be hard to imagine equals operator which do not take constant operands. But in some cases, like maintaining legacy code or writing COM (component object model) code you just may have to give up const correctness and have most of veriables non-constant.
Neil, as I have already said excelent library. I was waiting for that on Boost for a long time already. I like the pipe operator '|' and I think that this can be generalized to other functors other than range adaptors. IMHO this is out of the scope of the Boost.Range library, or in oder words that Boost.Range can profit as other for a generic framework. I don't think the first release of Boost.Range should come with the operators interface and a deeper analisys about how to chain functors must be done in a separated library. I would like that all the range stuff resides in the range namespace waiting for a consensus on where to place common algorigthms, directly on boost, on boost::algorithm::, on boost;; .... I think that all the common algorithms (in namespace boost::) interface should allow a partial specialization. The library do not address this issue. The same name could be applied to ranges, fusion sequences, .... Free functions should not be included in the boost namespace if specializations are not considered, but this is only my opinion. If a function works only with a concept the library should use enable_if to avoid invalid instantations, but this could come later. I realy think that the abandoned ConceptTraits library should be included in Boost. Respect to the name of the adaptors I prefer the -_view than the -ed suffix, but I can live with both. It would be good to use the same names for the same thing (i.e. be coherent with other boost libraries as e.g. Boost.Fusion). Even if the user can implement the standard algorithms _if _copy and _n with the library, I consider that the library must provide them for ranges and let other combinations to the user.
- What is your evaluation of the design?
The library has a simple and clean design.
- What is your evaluation of the implementation?
I have no taken too much time to look in, but what I have see is well implemented. I have just a problem with the use of the concept check using the Boost.ConceptCheck, library. The compiler messages are not enoug expicit. For example: ../../../../../boost_1_38_0/boost/mpl/eval_if.hpp: In instantiation of `boost::mpl::eval_if_c< true, boost::range_const_iterator<A>, boost::range_mutable_iterator<const A> >': ../../../boost/range/iterator.hpp:63: instantiated from `boost::range_iterator<const A>' ../../../boost/range/difference_type.hpp:26: instantiated from `boost::range_difference<const A>' C:\cygwin\home\Vicente\boost\sandbox\interthreads\libs\interthreads\example\parallel_sort2.cpp:56: instantiated from here ../../../../../boost_1_38_0/boost/mpl/eval_if.hpp:60: error: no type named `type' in `struct boost::range_const_iterator<A>'
- What is your evaluation of the documentation?
Good enough. I would like to see an example for each one of the algorithms as it is done for the adaptors. I would like also to see how an adaptor and an algorithms are implemented. This will help to those wanting to propose others. Just a problem with links: the links form the header table of contents of the adaptors do not point to the expected section.
- What is your evaluation of the potential usefulness of the library?
Very useful, the range algorithms as the range adaptors.
- Did you try to use the library? With what compiler? Did you have any problems?
I have used the library with gcc-3.4.4 on cygwin. I haven't found any problem.
- How much effort did you put into your evaluation? A glance? A quick - reading? In-depth study?
4-5 hours.
- Are you knowledgeable about the problem domain?
Yes, I use this kind of lazy mechanism since a log time.
- Do you think the library should be accepted as a Boost library?
Yes, this library must be in Boost. I have no doubt. Good luck, Vicente
participants (4)
-
Alexander -
Steven Watanabe -
Thorsten Ottosen -
vicente.botet