- Boost - lists.boost.org

[Review:Algorithms] About a static clamp function
by Vicente J. Botet Escriba 25 Sep '11

25 Sep '11

Hi, Sometimes the bound values are know at compile time. Could we ensure that the compiler could optimize the following code auto res = clamp(val, 1, 100); If this is not the case, I was wondering if it is worth adding a static clamp function that has its bounds defined as template parameters. auto res = static_clamp<1,100>(val); Best, Vicente

1 0

[system] Boost.Timer replacement
by Beman Dawes 25 Sep '11

25 Sep '11

"The best is the enemy of the good." Voltaire's famous bon mot applies to a replacement for Boost.Timer. I've had a "good", although not "best", replacement ready since circa 2006. It has always been set aside waiting for something better. The data-time, std::chrono, boost::chrono, boost::stopwatch, and probably others, were all candidates. I'm tired of waiting. http://beman.github.com/timer/ documents a useful replacement for Boost.Timer. The full library has been in the sandbox for years, but current development is on GitHub. See https://github.com/Beman/timer I'd like to move the header into boost/system/pending or boost/system/detail, and the rest into the appropriate libs/system subdirectories. The library will be proposed for a full review, or a mini-review if enough other Boost libraries start using it. If Endian gets accepted, for example, it certainly needs timing benchmarks. Comments? --Beman

7 13

[preprocessor] PP_CAT with symbols
by lcaminiti 25 Sep '11

25 Sep '11

Hello all, I just want to confirm that the following: BOOST_PP_CAT(old_size =, =) correctly (and always) expands to: old_size == I tested it on MSVC and GCC and it works. Plus from GCC documentation says about ##: Usually both will be identifiers, or one will be an identifier and the other a preprocessing number. When pasted, they make a longer identifier. This isn't the only valid case. It is also possible to concatenate two numbers (or a number and a name, such as 1.5 and e3) into a number. Also, multi-character operators such as += can be formed by token pasting. http://gcc.gnu.org/onlinedocs/gcc-3.2.3/cpp/Concatenation.html I am asking because ## has some limitation (x ## = is not valid, etc) so I want to confirm my understanding is correct. Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-preprocessor-PP-CAT-with-symbols-t… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 2

Overload resolution speed
by Mathias Gaunard 25 Sep '11

25 Sep '11

As part of the Boost.SIMD effort, another library was developed, Boost.Dispatch, which relies heavily on overload resolution. Before submitting this library for review, however, I did some compile-time benchmarking, and it's not looking very good. I'm therefore asking the Boost community if 1) this is expected, 2) if there is a workaround to this problem and 3) if compilers should be made to deal with this better. Boost.Dispatch essentially overloads a single free function, with, as arguments, a tag identifying the function followed by tags identifying properties/categories of the arguments (in an attempt to make a transparent tag dispatching system). The scripts from the link below [1] (the shell script is POSIX/GCC-only but should be easily adaptable) performs two tests: - Resolving a call with 1,000 function tags, overloaded 10 times each, everything implemented by overloading the same function as described above, - Resolving a call with 1,000 function tags, overloaded 10 times each, but with each function tag using a different functon. It takes 30s in the first case, 160ms in the second one. Unfortunately, the second solution is very restrictive and doesn't play very nice with generic programming. C++ apparently lacks a mechanism to define overloadable free functions with template parameters in their name. Back to the benchmark, making the number of functions vary show an apparent exponential increase in compile time. It's reasonably fast for 100 functions, but not at all for 1,000. On the other hand, changing the depth of the inheritance tree used for the category tags doesn't seem to affect it much. Any suggestions? [1] http://dl.dropbox.com/u/26902324/dispatching_bench.tar.gz

6 14

Persistency library
by Lifshitz, Yair 24 Sep '11

24 Sep '11

Hi, Object-based persistency/serialization libraries often require significant modifications to the code. Would Boost consider adding a process-level checkpointing library to boost? This is obviously not easily portable, so I understand this is a long shot. If it is relevant, we might contribute a package used by my team that support multiple Linux platforms. Thanks, Yair --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

3 2

Re: [boost] [Review:Algorithms] is_ordered name
by Brent Spillner 24 Sep '11

24 Sep '11

On Sat, 24 Sep 2011 09:34:59 joaquin wrote: >>Isn't this the same as the C++11 is_sorted_until? > >Yes! C+11 had is_sorted_until and is_sorted (equivalent to is_sorted_until(first,last)==last). I think the names here should be the same for >consistency reasons, and probably the functions should be just aliases to the c++11 ones where applicable. With the RV convention change that I proposed on github (always point before the first element that is out-of-order with respect to its predecessor, rather than the first that is out-of-order with respect to its successor), it would be exactly the same, so I think we may be stuck with this name, even though I agree that it sounds like it should return a bool. If we were starting from scratch my first impulse would be end_of_ordered_prefix(), but that too seems wordier than the ideal.

5 8

XInt library primality test
by Jorge Lodos Vigil 24 Sep '11

24 Sep '11

