October 2011 - Boost - lists.boost.org

[chrono] now() performance on several clocks
by Vicente J. Botet Escriba 03 Oct '11

03 Oct '11

Le 28/09/11 13:29, Vicente J. Botet Escriba a écrit : > Le 28/09/11 13:12, Stewart, Robert a écrit : >> Vicente J. Botet Escriba wrote: >>> Le 27/09/11 17:42, Stewart, Robert a écrit : >>> >>>>> - There's no information on Boost.Timers overhead relative >>>>> to timing the target code. >>>>> >>>> Are you asking for the overhead of the time computations or >>>> the reporting? >>> The former. >>> >>> > I will add some performance tests in Boost.Chrono to measure the time > spent by the now functions and the difference between two time_points > for each one of the clocks, so we can be fixed. > > Hi, I have measured the cost of calling Clock::now for some clocks and platforms. All the test are run with variant=release. The measured code stores on a vector the result of Clock::now() 10000000 times. /// for (int i=size-1; i>=0; --i) { vec[i]=Clock::now(); //vec[i]=typename Clock::time_point(typename Clock::time_point::duration(i)); } /// On iMac 3.06 GHz Inter Core i3. clang2.9 system_clock around 44 nanoseconds. steady_clock/high_resolution_clock around 24 nanoseconds. process_real_cpu_clock more than 600 nanoseconds. process_user_cpu_clock more than 1000 nanoseconds. Currently process_real_cpu_clock uses clock() and process_user_cpu_clock uses times(). On MinGw Windows msvc.10 system_clock around 32 nanoseconds. steady_clock/high_resolution_clock more that 2400 nanoseconds. process_real_cpu_clock around 84 nanoseconds. gcc-4.6 system_clock around 38 nanoseconds. steady_clock/high_resolution_clock more that 2500 nanoseconds. process_real_cpu_clock around 110 nanoseconds. Clearly I need to make more measures for the Windows based steady_clock code. The program is available on the trunk under the libs/chrono/perf directory. Could someone run the program on a posix platform? Please let me know if you think there is a better way to make these measures. Best, Vicente

1 0

[Interprocess] an XSI message queue
by Matthieu Dorier 03 Oct '11

03 Oct '11

Hello, I recently had to work with XSI shared memory objects using Boost, and I noticed that their is no implementation of the message_queue class on top of XSI shared memory objects. So I have created a new file xsi_message_queue.hpp (attached) defining this type of message queue. It is mostly based on the structures and classes defined in message_queue.hpp (in particular the messages, message headers, etc. and the mutex mechanism used in message_queue). It works fine in my project, but should certainly be more extensively tested if you want to integrate it in a future release. I noticed that contrary to other structures of the Interprocess library, message_queue is not very generic: you cannot simply change a template argument to make it work properly with XSI or Windows shared memory objects. Maybe a good step forward to improve it would be to make it more generic. -- Matthieu Dorier ENS Cachan, antenne de Bretagne Département informatique et télécommunication http://perso.eleves.bretagne.ens-cachan.fr/~mdori307/wiki/

1 0

[test] more files missing
by Jürgen Hunold 03 Oct '11

03 Oct '11

Hi Gennadiy, it seems you forgot to add at least the following files to svn: On Monday, 3. October 2011 08:59:48 gennadiy.rozental(a)thomson.com wrote: > +#include <boost/test/tree/observer.hpp> > +#include <boost/test/tree/test_unit.hpp> > +#include <boost/test/tree/visitor.hpp> > +#include <boost/test/tree/traverse.hpp> > +#include <boost/test/tree/test_case_counter.hpp> And btw. could you please update your email on svn.boost.org? Yours, Jürgen -- Dipl.-Math. Jürgen Hunold | IVE mbH Software-Entwickler | Lützerodestraße 10 Tel: +49 511 897668 33 | 30161 Hannover, Germany Fax: +49 511 897668 29 | http://www.ivembh.de juergen.hunold(a)ivembh.de | | Geschäftsführer: Sitz des Unternehmens: Hannover | Univ.-Prof. Dr.-Ing. Thomas Siefer Amtsgericht Hannover, HRB 56965 | PD Dr.-Ing. Alfons Radtke

2 2

the 'not' keyword
by Lorenzo Caminiti 03 Oct '11

03 Oct '11

Hello all, This might not be a "pure" Boost question but do you know if compilers portably support the 'not' keyword? int main ( ) { if(not false) return 0; return 1; } This compiles on GCC but not on MSVC... Why? If you look at the C++ standard, it says that 'not' is part of the language... Thanks a lot. --Lorenzo -- Sent from my mobile device Lorenzo

7 6

[accumulator] A lot of unused "parameter" warnings
by Vicente J. Botet Escriba 03 Oct '11

03 Oct '11

