- Boost-users - lists.preview.boost.org

problem in configuring the environment
by arto rasimus 03 Oct '15

03 Oct '15

I have Raspberry Pi, realtime kernel in it and machinekit 2.7-0 package. Boost version is 1.55-0.What to check, since the machinekit does not find the boost? (and therefore configuration script fails) Linux raspberrypi 3.18.11+ #781 PREEMPT Tue Apr 21 18:02:18 BST 2015 armv6l GNU/Linux configure: error: boost::python is required to build LinuxCNC pi@raspberrypi /machinekit/src $ dpkg -l | grep boost ii libboost-atomic1.55-dev:armhf 1.55.0+dfsg-3 armhf atomic data types, operations, and memory ordering constraints ii libboost-atomic1.55.0:armhf 1.55.0+dfsg-3 armhf atomic data types, operations, and memory ordering constraints ii libboost-chrono1.55-dev:armhf 1.55.0+dfsg-3 armhf C++ representation of time duration, time point, and clocks ii libboost-chrono1.55.0:armhf 1.55.0+dfsg-3 armhf C++ representation of time duration, time point, and clocks ii libboost-date-time1.55-dev:armhf 1.55.0+dfsg-3 armhf set of date-time libraries based on generic programming concepts ii libboost-date-time1.55.0:armhf 1.55.0+dfsg-3 armhf set of date-time libraries based on generic programming concepts ii libboost-dev:armhf 1.55.0.2 armhf Boost C++ Libraries development files (default version) ii libboost-filesystem-dev:armhf 1.55.0.2 armhf filesystem operations (portable paths, iteration over directories, etc) in C++ (default version) ii libboost-filesystem1.55-dev:armhf 1.55.0+dfsg-3 armhf filesystem operations (portable paths, iteration over directories, etc) in C++ ii libboost-filesystem1.55.0:armhf 1.55.0+dfsg-3 armhf filesystem operations (portable paths, iteration over directories, etc) in C++ ii libboost-program-options-dev:armhf 1.55.0.2 armhf program options library for C++ (default version) ii libboost-program-options1.55-dev:armhf 1.55.0+dfsg-3 armhf program options library for C++ ii libboost-program-options1.55.0:armhf 1.55.0+dfsg-3 armhf program options library for C++ ii libboost-python-dev 1.55.0.2 armhf Boost.Python Library development files (default version) ii libboost-python1.55-dev 1.55.0+dfsg-3 armhf Boost.Python Library development files ii libboost-python1.55.0 1.55.0+dfsg-3 armhf Boost.Python Library ii libboost-serialization-dev:armhf 1.55.0.2 armhf serialization library for C++ (default version) ii libboost-serialization1.55-dev:armhf 1.55.0+dfsg-3 armhf serialization library for C++ ii libboost-serialization1.55.0:armhf 1.55.0+dfsg-3 armhf serialization library for C++ ii libboost-system-dev:armhf 1.55.0.2 armhf Operating system (e.g. diagnostics support) library (default version) ii libboost-system1.55-dev:armhf 1.55.0+dfsg-3 armhf Operating system (e.g. diagnostics support) library ii libboost-system1.55.0:armhf 1.55.0+dfsg-3 armhf Operating system (e.g. diagnostics support) library ii libboost-test-dev:armhf 1.55.0.2 armhf components for writing and executing test suites (default version) ii libboost-test1.55-dev:armhf 1.55.0+dfsg-3 armhf components for writing and executing test suites ii libboost-test1.55.0:armhf 1.55.0+dfsg-3 armhf components for writing and executing test suites ii libboost-thread-dev:armhf 1.55.0.2 armhf portable C++ multi-threading (default version) ii libboost-thread1.55-dev:armhf 1.55.0+dfsg-3 armhf portable C++ multi-threading ii libboost-thread1.55.0:armhf 1.55.0+dfsg-3 armhf portable C++ multi-threading ii libboost1.55-dev:armhf 1.55.0+dfsg-3