Hi The recently reviewed (and rejected) XInt library includes prime number functionality. To evaluate primality it uses Miller-Rabin test iterating 5 times. For "small" primes this is way insufficient, while for "large" primes it is more than needed. This last case have an important speed impact for numbers with more than 1024 bits . In its current state the library cannot correctly evaluate primality for numbers with less than 400 bits. You may consult "Damgaard, Landrock, Pomerance: Average case error estimates for the strong probable prime test. Math. Comp. 61 (1993)". Additionally, it seems that efficiency may be gained using boost/math/special_functions/prime.hpp instead of calculating the first 2000 primes. If there will be any further work on this library I'm willing to provide patches and tests. Thank you. Best regards Jorge

2 3

[Review:Algorithms] is_ordered behaviour for singleton input, and name
by Phil Endecott 24 Sep '11

24 Sep '11

Dear All, The docs for the proposed is_ordered say: The function is_ordered(sequence, predicate) returns the point in the sequence where the predicate does not hold. It does that by comparing adjacent pairs of elements in the sequence to see if the predicate is satisfied. If all adjacent pairs satisfy the predicate, then it will return one past the last element of the sequence. OK. If the sequence has less than two elements, it returns the last element of the sequence. In other words, sequences of length zero and one are considered to be ordered - using any possible criteria. Shouldn't that say "it returns one past the last element"? Also, regarding the name: I would expect any "is_something" function to return a boolean. Since this returns an iterator I would have called it something like find_disorder. (There is a good chance that an iterator is convertible to bool, so one could mistakenly write "if (is_ordered(begin,end)) { ... }".) Regards, Phil.

7 10

Boost.Algorithms Review Begins today
by Dave Abrahams 24 Sep '11

24 Sep '11

The review period for the proposed Boost.Algorithms library, by Marshall Clow, begins today (September 22) and runs through Oct 1. I'm pleased to act as review manager. ,----[ Important Notes ] | - Please do not post your review or discussion as a reply to this | message. | - Please begin your review's subject line with "[Review:Algorithms]" | - Please feel free to note any individual issues in the GitHub issue | tracker and make reference to them from your review. | - Please see below for *further* important notes `---- You can find the library at https://github.com/mclow/Boost.Algorithm. If you don't want to use Git, you can get a .zip or tarball snapshot at https://github.com/mclow/Boost.Algorithm/archives/master Description =========== The Boost Algorithms library is a work in progress; it is not meant to be a complete set of general purpose algorithms for C++ programming; but rather a small collection of useful algorithms, and a structure for adding more over time. The algorithms here fall into three basic categories: 1. Searching - Boyer-Moore Search - Boyer-Moore-Horspool Search - Knuth-Morris-Pratt search 2. Sequence properties - Tests to see if a sequence is ordered - Tests for the elements of a sequence 3. Miscellaneous - Constrain a value between two 'boundaries' (minmax) Potential Interactions with Existing Boost Libraries ==================================================== This submission potentially interacts with all of the following existing Boost libraries: * foreach - http://boost.org/libs/foreach * minmax - http://boost.org/libs/algorithm/minmax * range - http://boost.org/libs/range * string_algo - http://boost.org/libs/algorithm/string_algo Reviewers should consider these potential interactions. What to include in Review Comments ================================== - Keep your criticism constructive. Constructive criticism usually comes with specific suggestions for improvement. - If you identify problems along the way, please note if they are minor, serious, or showstoppers. - Please *do* vote on whether the library should be accepted. Everyone who takes the time to look at the library is qualified to vote, and every vote is valuable. - Other 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? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

4 5

Re: [boost] [contract] extra type requirements for contracts
by Brent Spillner 23 Sep '11

23 Sep '11

On Fri, 23 Sep 2011 06:45:10 lcaminiti wrote: >In this case T = val has an operator== which is private. This causes both >the methods (1) using dummy::operator== and (2) the traits requirement >can_call_equal<val> to fail :( Exactly (at least for the default implementation of can_call_equal<>). This is in general the behavior you want (can't accidentally apply a generic operator== to a type with special semantics for which that wouldn't make sense), but in a contract-checking context I think most users would rather at least have the option to silently ignore the untestable constraint. >Ideally, can_call_equal<val>::value will return false instead of generating >a compiler-error when val::operator== is private or protected. A part from >such an (impossible?) improvement to can_call_equal, I have no solution for Hardly impossible... If you really want the constraint to be tested, you obviously have to friend the constraint checker class (which may not always be permissible.) If you're content to ignore it, just specialize can_call_equal<perverse_type> to make the nested ::value false. Note that some user intervention is still required (adding a friend to perverse_type, or adding a specialization of can_call_equal<>), so your contracts won't be silently compiling to no-ops, but the library user has full control with minimal effort. As far as I know, there's no way to offer both options without naming the test predicate something other than operator==. Along the same lines, I recognize that test_equality() isn't the only operation required or supported by the contract mechanism (although I'll bet it's the most common.) However, I still believe that a few test_equality(), test_not_equal(), test_less_than_or_equal(), operator_add(), etc. stubs, and perhaps a HAS_MEMBER_FUNC() macro to generate other custom stubs, would enable more readable code than a postN() method for each constraint. On the other hand, there is something to be said for straightforward mechanical generation, and if you already create 4 other member functions per constraint it's probably not a big deal. >What do you think? Honestly, I think it's a great library, and I hope I can be disciplined enough to make a habit of using it.

1 0