- Boost - lists.boost.org

[Review:Algorithms] My review
by Phil Endecott 03 Oct '11

03 Oct '11

Here is my review of the proposed Boost.Algorithm library. A problem with Boost in the past has been that the contributions have primarily been larger projects, while smaller things have not been submitted despite their potential usefulness because of the effort required to prepare and review them (real or perceived). I therefore very much welcome the idea of a library to which smaller contributions can be submitted - though we have yet to find out how such submissions will be processed, and perhaps some discussion of this would be helpful now. (I have an implementation of an edit distance / edit script "diff" algorithm that could probably be contributed.) Regarding the particular algorithms initially included: Search algorithms: These are certainly worth having and the implementations look satisfactory. Jim Xochellis has made some comments about relaxing the iterator requirements and this would be worth doing if possible. Reducing the size of the tables by storing uint8_t for short patterns (especially on 64-bit systems where 7/8 of the space is currently wasted) might be worthwhile, though it could conflict with the idea of relaxing the iterators. Perhaps something can be done with the traits class to make it easier for the user to tweak this, e.g. passing the skip-distance type as a defaulted template parameter to the traits class. Documentation needs to be improved as previously discussed, especially to guide the user to select the correct algorithm. Other algorithms i.e. Ordering & clamping: I have come to the conclusion that these algorithms are too trivial to be included in Boost. Anyone who wants one of these functions can easily implement their own in a "personal utility library" or similar; they are trivial to code and there are no subtle issues or portability problems. The difficulty with putting them in Boost is that there are different possibilities for naming and aspects of the behaviour and there is no one version that will suit everyone - for example, I would not want to use a version of clamp that is three times slower than my preferred implementation. Furthermore, the amount of discussion of a proposal seems to be in inverse proportion to its complexity! To avoid getting bogged down in endless discussions of trivia we should set a lower bound on the complexity of submissions, and these functions are below that threshold. > * What is your evaluation of the design? Straightforward. > * What is your evaluation of the implementation? Satisfactory. > * What is your evaluation of the documentation? Needs some work, but I'm confident this will happen. > * What is your evaluation of the potential usefulness of the library? Search algorithms useful. Other stuff not sufficiently useful. > * Did you try to use the library? With what compiler? Did > you have any problems? I did some simple tests and benchmarks with gcc on ARM Linux. I do recall some "unused argument" warnings that could be suppressed by removing or commenting the arg name. > * How much effort did you put into your evaluation? A glance? > A quick reading? In-depth study? I've read all of the docs and much of the code, written some test / benchmark programs, and taken part in discussions. > * Are you knowledgeable about the problem domain? Not especially. In summary, my opinion is that the library should be accepted in part. Regards, Phil.

2 1

[Review:Algorithms] Boost.Algorithms Review
by Stewart, Robert 02 Oct '11

02 Oct '11