Hi, I'm getting a lot of warnings while using Boost.Accumulators. Would you accept a patch that resolve them by commenting the parameter name? Best, Vicente In file included from stopwatch/basic_stopwatch_laps_accumulator_set_pass.cpp:17: In file included from ../../../boost/chrono/stopwatches/memories/laps_accumulator_set.hpp:12: In file included from ../../../boost/accumulators/framework/accumulator_set.hpp:19: In file included from ../../../boost/parameter/parameters.hpp:45: ../../../boost/parameter/aux_/tagged_argument.hpp:123:60: warning: unused parameter 'x' [-Wunused-parameter] reference operator[](default_<key_type,Default> const& x) const ^ ../../../boost/parameter/aux_/tagged_argument.hpp:129:58: warning: unused parameter 'x' [-Wunused-parameter] reference operator[](lazy_default<key_type,F> const& x) const ^ In file included from stopwatch/basic_stopwatch_laps_accumulator_set_pass.cpp:17: In file included from ../../../boost/chrono/stopwatches/memories/laps_accumulator_set.hpp:12: In file included from ../../../boost/accumulators/framework/accumulator_set.hpp:23: In file included from ../../../boost/accumulators/framework/depends_on.hpp:39: In file included from ../../../boost/fusion/include/mpl.hpp:11: In file included from ../../../boost/fusion/mpl.hpp:23: In file included from ../../../boost/fusion/mpl/has_key.hpp:11: ../../../boost/fusion/sequence/intrinsic/has_key.hpp:71:29: warning: unused parameter 'seq' [-Wunused-parameter] has_key(Sequence const& seq) ^ In file included from stopwatch/basic_stopwatch_laps_accumulator_set_pass.cpp:17: In file included from ../../../boost/chrono/stopwatches/memories/laps_accumulator_set.hpp:12: In file included from ../../../boost/accumulators/framework/accumulator_set.hpp:29: In file included from ../../../boost/fusion/include/any.hpp:10: In file included from ../../../boost/fusion/algorithm/query/any.hpp:13: ../../../boost/fusion/algorithm/query/detail/any.hpp:112:36: warning: unused parameter 'it' [-Wunused-parameter] static bool call(It const& it, F f) ^ ../../../boost/fusion/algorithm/query/detail/any.hpp:112:42: warning: unused parameter 'f' [-Wunused-parameter] static bool call(It const& it, F f) ^ In file included from stopwatch/basic_stopwatch_laps_accumulator_set_pass.cpp:17: In file included from ../../../boost/chrono/stopwatches/memories/laps_accumulator_set.hpp:14: In file included from ../../../boost/accumulators/statistics/sum.hpp:14: ../../../boost/accumulators/numeric/functional.hpp:188:5: warning: unused variable 'plus' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(plus, +, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:188:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(plus, +, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:189:5: warning: unused variable 'minus' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(minus, -, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:189:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(minus, -, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:190:5: warning: unused variable 'multiplies' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(multiplies, *, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:190:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(multiplies, *, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:191:5: warning: unused variable 'divides' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(divides, /, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:191:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(divides, /, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:192:5: warning: unused variable 'modulus' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(modulus, %, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:192:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(modulus, %, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:194:5: warning: unused variable 'greater_equal' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(greater_equal, >=, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:194:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(greater_equal, >=, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:196:5: warning: unused variable 'less_equal' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(less_equal, <=, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:196:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(less_equal, <=, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:197:5: warning: unused variable 'equal_to' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(equal_to, ==, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:197:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(equal_to, ==, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:198:5: warning: unused variable 'not_equal_to' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(not_equal_to, !=, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:198:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(not_equal_to, !=, BOOST_NUMERIC_FUNCTIONAL_DEDUCED) ^ ../../../boost/accumulators/numeric/functional.hpp:200:5: warning: unused variable 'assign' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(assign, =, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:200:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(assign, =, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:201:5: warning: unused variable 'plus_assign' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(plus_assign, +=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:201:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(plus_assign, +=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:202:5: warning: unused variable 'minus_assign' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(minus_assign, -=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:202:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(minus_assign, -=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:203:5: warning: unused variable 'multiplies_assign' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(multiplies_assign, *=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:203:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(multiplies_assign, *=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:204:5: warning: unused variable 'divides_assign' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(divides_assign, /=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:204:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(divides_assign, /=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:205:5: warning: unused variable 'modulus_assign' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(modulus_assign, %=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:205:47: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_BINARY_OP(modulus_assign, %=, BOOST_NUMERIC_FUNCTIONAL_LEFT) ^ ../../../boost/accumulators/numeric/functional.hpp:207:5: warning: unused variable 'unary_plus' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(unary_plus, +) ^ ../../../boost/accumulators/numeric/functional.hpp:207:46: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(unary_plus, +) ^ ../../../boost/accumulators/numeric/functional.hpp:208:5: warning: unused variable 'unary_minus' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(unary_minus, -) ^ ../../../boost/accumulators/numeric/functional.hpp:208:46: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(unary_minus, -) ^ ../../../boost/accumulators/numeric/functional.hpp:209:5: warning: unused variable 'complement' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(complement, ~) ^ ../../../boost/accumulators/numeric/functional.hpp:209:46: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(complement, ~) ^ ../../../boost/accumulators/numeric/functional.hpp:210:5: warning: unused variable 'logical_not' [-Wunused-variable] BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(logical_not, !) ^ ../../../boost/accumulators/numeric/functional.hpp:210:46: note: instantiated from: BOOST_NUMERIC_FUNCTIONAL_DEFINE_UNARY_OP(logical_not, !) ^ ../../../boost/accumulators/numeric/functional.hpp:414:28: warning: unused variable 'average' [-Wunused-variable] op::average const &average = boost::detail::pod_singleton<op::average>::instance; ^ ../../../boost/accumulators/numeric/functional.hpp:417:28: warning: unused variable 'as_zero' [-Wunused-variable] op::as_zero const &as_zero = boost::detail::pod_singleton<op::as_zero>::instance; ^ ../../../boost/accumulators/numeric/functional.hpp:418:27: warning: unused variable 'as_one' [-Wunused-variable] op::as_one const &as_one = boost::detail::pod_singleton<op::as_one>::instance; ^ In file included from stopwatch/basic_stopwatch_laps_accumulator_set_pass.cpp:17: In file included from ../../../boost/chrono/stopwatches/memories/laps_accumulator_set.hpp:14: In file included from ../../../boost/accumulators/statistics/sum.hpp:16: ../../../boost/accumulators/framework/parameters/weight.hpp:17:1: warning: unused variable 'weight' [-Wunused-variable] BOOST_PARAMETER_KEYWORD(tag, weight) ^ ../../../boost/accumulators/framework/parameters/weight.hpp:17:30: note: instantiated from: BOOST_PARAMETER_KEYWORD(tag, weight) ^ In file included from stopwatch/basic_stopwatch_laps_accumulator_set_pass.cpp:17: In file included from ../../../boost/chrono/stopwatches/memories/laps_accumulator_set.hpp:18: In file included from ../../../boost/accumulators/accumulators.hpp:21: ../../../boost/accumulators/framework/parameters/weights.hpp:17:1: warning: unused variable 'weights' [-Wunused-variable] BOOST_PARAMETER_KEYWORD(tag, weights) ^ ../../../boost/accumulators/framework/parameters/weights.hpp:17:30: note: instantiated from: BOOST_PARAMETER_KEYWORD(tag, weights) ^

