- Boost - lists.boost.org

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

Cross-compiling: linux host, qnx target. Perhaps it's a bug?
by Félix Robles 23 Sep '11

23 Sep '11

Hi, I've got KUbuntu 64bits installed: Linux findeton-PC 2.6.38-11-generic #48-Ubuntu SMP Fri Jul 29 19:02:55 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux I want to compile boost using qcc toolset (qcc versión 4.4.2) for a qnx target-os from a linux host, and I'm unable to compile python,serialization and test libs (the rest of them are fine). This is how I do it: $ ./bootstrap.sh And it goes fine, it uses the gcc compiler, not qcc, because I want to execute b2 in my linux machine. Then I use the following command: $ ./b2 --build-dir=/home/findeton/boost_1_47_0/ toolset=qcc target-os=qnx --build-type=complete -a And this is the kind of output I get: qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/numeric.o In file included from ./boost/integer_fwd.hpp:17, from ./boost/integer.hpp:18, from ./boost/function/function_base.hpp:21, from ./boost/function/detail/prologue.hpp:17, from ./boost/function/function_template.hpp:13, from ./boost/function/detail/maybe_include.hpp:13, from ./boost/function/function0.hpp:11, from ./boost/python/errors.hpp:13, from ./boost/python/handle.hpp:11, from ./boost/python/converter/arg_to_python_base.hpp:7, from ./boost/python/converter/arg_to_python.hpp:14, from ./boost/python/call.hpp:15, from ./boost/python/object_core.hpp:14, from ./boost/python/object.hpp:9, from ./boost/python/tuple.hpp:10, from ./boost/python/numeric.hpp:10, from libs/python/src/numeric.cpp:6: ./boost/cstdint.hpp:74: error: 'intleast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:75: error: 'intfast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:76: error: 'uintleast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:77: error: 'uintfast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:79: error: 'intleast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:80: error: 'intfast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:81: error: 'uintleast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:82: error: 'uintfast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:84: error: 'intleast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:85: error: 'intfast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:86: error: 'uintleast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:87: error: 'uintfast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:91: error: 'intleast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:92: error: 'intfast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:93: error: 'uintleast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:94: error: 'uintfast64_t' in namespace '::' does not name a type cc: /opt/qnx650/host/linux/x86/usr/lib/gcc/i486-pc-nto-qnx6.5.0/4.4.2/cc1plus error 1 "QCC" -Wc,-ftemplate-depth-128 -gstabs+ -O0 -Wc,-fno-inline -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_SOURCE -DBOOST_PYTHON_STATIC_LIB -I"." -I"/usr/include/python2.7" -c -o "/home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/numeric.o" "libs/python/src/numeric.cpp" ...failed qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/numeric.o... qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/list.o In file included from ./boost/integer_fwd.hpp:17, from ./boost/integer.hpp:18, from ./boost/function/function_base.hpp:21, from ./boost/function/detail/prologue.hpp:17, from ./boost/function/function_template.hpp:13, from ./boost/function/detail/maybe_include.hpp:13, from ./boost/function/function0.hpp:11, from ./boost/python/errors.hpp:13, from ./boost/python/handle.hpp:11, from ./boost/python/converter/arg_to_python_base.hpp:7, from ./boost/python/converter/arg_to_python.hpp:14, from ./boost/python/call.hpp:15, from ./boost/python/object_core.hpp:14, from ./boost/python/object.hpp:9, from ./boost/python/list.hpp:10, from libs/python/src/list.cpp:5: ./boost/cstdint.hpp:74: error: 'intleast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:75: error: 'intfast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:76: error: 'uintleast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:77: error: 'uintfast8_t' in namespace '::' does not name a type ./boost/cstdint.hpp:79: error: 'intleast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:80: error: 'intfast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:81: error: 'uintleast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:82: error: 'uintfast16_t' in namespace '::' does not name a type ./boost/cstdint.hpp:84: error: 'intleast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:85: error: 'intfast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:86: error: 'uintleast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:87: error: 'uintfast32_t' in namespace '::' does not name a type ./boost/cstdint.hpp:91: error: 'intleast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:92: error: 'intfast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:93: error: 'uintleast64_t' in namespace '::' does not name a type ./boost/cstdint.hpp:94: error: 'uintfast64_t' in namespace '::' does not name a type cc: /opt/qnx650/host/linux/x86/usr/lib/gcc/i486-pc-nto-qnx6.5.0/4.4.2/cc1plus error 1 "QCC" -Wc,-ftemplate-depth-128 -gstabs+ -O0 -Wc,-fno-inline -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_SOURCE -DBOOST_PYTHON_STATIC_LIB -I"." -I"/usr/include/python2.7" -c -o "/home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/list.o" "libs/python/src/list.cpp" ...failed qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/python/build/qcc/debug/link-static/target-os-qnx/list.o... [ And after some of those, then I get some of this kind : ] qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/serialization/build/qcc/release/target-os-qnx/threading-multi/binary_iarchive.o In file included from ./boost/serialization/extended_type_info_typeid.hpp:34, from ./boost/archive/detail/iserializer.hpp:47, from ./boost/archive/detail/interface_iarchive.hpp:22, from ./boost/archive/detail/common_iarchive.hpp:23, from ./boost/archive/basic_binary_iarchive.hpp:31, from ./boost/archive/binary_iarchive_impl.hpp:22, from ./boost/archive/binary_iarchive.hpp:20, from libs/serialization/src/binary_iarchive.cpp:14: ./boost/serialization/factory.hpp:28: error: '::va_list' has not been declared cc: /opt/qnx650/host/linux/x86/usr/lib/gcc/i486-pc-nto-qnx6.5.0/4.4.2/cc1plus error 1 "QCC" -Wc,-ftemplate-depth-128 -O3 -Wc,-finline-functions -Wc,-Wno-inline -shared -DBOOST_ALL_NO_LIB=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -DNDEBUG -I"." -c -o "/home/findeton/boost_1_47_0/boost/bin.v2/libs/serialization/build/qcc/release/target-os-qnx/threading-multi/binary_iarchive.o" "libs/serialization/src/binary_iarchive.cpp" ...failed qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/serialization/build/qcc/release/target-os-qnx/threading-multi/binary_iarchive.o... qcc.compile.c++ /home/findeton/boost_1_47_0/boost/bin.v2/libs/serialization/build/qcc/release/target-os-qnx/threading-multi/binary_oarchive.o In file included from ./boost/serialization/extended_type_info_typeid.hpp:34, from ./boost/archive/detail/oserializer.hpp:38, from ./boost/archive/detail/interface_oarchive.hpp:23, from ./boost/archive/detail/common_oarchive.hpp:22, from ./boost/archive/basic_binary_oarchive.hpp:34, from ./boost/archive/binary_oarchive_impl.hpp:23, from ./boost/archive/binary_oarchive.hpp:21, from libs/serialization/src/binary_oarchive.cpp:14: ./boost/serialization/factory.hpp:28: error: '::va_list' has not been declared