1 1

range: partition a transformed range adaptor
by Auer, Jens 02 Oct '15

02 Oct '15

Hi, So today I wanted to partition a transformed range. I came up with something like std::vector<int> v; auto t2 = r | transformed( [](int) {return 0;} ); auto p2 = boost::range::partition(t2, [](int) {return true;} ); , but that didn't work. On Stackoverflow, it was explained that this doesn't work because partition needs to modify the range, and a transformed range is not modifiable. So far so good, I can follow this and see why and modify the program to use transform on the vector directly. What bothers me is that I was not able to figure that out from the documentation, and that the error message was not very intuitive to say the least. According to the documentation, the requirements on the range for partition are that it has to be a model of ForwardRange, which means that the iterators have to be forward traversable iterators. I think the important fact, namely that it has to be writeable iterator, is missing from the documentation completely. As far as I can see, readable/writable categories are not used in the range documentation at all. Best wishes, Jens -- Dr. Jens Auer | CGI | Software Engineer CGI Deutschland Ltd. & Co. KG Rheinstraße 95 | 64295 Darmstadt | Germany T: +49 6151 36860 154 jens.auer(a)cgi.com Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter de.cgi.com/pflichtangaben. CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply e-mail.

1 0

parallelised ODE solvers
by Vihan Pandey 01 Oct '15

01 Oct '15

Dear all, I am trying to integrate a simple 2 variable ODE system. I wanted to know which of the solvers listed here : http://www.boost.org/doc/libs/1_56_0/libs/numeric/odeint/doc/html/boost_num… are parallelised for multicore CPU’s and GPU’s? Perhaps using Thrust for the Nvidia/CUDA GPU end of things? I am principally interested if someone has managed to make/port a library for parallelised RK45 methods. Please note in later work I plan on having more ODE's - probably systems of 12-15 parameters though they will be all be first order equations. Thanks and Cheers! - vihan -- Listening to Ozzy again!

3 4

boost::sort::spreadsort::integer_sort
by v9v＠laposte.net 01 Oct '15

01 Oct '15

Hi!I'm a C++ beginner and any help would be very much appreciated.I would like to convert this "std::sort" into "boost::sort::spreadsort::integer_sort".I know that I have to write "#include <boost/sort/spreadsort/integer_sort.hpp>" inmy header instead of "#include <algorithm>" but after that, this is too difficult...Thanks!-------------------------------------------------------------------#include <iostream>#include <algorithm>using namespace std;int main() { int nb1[4] = {15, 5, 0, 20}; int nb2[4] = {99,102, 8, 2}; int indices[4]; for (short i=0; i<4; i++) indices[i]=i; sort(begin(indices), end(indices), [&](int i1, int i2) { return nb1[i1] < nb1[i2]; } ); for (short i=0; i<4; i++) cout << nb1[indices[i]] << ' '; cout <<endl; // 0 5 15 20 for (short i=0; i<4; i++) cout << nb2[indices[i]] << ' '; cout <<endl; // 8 102 99 2 return 0;}---------------------------------------------------------------------

2 1

program_option parsing error
by Marek Skalický 30 Sep '15

30 Sep '15

Hello everyone, I have a question about program_option library. If I have argv=["binaryname", "--port", "5"] and port have set default_value=6 and implicit_value=7 what should be the value of port after parsing argv? I am asking because this test https://github.com/mongodb/mongo/blob/0481c958daeb2969800511e7475dc66986fa9… is failing with boost 1.59 (with boost 1.58 it is passing). Does someone please know what changed in this new version? Thank you, Marek

2 4

Is there any support for measuring or checking resource utilization in the boost utf?
by Victor Yankee 29 Sep '15

29 Sep '15

Is there any support for measuring or checking resource utilization, especially CPU usage and memory (either absolute amounts or percentages would be ok) in the boost utf?

2 1

bug in boost or in gcc-5.2.0 ?
by renaud lepere 29 Sep '15