Boost.Algorithms should be accepted into Boost. Many issues have been raised during the review and during the pre-review using Code Collaborator. I have confidence that Marshall will carefully weigh all of the ideas and concerns that have been raised and apply those that are sensible and appropriate. __________ Design I have a problem with the physical design. all.hpp is not the file I'd expect to find any_of or none_of. I'd prefer to see them moved to any.hpp and none.hpp. I realize that none_of must test all elements in a range in the case when no element matches the predicate, but that doesn't make me think of all.hpp as the place to find it. I think "is_ordered_until" is a better name than "is_ordered" for the reasons previously elucidated. As to your dislike of "is_ordered_until", just read it as "the range is ordered until the element referenced by the return value". As there may well be other search algorithms than those you've provided thus far, I think each should be in a separate header and documented separately. Otherwise, search.hpp may grow to be ridiculously large. __________ Implementation I find the naming of your formal parameters to be inconsistent: first, last, p, lo, hi, val, and range. A more consistent set of names would be first, last, predicate, low, high, value, and range. I'd even accept "pred" in that list. Likewise, the template parameter names are inconsistent: InputIterator, Predicate, R, V, Pred, FI, patIter, and corpusIter. A more consistent set of names would be InputIterator, Predicate, Range, Value, ForwardIterator, PatternIterator, CorpusIterator. If you'd prefer to abbreviate "Iterator" with "It" or "Iter", then I'd abbreviate the categories, too: InIt, FwdIt, RandomIt, etc. You presume that all C++ implementations with a specific value of __cplusplus provide std::all_of, std::any_of, and std::none_of. Is that portable? Indentation is inconsistent. The use of mpl::identity for clamp's arguments should be documented for future maintainers. is_ordered() uses a one-line if/return and a two-line for no apparent reason. That inconsistency increases the chances of a maintainer failing to notice one or the other. search.hpp uses BOOST_ALGO_DEBUG. "ALGO" should be spelled out. Many of the functions controlled by that manifest constant use camelcase and should be all lower case. I was expecting more algorithm documentation in search.hpp. The code is not overly complex, but there should at least be pointers to literature on the implementation of each algorithm. However, as such literature may not always be accessible, copying pertinent information to the header would be helpful to future maintainers. __________ Documentation Specific notes and corrections are listed at the end of this message. I'd like to see the complexity, behavioral, and iterator information be documented for each algorithm separately rather than for a group, such as you've done in paragraphs 3 and 4 of all.html. Note that the complexity is described below the clamp algorithms and above the all_of, any_of, and none_of algorithms. This should be consistent. The algorithms are all function templates, so "the function <algorithm-name>" is incorrect. Thus, instead of "the function all_of", write "all_of". Look for other uses of "function" and "functions" for similar terminology issues. While is_increasing, is_decreasing, is_strictly_increasing, and is_strictly_decreasing are implemented using is_ordered, that is by no means a requirement. Consequently, I'd prefer that each was documented separately. Complexities written as should be written in all upper case: O(N), O(M x N), etc. The treatment of the two internal tables used by the search algorithms is inconsistent ("first", "second", "skip", etc.). I'm not even sure they should be mentioned as you do. I realize that you want to document memory usage and customization options, but perhaps the better approach is to clearly document the traits class and its usage as well as the memory usage in terms of the pattern and corpus character sets. For example, K-M-P allocates N bytes per element in the pattern. The Reference section for each algorithm should include "#include <boost/algorithm/foo.hpp>", to permit copying and pasting, plus complexity and template parameter requirements. Template parameters should be documented just as function parameters. Thus, for example, in the reference page for knuth_morris_pratt_search(), there should be a section that describes the two iterator types including their iterator category as well as their relationship (which elsewhere you mention requiring that their value_types be identical). The boyer_moore_search() and boyer_moore_horspool_search() algorithms do not have reference pages. There are no examples in the text. There should be an example for each algorithm. The search algorithms' traits classes are not documented. __________ Usefulness This library, in its current state has certain utility. As a place to incorporate future algorithms that don't deserve a library of their own, it has enormous utility. __________ Usage I did not try to use the library due to time constraints. __________ Effort I spent many hours studying and commenting on the code during the pre-review and now, reading the documentation, etc. __________ Domain Knowledge I have no experience designing string search algorithms. I have used many algorithms. I have designed a good deal of generic code. Thus, I have broad domain knowledge, but nothing extraordinary. __________ Documentation Issues _____ Description and Rationale 2nd para, 3rd sent: missing "and" from "tested, reviewed, documented" _____ Future plans Written with this review in mind, this section is fine, but for an accepted library, it isn't right. I suggest something like this: "This library will be extended by algorithms submitted or suggested by Boost developers and users. The Adobe Source Library (http://stlab.adobe.com/) for example, contains many useful algorithms with documentation and test cases that might be culled for inclusion in this library. Knuth's _The Art of Computer Programming_ is full of algorithm descriptions, too. Various algorithms have been created and documented in magazines, online forums, etc., or even just for personal use. All of these sources, and more, can provide fodder for algorithms to add to this library. "Adding new algorithms will require some form of review, but will not be subject to the usual Boost review process. The Boost.Algorithm maintainer would have the ability to add algorithms without review, but this will not be the case for non-trivial algorithms. Non-trivial algorithms, and possibly even trivial algorithms, will be subjected to a mini-review. This will be a call for Boost developers to study the proposed algorithms with the goal to get more minds to consider their design and utility to ensure their broad utility." _____ Header: 'all.hpp' The heading can just be "all.hpp". 1st para, 1st sent: Strike "The header file". 1st para, 2nd sent: any_of does not verify that every element has a particular property. 2nd para: All three of these algorithms is in C++11. Try this wording: "The iterator-based versions are part of the standard library in C++11 (§25.2 Non-modifying sequence operations). Boost.Algorithms will use the standard library versions of these algorithms when available." 4th para: The algorithms will not work on output iterators. Therefore, you should indicate that they require input iterators. _____ Header: 'clamp.hpp' The heading can just be "clamp.hpp". 1st para, 1st sent: Strike "The header file". The description is insufficient, which you seem to understand since you quoted "clamp". I suggest this instead: "clamp.hpp contains function templates to constrain a value to be within the inclusive range formed from supplied boundary values." 2nd para, bullets: s/iff/if. "iff" is overly proscriptive on the implementation. That is, lo could be returned if v == lo without affecting the result. 3rd para: "also" this sentence refers the previous paragraph, which uses < in the bullets, but this is a bit awkard. It would be better to describe each version of clamp separately. The second would have the same bulleted list, but would use p(v, lo) and p(hi, v). _____ Header: 'ordered.hpp' The heading can just be "ordered.hpp". 1st para, 1st sent: Strike "The header file". Strike the parentheses. 2nd para, 4th sent: Surely is_ordered returns the end iterator for sequences of less than two elements. 3rd para: s/are will not/will not/ 5th para, 1st sent: I'd prefer, "There are also a number of function templates that use is_ordered to determine whether an entire sequence satisfies a particular ordering." _____ Header: 'search.hpp' The heading can just be "search.hpp". ___ Overview 1st para, 1st sent: Strike "The header file". 3rd para: merge with the 2nd para 4th para: Change from first person and quoting to "For each of these search algorithms, the sequence being searched is referred to as the <i>pattern,</i> and the sequence being searched as the <i>corpus.</i>" 5th para, 1st sent: Change to "These search algorithms generate tables to make searches faster." 5th para, 3rd sent: s/To help with this/To provide control over the overhead/ 5th para, 3rd sent: s/;/:/ 5th para, 4th sent: s/the search/the search, thereby using the same generated table(s) for multiple searches./ 7th para: s/and here are/and here is/ 8th para, last sent: Must I1::value_type be the same as I2::value_type or must they merely be comparable? ___ Boyer-Moore 1st para: The wording at the end is confusing. I think you mean, "benchmark used in the literature on practical string searching." 2nd para: merge with the 1st para s/target string (pattern) that is being search for/pattern/ s/algorithm, while still...can have/algorithm has O(N) complexity, where N is the corpus length, but can have/ s/algorithms; it doesn't/algorithms because it doesn't/ s/gets faster as the key being search for becomes longer/is faster for longer patterns/ Note: s/skip table (the second one) as stored as an/skip table (the second one); it is stored as a/ s/are (say) UTF-16 text; in that case, the/are UTF-16 text, for example, since the/ s/The B-M and B-M-H objects take a 'traits' template parameter which lets/The traits template parameter of the B-M and B-M-H class templates allow/ s/paramater/parameter/ ___ Boyer-Moore-Horspool 1st para: s/Boyer-Moore, and has/Boyer-Moore, but has/ 2nd para: s/algorithm an internal/algorithm uses an internal/ You should mention that the traits template parameter allows using a different container to store that data so the memory usage can change. Unless this reference is to the "first" table. ___ Knuth-Morris-Pratt 2nd para: s/looking for the match - instead of just at the next entry/looking next for a match rather than just advancing to the next element/ _____ Reference I don't think the all.hpp content should be in reference.html. It should be found by a link like the other three headers. The declarations for all.hpp are compressed too much. Some vertical whitespace would be helpful. Why is "Marshall Clow" in the "Header <boost/algorithm/all.hpp>" section? It also appears in the clamp.hpp reference page. _____ Function template clamp (both) Returns: Could be improved: "lo if p(val, lo) returns true, hi if p(hi, val) returns true, and val otherwise." _____ Header <boost/algorithm/ordered.hpp> The declarations are compressed too much. Some vertical whitespace would be helpful. _____ Function template is_ordered (iterators) Returns: Could be improved: "the iterator it, in the range [first, last), for which p(*it) returns false, or last if there is no such iterator." _____ Function template is_ordered (range) Returns: Could be improved: "the iterator it, in range, for which p(*it) returns false, or boost::end(range) if there is no such iterator." _____ Function template is_increasing (iterators) Returns: "true if each element in [first, last) is greater than or equal to the previous element or [first, last) has fewer than two elements." _____ Function template is_increasing (range) Returns: "true if each element in range is greater than or equal to the previous element or range has fewer than two elements." _____ Function template is_decreasing (iterators) Returns: "true if each element in [first, last) is less than or equal to the previous element or [first, last) has fewer than two elements." _____ Function template is_decreasing (range) Returns: "true if each element in range is less than or equal to the previous element or range has fewer than two elements." _____ Function template is_strictly_increasing (iterators) Returns: "true if each element in [first, last) is greater than the previous element or [first, last) has fewer than two elements." _____ Function template is_strictly_increasing (range) Returns: "true if each element in range is greater than the previous element or range has fewer than two elements." _____ Function template is_strictly_decreasing (iterators) Returns: "true if each element in [first, last) is less than the previous element or [first, last) has fewer than two elements." _____ Function template is_strictly_decreasing (range) Returns: "true if each element in range is less than the previous element or range has fewer than two elements." _____ Header <boost/algorithm/search.hpp> The declarations are compressed too much, though the horizontal whitespace does help in the latter half. Some vertical whitespace would be helpful. _____ Class template boyer_moore The constructor deserves information on memory allocated, what exceptions might be emitted, etc. The function call operator should include information on its behavior, complexity, etc. The private member functions should not be listed. _____ Class template boyer_moore_horspool Ditto _____ Class template knuth_morris_pratt Ditto _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