1 0

FW: Boost.Units problem with user-defined units and dimensionless quantities
by Pieter 23 Sep '11

23 Sep '11

Thanks Steven. I now see the problem arises from using si::dimensionless with nautical::length (The error message I get depends on the included header files but is related to the operator+ (when absolute.hpp is included) or the lack of a specialized add_typeof_helper in case that for example si/area.hpp is included). I guess my misconception was that I silently assumed that the 'dimensionless' type was acting as a normal double, reinforced by the fact that the line with the pure multiplication (nm1 = d*nm2;) does compile OK. The documentation says that " Because dimensionless quantities have no associated units, they behave as normal scalars, and allow implicit conversion to and from the underlying value type or types that are convertible to/from that value type". I intended to use my TDimless type as a 'generic' type for dimensionless quantities, but I now understand these quantities still need to be related to a 'system' and every system would need its own dimensionless type, even though there is no relation to the base units that define the system. Would I need to explicitly define conversions (e.g. BOOST_UNITS_DEFINE_CONVERSION_FACTOR(nautical::dimensionless, si::dimensionless, double, 1.0); or is there a more elegant way to use dimensionless quantities across systems? Thanks again, Pieter -----Original Message----- From: Steven Watanabe [mailto:watanabesj@gmail.com] Sent: Friday, September 23, 2011 17:06 To: boost(a)lists.boost.org Subject: Re: [boost] Boost.Units problem with user-defined units and dimensionless quantities AMDG On 09/21/2011 12:29 PM, Pieter wrote: > I am having some trouble using user-defined units and dimensionless once. > Consider the example (taken straight from the documentation) that > defines nautical miles (added at the bottom). > > When I do the following on VS2010: > > typedef quantity<boost::units::nautical::length> TDistanceInNMI; > typedef quantity<dimensionless> TDimLess; > > TDistanceInNMI nm1,nm2,nm3; > TDimLess d; > > nm1 = nm2 + nm3; // compiles OK > nm1 = d*nm2; // compiles OK > nm1 = nm2 + d*nm3; // does not compile, claims there is no operator+ > defined > > I suppose I might have to add a dimensionless type to the 'nautical' > system, or have some misconceptions on how this should work. I tried > adding the following line (mimicking some of the internal stuff) but > that did not due to trick: > > typedef unit<dimensionless_type,system> dimensionless; > I'm surprised that this doesn't work. It seems to work when I try it. The attached compiles with MSVC 2010. > Could anyone tell me whether there is there anything I need to define > to make this work? > In Christ, Steven Watanabe

1 0

Re: [boost] More tests running with Boost.Test than registered
by Jon Black 23 Sep '11

23 Sep '11

On 23-9-2011 7:42, boost-request(a)lists.boost.org wrote: >> So I put a print statement in the test in each DLL and ran it again, and > You could have used --log_level=all to see what is being tested Thanks. That's much nicer. >> > The project for MyDll1 depends on the other projects. That can't be a >> > coincidence! I'm confused though, why is the console_test_runner >> > executing tests in other DLL's when I've only specified MyDll1 on the >> > command line? Each DLL has its own unit_test_init() function declared in > You probably are using automatically registered test units. These are registered > in single shared test framework as soon as you load these libraries and they are > loaded in memory as they are dependencies of the library you want to test. Thus > you end up with all test units in all loaded libraries. Yes, they are automatically registered tests. In the init_unit_test() method I also give the master test suite a unique name for each DLL. If there is on shared test framework, does this mean I'm just renaming the same master test suite each time? > You can specify the test case belonging to the Mydll1 using --run=TestMyDll1 and > you'll get only 1 test case being executed. Perfect! I've used run_test to limit to a test suite which I've auto registered per project. > I think this is correct behavior overall. What you got here is implicit > dependency between test units you can't be sure TestMyDll1 working until you > tested all of it's dependent test cases which are in this case reside in > corresponding libraries. Agreed. I'm running it as a post build step. Adding the run_test option to limit what is executed solves my problem. Thanks. > Gennadiy

2 1

Boost.Units problem with user-defined units and dimensionless quantities
by Pieter 23 Sep '11

23 Sep '11

LS, I am having some trouble using user-defined units and dimensionless once. Consider the example (taken straight from the documentation) that defines nautical miles (added at the bottom). When I do the following on VS2010: typedef quantity<boost::units::nautical::length> TDistanceInNMI; typedef quantity<dimensionless> TDimLess; TDistanceInNMI nm1,nm2,nm3; TDimLess d; nm1 = nm2 + nm3; // compiles OK nm1 = d*nm2; // compiles OK nm1 = nm2 + d*nm3; // does not compile, claims there is no operator+ defined I suppose I might have to add a dimensionless type to the 'nautical' system, or have some misconceptions on how this should work. I tried adding the following line (mimicking some of the internal stuff) but that did not due to trick: typedef unit<dimensionless_type,system> dimensionless; Could anyone tell me whether there is there anything I need to define to make this work? Any help is appreciated, Many thanks, Pieter --- The example --- namespace boost { namespace units { namespace nautical { struct length_base_unit : base_unit<length_base_unit, length_dimension, 1000> { static std::string name() { return "nautical mile"; } static std::string symbol() { return "nmi"; } }; typedef make_system<length_base_unit>::type system; typedef unit<length_dimension,system> length; // 'typedef unit<dimensionless_type,system> dimensionless'; static const length mile,miles; } } } // helper for conversions between nautical length and si length BOOST_UNITS_DEFINE_CONVERSION_FACTOR(boost::units::nautical::length_base_uni t, boost::units::si::meter_base_unit, double, 1.852e3); Pieter

2 1

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

23 Sep '11

On Thu, 22 Sep 2011 08:03:09 lcaminiti wrote: >For example, the following code asserts back() == value only when >can_call_equal<T>::value is true. However, is there a better way to do this >that does not require the extra function call to post1? Unless I'm missing something, you should be able to replace the post1() calls with assert(boost::can_call_equal<T>::value && std::clog << "actual assertion\n" == std::clog && back() == value || std::clog << "trivial assertion\n" == std::clog);

3 5

structured exceptions for UNIXs -- the hard way
by Peter Foelsche 23 Sep '11

23 Sep '11

On UNIXs one does not get around signals. They are used for everything. E.g. using memory mapped io is impossible without dealing with signals. E.g. somebody may edit the file which is mapped into your process thereby truncating it and invalidating some part of the memory. Or one may be writing into a sparse file via memory mapped io and the result of "out of disk space" is also a signal. Then there are such sick solutions as setjmp()/longjmp(). Could they be packed into some class to enable some kind of structured exceptions on UNIXs? #include <setjmp.h> #include <vector> static std::vector<jmp_buf> s_sStack; static void signalHandler(void) { if (s_sStack.size()) { jmp_buf s = s_sStack.back(); s_sStack.pop_back(); longjmp(s); } } struct CSetLongJmp { CSetLongJmp(void) { s_sStack.push_back(jmp_buf()); if (setjmp(s_sStack.back())) throw "something"; } ~CSetLongJmp(void) { s_sStack.pop_back(); } }; This class would need to be part of anything which needs to be protected against signals: std::string s; CSetLongJmp s1; useString(s); Peter Foelsche

9 12