29 Sep '15

I have a strange problem with mingw-w64, gcc-5.2.0 in 32bits on windows in release. The following code leads to a crash (it is working in 64 bits and in debug). The adress of return in the stack seems to be broken. I was not able to reduce it more than this, and in particular I am not able to remove BOOST_CHECK_CLOSE (using BOOST_CHECK_EQUAL works). This can be either a bug in gcc (false code generation) or something else. How can I investigate ? #define BOOST_TEST_MODULE MyTest #include <boost/test/unit_test.hpp> #include <iostream> struct P { P(double x_, double y_): x(x_), y(y_) {} double x; double y; }; struct Seg { Seg(const P & o_, const P & e_): o(o_), e(e_) {} P o; P e; }; void f() { auto Check = [](const Seg & s1, const Seg & s2, bool expected_common_cut, double expected_length) { std::cerr << expected_length << std::endl; BOOST_CHECK_CLOSE(1e-3, 1e-4, .1); }; Check(Seg(P(0, 0), P(100, 0)), Seg(P(0, 0), P(100, 0)), false, 0.0); Check(Seg(P(0, 0), P(100, 0)), Seg(P(100, 0), P(0, 0)), true, 100.0); std::cerr << "STILL LEAVING !" << std::endl; } void g() { std::cerr << "BEFORE CRASH" << std::endl; f(); std::cerr << "NEVER PRINTED" << std::endl; } BOOST_AUTO_TEST_CASE( my_test ) { g(); }

2 3

Heap: what is expected from T?
by Akim Demaille 28 Sep '15

28 Sep '15

Hi, I'm using a heap whose elements are value_type from a map; hence the key type is const. Some heaps seem to accept this gracefully, other just fail to compile. Is this expected? I saw no requirement about T in the documentation. This is Boost 1.59 from Mac Ports, on OS X. $ cat foo.cc #include <tuple> #include <string> #include <boost/heap/priority_queue.hpp> #include <boost/heap/fibonacci_heap.hpp> int main() { using datum_t = std::tuple<const std::string>; { using queue_t = boost::heap::fibonacci_heap<datum_t>; auto q = queue_t{}; q.emplace("foo"); } { using queue_t = boost::heap::priority_queue<datum_t>; auto q = queue_t{}; q.emplace("foo"); } } $ clang++-mp-3.7 -std=c++11 /tmp/foo.cc -isystem /opt/local/include In file included from /tmp/foo.cc:1: /opt/local/libexec/llvm-3.7/bin/../include/c++/v1/tuple:283:19: error: no viable overloaded '=' value = _VSTD::forward<_Tp>(__t); ~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~ /opt/local/libexec/llvm-3.7/bin/../include/c++/v1/tuple:485:45: note: in instantiation of function template specialization 'std::__1::__tuple_leaf<0, const std::__1::basic_string<char>, false>::operator=<const std::__1::basic_string<char> >' requested here __swallow(__tuple_leaf<_Indx, _Tp>::operator=(_VSTD::forward<_Tp>(static_cast<__tuple_leaf<_Indx, _Tp>&>(__t).get()))...); ^ /opt/local/libexec/llvm-3.7/bin/../include/c++/v1/tuple:498:29: note: in instantiation of member function 'std::__1::__tuple_impl<std::__1::__tuple_indices<0>, const std::__1::basic_string<char> >::operator=' requested here class _LIBCPP_TYPE_VIS_ONLY tuple ^ /opt/local/libexec/llvm-3.7/bin/../include/c++/v1/algorithm:4848:5: note: in instantiation of function template specialization 'std::__1::__sift_up<boost::heap::detail::heap_base<std::__1::tuple<const std::__1::basic_string<char> >, std::__1::less<std::__1::tuple<const std::__1::basic_string<char> > >, false, unsigned long, false> &, std::__1::__wrap_iter<std::__1::tuple<const std::__1::basic_string<char> > *> >' requested here __sift_up<_Comp_ref>(__first, __last, __comp, __last - __first); ^ /opt/local/include/boost/heap/priority_queue.hpp:261:14: note: in instantiation of function template specialization 'std::__1::push_heap<std::__1::__wrap_iter<std::__1::tuple<const std::__1::basic_string<char> > *>, boost::heap::detail::heap_base<std::__1::tuple<const std::__1::basic_string<char> >, std::__1::less<std::__1::tuple<const std::__1::basic_string<char> > >, false, unsigned long, false> >' requested here std::push_heap(q_.begin(), q_.end(), static_cast<super_t const &>(*this)); ^ /tmp/foo.cc:17:7: note: in instantiation of function template specialization 'boost::heap::priority_queue<std::__1::tuple<const std::__1::basic_string<char> >, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>::emplace<char const (&)[4]>' requested here q.emplace("foo"); ^ /opt/local/libexec/llvm-3.7/bin/../include/c++/v1/string:1376:19: note: candidate function not viable: 'this' argument has type 'const std::__1::basic_string<char>', but method is not marked const basic_string& operator=(const basic_string& __str); ^ /opt/local/libexec/llvm-3.7/bin/../include/c++/v1/string:1379:19: note: candidate function not viable: 'this' argument has type 'const std::__1::basic_string<char>', but method is not marked const basic_string& operator=(basic_string&& __str) ^ /opt/local/libexec/llvm-3.7/bin/../include/c++/v1/string:1383:45: note: candidate function not viable: 'this' argument has type 'const std::__1::basic_string<char>', but method is not marked const _LIBCPP_INLINE_VISIBILITY basic_string& operator=(const value_type* __s) {return assign(__s);} ^ /opt/local/libexec/llvm-3.7/bin/../include/c++/v1/string:1384:19: note: candidate function not viable: 'this' argument has type 'const std::__1::basic_string<char>', but method is not marked const basic_string& operator=(value_type __c); ^ /opt/local/libexec/llvm-3.7/bin/../include/c++/v1/string:1387:19: note: candidate function not viable: 'this' argument has type 'const std::__1::basic_string<char>', but method is not marked const basic_string& operator=(initializer_list<value_type> __il) {return assign(__il.begin(), __il.size());} ^ 1 error generated. Thanks in advance.