4 7

Is someone interested in container CompressedVector, a vector-like storage for integer types
by Alexander Bulovyatov 02 Oct '11

02 Oct '11

Hi! Assume you want an interface as for vector<unsigned int>, but know that elements have only N significant bits, say 17. In this case the container will save 46% memory compared to vector<unsigned int>. CompressedVector internally stores elements as a dynamic bitset (vector<size_t>) and uses bitshift ops to put/get significant bits into one or two size_t elements. It's similar to vector<bool> and dynamic_bitset, and has the same drawback, it's not a proper STL container. Anyway, the container is simple, efficient and quite fast. It will work best for very long arrays of indexes. Since its storage is continuous, it can also be used to speed up IO (load/store to disk, network transfers) acting as a very fast compression.

2 4

metatest interface update, better Boost.Test integration
by Ábel Sinkovics 02 Oct '11

02 Oct '11

Hi, Thank you for the feedback about my library so far. I've done changes to the interface of the metatest library (currently part of mpllibs - https://github.com/sabel83/mpllibs) The purpose of the changes was to improve compatibility with Boost.Test. They make it easy to embed assertions of compile-time predicates in runtime test functions. The result and pretty-printed reason of a compile-time predicate is represented by an object of type test_result (http://abel.web.elte.hu/mpllibs/metatest/test_result.html) at runtime. These objects can be built using a template function, test_result::build. It evaluates the predicate and does the pretty-printing. operator<< is overloaded for test_result, thus one can easily display these objects in output streams. This is useful for passing the results of compile-time tests to runtime unit testing frameworks. I've implemented the metaprogramming equivalent of the BOOST_<level>() macros as template functions (meta_<level>). One can use them the following way: meta_check< equal_to<int_<13>, metafunction_to_test<int, char> > >(MPLLIBS_HERE); meta_warn< equal_to<int_<13>, metafunction_to_test<int, char> > >(MPLLIBS_HERE, "Some message"); // ... I've used a template function instead of a macro to improve the error messages about syntax errors in the predicates. The template function takes a location (http://abel.web.elte.hu/mpllibs/metatest/location.html) object as argument and metatest provides a macro, MPLLIBS_HERE, that constructs a location object with the current filename:line values. The template functions call BOOST_<level>_MESSAGE. A disadvantage of this solution is that the error reports contain two filename:line locations: the location of BOOST_<level>_MESSAGE in the integration function and the location of MPLLIBS_HERE (which is the one the user will be interested in). I've added a new example demonstrating these integration functions. You can find it in libs/metatest/example/boost_test_assertion in the source tree. I've tested the new interface with the same three compilers I've been testing the libraries with (gcc 4.5, clang 2.8, Visual C++ 10). I'm happy to receive feedback about the new interface. I'm interested if people find it useful. Regards, Abel