4 5

[Review:Algorithms]
by Edward Diener 03 Oct '11

03 Oct '11

This is my late review of the Boost Algorithms library. First a minor irritation. I am used to downloading a library in its own directory separate from a Boost tree, and then being able to generate docs and tests by running the bjam files with a line such as: 'bjam --boost=C:/Programming/VersionControl/boost toolset=msvc-10.0' where I point to a Boost tree with the --boost parameter. This works if the bjam root file has the canonical search for BOOST_ROOT given in the sandbox example library's jamroot.jam. It's really simple just to copy over that jamroot.jam into the root directory of the library before distribution, but almost no one seems to do this automatically. So I always have to do it myself. This is a PITA. So I wonder if we can not put on some web page for library developers this simple jamroot.jam and tell developers to use it. * What is your evaluation of the design? Clean and clear. * What is your evaluation of the implementation? I did not look. * What is your evaluation of the documentation? Very good. My only suggestion is that soem sort of extended discussion of advantages and disadvantages of search algorithms would be possible in the docs which would allow an end-user to decide what search algorithm would be optimal for particular practical situations. * What is your evaluation of the potential usefulness of the library? Very useful and very much needed. There is a little overlap with some other Boost libraries as mentioned in Dave Abrahams initial introduction to the library in his post about the start of the review, but I very much like the general nature of the algorithms where other libarries are more specific to their domain. * Did you try to use the library? With what compiler? Did you have any problems? I tried quickly with MSVC-10.0 and gcc-4.6.0, neither with any problems. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A very quick evaluation but a thorough reading. * Are you knowledgeable about the problem domain? Aside from the search algorithms I have used various forms of nearly all the other algorithms in my programming career so I understand what they are about and how useful they can be. I vote for the Boost Algorithms library to be accepted into Boost and I look forward to other general purpose algorithms being added to it in the future. Boost should be leading the way in introducing general purpose algorithms that work on C++ sequences, via range or iterators, given the fact that the C++ standard library changes as slowly as the C++ standard and new algorithms can be quite useful, as these are. Kudos to Marshall Clow for a clean and effective design and keeping the initial algorithms focused on usefulness and end-user simplicity, both of which I value very highly.

2 1

[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 03 Oct '11

03 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 03 Oct '11

03 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