1 0

[multi_index_container] Using equal_range with hashed indices
by Muruganand Karthikeyan 28 Sep '15

28 Sep '15

Hello! std::equal_range requires that the container be pre-sorted ( http://www.cplusplus.com/reference/algorithm/equal_range/) How does multi-index container handle this scenario with respect to hashed non-unique indices. The reason I ask is since I'm facing a situation with equal_range. Please see below code - typedef bmi< UserIdEntry, indexed_by< hashed_non_unique<tag<id1_id2>, composite_key<UserIdEntry, BMI_MEMBER(UserIdEntry, std::string, id1), BMI_MEMBER(UserIdEntry, std::string, id2) > > > > UserIdContainer; typedef UserIdContainer::index<id1_id2>::type IndexById1Id2; typedef IndexById1Id2::const_iterator IndexById1Id2_it; std::pair<IndexById1Id2_it, IndexById1Id2_it> entries = indexById1Id2.equal_range(make_tuple(id1_val, id2_val)); I'm seeing that *sometimes* entries.first equals indexById1Id2.end() and entries.second does not equal indexById1Id2.end(). The lookup is valid - meaning I've verified that there is at-least one entry which should be caught by the equal_range. I'm guessing the iterators' values are swapped. (second should be pointing to first and first should be pointing to second) What could be the reason for this? Thanks, MK.

2 1

[multi_index_container] Using modify_key vs modify
by Muruganand Karthikeyan 28 Sep '15

28 Sep '15

Hello! Under what circumstances should we use modify_key? I believe we can achieve the same result using modify, so what is the advantage in using modify_key? Thanks, MK. -- Anand's signature

2 1