2 3

[contract] the volatile issue
by Lorenzo Caminiti 01 Oct '11

01 Oct '11

Hello all, N1962 does not indicate that contracts for volatile members should be handled in any special way (in fact, volatile is not discussed at all in N1962). My library does the following for volatile members: 1) The object `this` is const volatile (and not just const) while checking preconditions, postconditions, and invariants for a volatile member. 2) By default, class invariants of volatile members are the same as for non-volatile members. However, programmers can specify a different set of class invariants for volatile and non-volatile members if they wish to do so. The reason for 2) is that when programming a volatile member that overloads a non-volatile member, programmers can already specify a different set of preconditions and postconditions. Therefore, it seemed reasonable to give the option to also specify a different set of class invariants for volatile and non-volatile members (otherwise why would the pre/postcondition of a volatile member be different from the ones of its non-volatile version while the class invariants are forced to remain the same?). For example, consider a very strange number class which is non-negative (>= 0) when used in non-volatile context but it is non-positive (<= 0) when used in volatile context (probably not a real-life example but still...). The contracts could read: #include <contract.hpp> CONTRACT_CLASS( class (num) ) { CONTRACT_CLASS_INVARIANT( get() >= 0, // (1) volatile class( get() <= 0 ) // (2) ) public: CONTRACT_FUNCTION( public void (set) ( int x ) precondition( x >= 0 ) // 3) postcondition( get() == x ) ) { x_ = x; } CONTRACT_FUNCTION( public void (set) ( int x ) volatile precondition( x <= 0 ) // (4) postcondition( get() == x ) ) { x_ = x; } CONTRACT_FUNCTION( public int (get) ( void ) const ) { return x_; } CONTRACT_FUNCTION( public int (get) ( void ) const volatile ) { return x_; } num ( ) : x_(0) {} private: int x_; }; int main ( ) { num p; p.set(3); num volatile v; v.set(-3); return 0; } Note that via function overloading it is automatically possible to specify a different set of preconditions (and eventually postconditions) for the volatile member (4) than for the non-volatile member (5). Therefore, my library also allows to specify a different set of class invariants for volatile members (2) than for non-volatile members (1) so that the entire contract (including class invariants) can be programmed differently for volatile members if programmers wish to do so. However, if `volatile class(...)` is not used (default) the class invariants: CONTRACT_CLASS_INVARIANT( get() >= 0 ) are applied by the library to all members volatile and non-volatile. (In this case, this invariant is compiled in const volatile context iff the class has one or more volatile functions so a volatile verion of get() is only requirement if a volatile version of set() is introduced.) What do you think? Thanks, --Lorenzo

2 2

[Review:Algorithms] My review of Boost.Algorithm
by dpxguard-boost＠yahoo.gr 01 Oct '11

01 Oct '11

Hello list, First of all I have to clarify that I have only studied the three search algorithms and I can only speak about this part of the library. Furthermore my review was by no means exhaustive, I have only emphasized in few things which I had the time to notice. However I have noticed at least two showstoppers, one in documentation of the search algorithms and the other in the design of the KMP algorithm. Hence my vote for now is "no". I personally believe that the search algorithms should not be accepted, unless these issues are addressed, (or unless I am proved wrong of course) although it would be undoubtedly a good idea to have such a library in Boost. Specifically in the design issue of the KMP algorithm I am willing to help if this becomes necessary. A. Documentation issue The three search algorithms of this library does not offer any additional functionality compared to the standard std::search of the STL. On the contrary these algorithms are less generic than std::search. Consequently the only single reason that will make a developer to choose one of them instead of the std::search can be their performance superiority. (In the most notable STL implementations std::search is implemented using straightforward (brute-force) searching.) However in the documentation I have not found anything (no benchmarks, measurements, etc) that would help the user of the library to understand how fast each algorithm is and in which situations it is advisable to use it. (I believe Phil Endecott has mentioned this issue as well) This is especially important because of the following reasons: - Boyer-Moore and Boyer-Moore-Horspool have identical average time complexity, hence it is not easy for the user to choose among them based on their complexities. - Although KMP has much better worst-case complexity than a typical std::search implementation, their average complexities are practically the same. - The straightforward (brute-force) sequence searching is known to frequently outperform some KMP implementations. For all these reasons I believe that some performance analysis and performance guidelines should be added to the documentation, before this library becomes a part of Boost. For example it would be very nice to have a graphical performance comparison of these three algorithms together with the std::search, in different pattern and alphabet sizes. B. Design issue The fact that the KMP implementation of this library requires random-access iterators for both the pattern and the corpus, seems like a major design drawback to me. I also believe that this drawback virtually cripples the usefulness of the algorithm, for reasons I have already mentioned in previous posts. Best regards Jim Xochellis Homepage: https://sites.google.com/site/xochellis/

2 1

[timer] Boost Timer Library Version 2
by Beman Dawes 30 Sep '11

30 Sep '11

Version 2 of Boost.Timer is about ready to move to trunk. The original version 1 timers are deprecated, but not changed in any way. Besides deciding to keep the version 2 timers in Boost.Timer, many suggestions and corrections from the "Boost.Timer replacement" thread have been applied. See http://lists.boost.org/Archives/boost/2011/09/185820.php The docs can be viewed at http://beman.github.com/timer/ The code is available at https://github.com/Beman/timer Thanks to all who posted comments, corrections, and suggestions in response to the original posting. Special thanks to Rob Stewart - many of his suggestions have been incorporated - and to Vicente Botet for his work on Boost.Chrono which now is used to implement much higher resolution for wall-clock time. While additional comments are always welcome, unless someone comes up with a showstopper I'm planning to move Version 2 to trunk and get on with other projects. --Beman

3 15

Re: [boost] property tree find no match for 'operator=='
by Ivan Le Lann 30 Sep '11

30 Sep '11

----- "Bernd Prager" <bernd(a)prager.ws> a écrit : > All, > > This is likely to be a silly question. > I am trying to check for the existence of a value in a property tree. > > Reading the docs I assumed the easiest way would be: > > namespace pt = boost::property_tree; > static pt::ptree pt; > > bool has(const std::string key) { > if (pt.find(key) == pt.end()) return false; // (1) > return true; > } > > The compiler complains about "error: no match for 'operator=='" in > line > (1) though. > What am I missing? > For your problem, the two iterators are not of the same type. Don't know the exact reason, but I know that ptree uses multi_index. Might be related. Anyway : - you have a get_optional() method. - you can try replacing end() with not_found() Regards, Ivan

1 0

property tree find no match for 'operator=='
by Bernd Prager 30 Sep '11

30 Sep '11

All, This is likely to be a silly question. I am trying to check for the existence of a value in a property tree. Reading the docs I assumed the easiest way would be: namespace pt = boost::property_tree; static pt::ptree pt; bool has(const std::string key) { if (pt.find(key) == pt.end()) return false; // (1) return true; } The compiler complains about "error: no match for 'operator=='" in line (1) though. What am I missing? Thank you for any help, -- Bernd

2 1

[Review:Algorithms] My review of Boost.Algorithm
by Lorenzo Caminiti 30 Sep '11

30 Sep '11

Review of Boost.Algorithm 2011-09-29 - Lorenzo Caminiti ============================== Do you think the library should be accepted as a Boost library? ------------------------------ Yes, in my opinion Boost.Alrogithm should be accepted as a Boost library. Key points are: a) I would find the library usefull as is, especially for all_of_equal and for the search algorithms. b) I would like to see more algorithms supported into the library in the (near) future (IMO the "only" non-trivial algorithms currently offered are the 3 search algorithms). c) The documentation (which is clear and straightforward) should list more examples. My comments below are all numbered an marked as: [MUST] If these comments are not addressed, I would no longer recommend this library for addition to Boost. [WANT] I would like to see these comments addressed (at least replied to) but I would recommend this library for addition to Boost regardless. [NOTE] I do not feel strongly about these comments and they can be ignored. What is your evaluation of the design? ------------------------------ 1) [WANT] Could all/any/none/one_of_equal be made more general and merged with all/any/none/one_of by accepting a binary predicate via overloading? template<typename InputIterator, typename UnaryPred> bool all_of ( InputIterator first, InputIterator last, Pred p ); template<typename InputIterator, typename BinaryPred, typename V> bool all_of ( InputIterator first, InputIterator last, BinaryPred p, V const& v ); // could even overload for ternary, etc predicates bool BOOST_LOCAL_FUNCTION_PARAMS(int x) { return x > 0; } BOOST_LOCAL_FUNCTION_NAME(positive) int a[3] = {2, 2, 2}; all_of(a, a + 3, positive); // existing form all_of(a, a + 3, std::equal_to<int>(), 2); // instead of all_of_equal all_of(a, a + 3, std::less<int>(), 10); // can also do this now :) not just equal BTW, you can use Boost.Local to define the predicate functions at local scope ;) 2) [NOTE] Is there a (run-time) cost with the destruction of the tables used by Boyer-Moore and the other search algorithms? If so, is the same cost encountered by both the object and functional version of the algorithms? (BTW, it made sense to me to have both an object and function version of the algorithms.) 3) [MUST] There should be a range version for all search algorithms (unless it's not possible for some reason that I can't foresee). 4) [WANT] When using the object interface, is the caller responsible to keep the pattern in scope until the search object is destructed? Either way, this requirement should be clearly documented. 5) [NOTE] I'd be OK with any renaming of is_order based on other's opinions-- I'd follow C++11 if at all possible (is_sorted_until?). (No comment on clamp's argument ordering ;) .) What is your evaluation of the implementation? ------------------------------ 6) I very quickly read through the code. It looks clean and well organized... the iterator algorithms made sense. I did not study the search algorithm implementation close enough to comment on it. What is your evaluation of the documentation? ------------------------------ 7) [WANT] Please add more examples to the docs (you can take a few from the ones you already have in examples and tests). 8) [WANT] Always state complexity guarantees (they are mentioned in docs section but not in the code reference section). 9) [WANT] Are these examples from the docs incorrect? (What's 3, 9, etc?) one_of ( c.begin (), c.end (), 3 ) --> true one_of ( c, 3 ) --> true none_of ( c, 9 ) --> true any_of ( c.begin (), c.end (), 9 ) --> false 10) [WANT] Typos that I noted in the docs: * "are will" in "Since they have to return a place in the input sequence, input iterators are will not suffice". * check indentation of close `};` for `class boyer_moore`. * "and here are the corresponding procedural interface:" should say and "here is". 11) [WANT] Extend document of Boyer-Moore-Horspool and/or Knuth-Morris-Pratt with class code, etc to match docs of Boyer-Moore (interface is listed in the code reference section but not in the search algorithm section). What is your evaluation of the potential usefulness of the library? ------------------------------ 12) I would find the library useful as is (especially, for the handy all_of_equal and faster searches) but I would like to see more algorithms supported by the library in the near future. IMO, any/none/one/all and clamp are nice utilities, same goes for the ordered stuff, but at the end I got the sense that the search algorithms were the "only" real meat of the library. Did you try to use the library? With what compiler? Did you have any problem? ------------------------------ 13) Yes, I compiled all examples and tests on GCC 4.3.4 under Cygwin (BTW, in all_example.cpp rename all_of_val to all_of_equal). I got some warnings on MVSC 10 under Windows (see attached file). How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? ------------------------------ 14) I'd say a quick reading, I spent about 7 hours on it. I red all the docs and compiled all the examples (at least on GCC). Are you knowledgeable about the problem domain? ------------------------------ 15) Thankfully, not anymore ;) but reading the docs reminded of my class work on Boyer-Moore and variations-- it was a while ago. I'd say I am marginally familiar with the problem domain. --Lorenzo

3 3