May 2016 - Boost - lists.preview.boost.org

Call for Papers for Meeting C++ 2016 ends on Friday night!
by Jens Weller 25 May '16

25 May '16

Hello Boost Community! a short reminder, that the deadline is coming up for submitting your talk to this years Meeting C++ conference! Meeting C++ 2016 Page: http://meetingcpp.com/index.php/mcpp2016.html Talk submission page: https://meetingcpp.com/mcpp/submittalk/ thanks, Jens Weller

1 0

Error while compiling mysql-5.7.12 /usr/xpg4/include/term.h:596: error: conflicting types for ‘tgoto’
by Mariano Apilado 25 May '16

25 May '16

Hi, I get the following error when compiling mysql-5.7.12 on Nexenta 4.0.4 OS ( Formerly known as Open Solaris / Illumos ). In order to temporarily bypass this problem, I commented out. However, this is not the solution. /usr/local/mysql-5.7.12/cmd-line-utils/libedit/terminal.c:60: /* *#ifdef HAVE_CURSES_H *#include <curses.h> *#elif HAVE_NCURSES_H *#include <ncurses.h> *#endif */ Thanks and Regards,Mariano Error: [ 4%] Building C object cmd-line-utils/libedit/CMakeFiles/edit.dir/terminal.c.o cd /usr/local/mysql-5.7.12/cmd-line-utils/libedit && /usr/bin/gcc -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_POSIX_PTHREAD_SEMANTICS -D_PTHREADS -D_REENTRANT -D__EXTENSIONS__ -I/usr/local/mysql-5.7.12/cmd-line-utils/libedit -I/usr/local/mysql-5.7.12/include -I/usr/local/mysql-5.7.12/extra/rapidjson/include -I/usr/local/mysql-5.7.12/libbinlogevents/include -I/usr/local/mysql-5.7.12/libbinlogevents/export -I/usr/xpg4/include -m64 -O3 -g -fabi-version=2 -fno-omit-frame-pointer -fno-strict-aliasing -DDBUG_OFF -fPIC -m64 -lstdc++ -R'RIGIN/../lib' -R/usr/lib/amd64 -o CMakeFiles/edit.dir/terminal.c.o -c /usr/local/mysql-5.7.12/cmd-line-utils/libedit/terminal.c In file included from /usr/xpg4/include/curses.h:43, from /usr/local/mysql-5.7.12/cmd-line-utils/libedit/terminal.c:60: /usr/xpg4/include/term.h:596: error: conflicting types for ‘tgoto’ /usr/local/mysql-5.7.12/cmd-line-utils/libedit/sys.h:137: note: previous declaration of ‘tgoto’ was here gmake[2]: *** [cmd-line-utils/libedit/CMakeFiles/edit.dir/terminal.c.o] Error 1 gmake[2]: Leaving directory `/usr/local/mysql-5.7.12' gmake[1]: *** [cmd-line-utils/libedit/CMakeFiles/edit.dir/all] Error 2 gmake[1]: Leaving directory `/usr/local/mysql-5.7.12’ gmake: *** [all] Error 2

1 0

Having problems installing mysql 5.7.12 with boost ELF 32 bit, wrong ELF Class
by Mariano Apilado 25 May '16

25 May '16

Hi, I get the following error when compiling mysql-5.7.12 on Nexenta 4.0.4 OS ( Formerly known as Open Solaris / Illumos ). How do I fix the compile options or get the necessary files required to make the compile successful? Thanks and Regards, Mariano The files libboost_system.so and libboost_chrono.so are the wrong ELF class: ELFCLASS32. root@nex-01-test:/volumes# file /root/boost_1_59_0/stage/lib/libboost_system.so /root/boost_1_59_0/stage/lib/libboost_system.so: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped, no debugging information available root@nex-01-test:/volumes# file /root/boost_1_59_0/stage/lib/libboost_system.so /root/boost_1_59_0/stage/lib/libboost_system.so: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped, no debugging information available Error Message: [ 95%] Linking CXX executable ../mysqlpump cd /root/mysql-5.7.12/client/dump && /usr/local/bin/cmake -E cmake_link_script CMakeFiles/mysqlpump.dir/link.txt --verbose=1 /usr/bin/g++ -w -fpermissive -m64 -Wall -Wextra -Wformat-security -Wvla -Woverloaded-virtual -Wno-unused-parameter -O3 -g -fabi-version=2 -fno-omit-frame-pointer -fno-strict-aliasing -DDBUG_OFF -R'$ORIGIN/../lib' -R/usr/lib/amd64 CMakeFiles/mysqlpump.dir/program.cc.o -o ../mysqlpump libmysqlpump_lib.a -lboost_system -lboost_chrono ../base/libclient_base.a ../../libmysql/libmysqlclient.a -lsocket -lnsl -lm ../../extra/liblz4_lib.a ld: fatal: file /root/boost_1_59_0/stage/lib/libboost_system.so: wrong ELF class: ELFCLASS32 ld: fatal: file /root/boost_1_59_0/stage/lib/libboost_chrono.so: wrong ELF class: ELFCLASS32 ld: fatal: file processing errors. No output written to ../mysqlpump collect2: ld returned 1 exit status gmake[2]: *** [client/mysqlpump] Error 1 gmake[2]: Leaving directory `/root/mysql-5.7.12' gmake[1]: *** [client/dump/CMakeFiles/mysqlpump.dir/all] Error 2 gmake[1]: Leaving directory `/root/mysql-5.7.12’ gmake: *** [all] Error 2

2 1

[compute] [OS X 10.11.5] [GeForce GT 750M] Segmentation fault
by Prashant 25 May '16

25 May '16

Hi, Am trying to sort a vector on GPU (GeForce GT 750M) using example code which generates SEGV. However, it runs fine on Iris Pro (Intel(R) Core(TM) i7-4850HQ CPU). We observe SEGV when size is 10 million. When the size is 5 million, following exception is thrown: boost/1_61_0/include/boost/compute/command_queue.hpp(453): Throw in function boost::compute::event boost::compute::command_queue::enqueue_write_buffer(const boost::compute::buffer &, size_t, size_t, const void *, const boost::compute::wait_list &) Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector< boost::compute::opencl_error> > std::exception::what: Invalid Value Another observation: if the size of vector is 50 million the sorting works fine, though the timings are worse than Iris Pro. Also, when is size is 100 million, the binary causes the OS to crash. Compiler details: clang++ --version Apple LLVM version 7.3.0 (clang-703.0.31) Target: x86_64-apple-darwin15.5.0 Thread model: posix OS: System Version: OS X 10.11.5 (15F34) Kernel Version: Darwin 15.5.0 Regards, Prashant ----------------------------Cut here------------------------------------- #include <iostream> #include <vector> #include <algorithm> #include <boost/foreach.hpp> #include <boost/compute/core.hpp> #include <boost/compute/platform.hpp> #include <boost/compute/algorithm.hpp> #include <boost/compute/container/vector.hpp> #include <boost/compute/functional/math.hpp> #include <boost/compute/types/builtin.hpp> #include <boost/compute/function.hpp> #include <boost/chrono/include.hpp> #include <boost/exception/all.hpp> namespace compute = boost::compute; int main(int argc, char* argv[]) { if (argc != 2) { std::cout << "Usage: " << argv[0] << " <size> " << std::endl; return 0; } // generate random data on the host std::vector<float> host_vector(atoi(argv[1])); std::generate(host_vector.begin(), host_vector.end(), rand); std::cout << "===============CPU==================\n"; for (size_t k=0; k<5; k++) { std::vector<float> host_copy_vector(host_vector); auto start = std::chrono::high_resolution_clock::now(); std::sort(host_copy_vector.begin(), host_copy_vector.end()); auto duration = std::chrono::duration_cast<std::chrono::milliseconds> (std::chrono::high_resolution_clock::now() - start); std::cout << "time: iteration ("<< k << ") : " << duration.count() << " ms" << std::endl; } std::vector<compute::platform> platforms = compute::system::platforms(); for(size_t i = 0; i < platforms.size(); i++){ const compute::platform &platform = platforms[i]; std::cout << "Platform '" << platform.name() << "'" << std::endl; std::vector<compute::device> devices = platform.devices(); for(size_t j = 0; j < devices.size(); j++){ const compute::device &device = devices[j]; std::string type; if(device.type() & compute::device::gpu) type = "GPU Device"; else if(device.type() & compute::device::cpu) type = "CPU Device"; else if(device.type() & compute::device::accelerator) type = "Accelerator Device"; else type = "Unknown Device"; if (type != "GPU Device") { std::cout << "Ignoring non GPU devices.\n"; continue; } std::cout << "====\n"; std::cout << " " << type << ": " << device.name() << std::endl; std::cout << "====\n"; compute::context context(device); compute::command_queue queue(context, device); for (size_t k=0; k<5; k++) { compute::vector<float> device_vector(host_vector.size(), context); // copy data from the host to the device compute::copy( host_vector.begin(), host_vector.end(), device_vector.begin(), queue ); auto start = std::chrono::high_resolution_clock::now(); try { compute::sort(device_vector.begin(), device_vector.end(), queue); } catch (boost::exception & e) { std::cerr << diagnostic_information(e); break; } auto duration = std::chrono::duration_cast<std::chrono::milliseconds> (std::chrono::high_resolution_clock::now() - start); std::cout << "time: iteration ("<< k << ") : " << duration.count() << " ms" << std::endl; } std::cout << "====\n"; } } return 0; }

2 1

[multiprecision] compilation failure
by Raffi Enficiaud 24 May '16

24 May '16

Hi, I have the following failure on develop from multiprecision (unit tests of boost.test): In file included from writing-test-ts/fp-multiprecision-comparison-test.cpp:23:0: ../../../boost/multiprecision/cpp_dec_float.hpp: In member function ?std::size_t boost::multiprecision::backends::cpp_dec_float<Digits10, ExponentType, Allocator>::hash() const?: ../../../boost/multiprecision/cpp_dec_float.hpp:264:10: error: ?hash_combine? is not a member of ?boost? boost::hash_combine(result, data[i]); Thanks, Raffi

3 2

Request for a "Policy Review" regarding 'CMakeLists.txt'
by David Sankel 24 May '16

24 May '16

A question has been brought up regarding whether or not a Boost library author is permitted to include a 'CMakeLists.txt' file in the root of the directory. This stemmed from a discussion at C++Now 2016 which included several members of the Boost Steering Committee and a sampling of the Boost community. We recommend and propose that the Boost Guidelines are modified to allow library authors, at their own discretion, to include a 'CMakeLists.txt' file in their library's top-level directory. * Several libraries, such as Boost.Hana and Boost.Spirit, have two distribution mechanisms: one as distributed with Boost and the other as an independent package. The requirement that these libraries not include a 'CMakeLists.txt' as part of their Boost distribution creates a maintenance burden for authors or otherwise hurts usability of the independent distribution. * Several companies have revealed that they are building Boost with their own custom CMake scripts. The suggested policy change would enable authors to relieve the infrastructure cost of their CMake users and unify how their library is built. * CMake is, by far, the most popular build system for C++. Allowing authors to support CMake users in addition to BJam will help the Boost ecosystem to grow and thrive by lowering the barriers to access. -- David Sankel

51 224

Boost.Fit review Mars 3-20 result
by Vicente J. Botet Escriba 24 May '16

24 May '16

Hi, I will be out for two weeks and I wanted to at least give the result of the Boost.Fit library review even if I would need more time to have a complete report. Summary ======= The review of the proposed Boost.Fit library ended on Mars 20, 2016. The verdict is: Conditional acceptance (a new review is needed) There were too much concerns about the documentation and what exactly this library is proposing and not enough reviews commenting the design, code and test for each one of the proposed functions. From the review discussion I deduce that there is some interest in the library, and that some people don't understand yet what the library is proposing. Paul has started already to take in account some if the issues raised during the review and a lot of them must be resolved before we re-try a new review. There were some discussion about the name of the library, but there were no consensus. Paul is free to change the name of his library and see how people react. On behalf of the Boost community, I would like to thank Paul Fultz for the work he has put into the Fit library so far. I encourage him to continue to evolve this library and to bring it back for a new review. We had seven 6 formal votes, and 2 more votes without a complete review abbreviated here: Steaven Watanabe: No in his current state Zach Laine : Conditinal acceptance Krzysztof Jusiak: Accepted Artyom Beilis : Rejected Peter Dimov : Accepted (no review) Manuel Sancher : Accepted (no review) Rob Stewart : Conditinal acceptance ??? Louis Dionne : Conditinal acceptance There were other people that participated on the review giving their advice respect to a specific issue. I thank each of these reviewers, and indeed everyone who invested some time participating in the discussions. If you feel that I have misrepresented your position, or have omitted or garbled an important point, please respond: the archived mail thread should accurately reflect the will of the community, even if this message does not. Detailed Report =============== You will need to wait yet for a month before I will be able to do it. On the mean time there are a lot of issues that must be addressed and that are part of the github issues. For more information see: Github:https://github.com/pfultz2/Fit/tree/boost Issues:https://github.com/pfultz2/Fit/issues Documentation:http://pfultz2.github.io/Fit/doc/html/ Hopping this helps, Vicente Botet Escriba

11 26

b2 looks for tools/inspect/build/Jamfile
by Peter Dimov 23 May '16

23 May '16

I'm experimenting with a partial Boost clone, the superproject, tools/build, libs/bind, libs/config and few others, and when trying to build the tests, I'm getting the following error: D:\tmp\boost\libs\bind\test>..\..\..\b2 toolset=msvc-10.0 D:/tmp/boost/tools/build/src/build\project.jam:262: in find-jamfile from module project error: Unable to load Jamfile. error: Could not find a Jamfile in directory '../../../tools/inspect/build'. error: Attempted to find it with pattern '[Bb]uild.jam [Jj]amfile.v2 [Jj]amfile [Jj]amfile. [Jj]amfile.jam'. error: Please consult the documentation at 'http://www.boost.org'. D:/tmp/boost/tools/build/src/build\project.jam:280: in load-jamfile from module project D:/tmp/boost/tools/build/src/build\project.jam:64: in load from module project D:/tmp/boost/tools/build/src/build\project.jam:89: in load-used-projects from mo dule project D:/tmp/boost/tools/build/src/build\project.jam:75: in load from module project D:/tmp/boost/tools/build/src/build\project.jam:113: in load-parent from module p roject D:/tmp/boost/tools/build/src/build\project.jam:464: in initialize from module pr oject D:/tmp/boost/tools/build/src/build\project.jam:306: in load-jamfile from module project D:/tmp/boost/tools/build/src/build\project.jam:64: in load from module project D:/tmp/boost/tools/build/src/build\project.jam:113: in load-parent from module p roject D:/tmp/boost/tools/build/src/build\project.jam:464: in initialize from module pr oject D:/tmp/boost/tools/build/src/build\project.jam:306: in load-jamfile from module project D:/tmp/boost/tools/build/src/build\project.jam:64: in load from module project D:/tmp/boost/tools/build/src/build\project.jam:145: in project.find from module project D:/tmp/boost/tools/build/src\build-system.jam:535: in load from module build-sys tem D:\tmp\boost\tools\build\src/kernel\modules.jam:295: in import from module modul es D:\tmp\boost\tools\build\src/kernel/bootstrap.jam:139: in boost-build from modul e D:\tmp\boost\boost-build.jam:17: in module scope from module Does anyone have an idea why b2 looks for the tools/inspect Jamfile? I don't remember this being a problem before when I tried a stripped-down installation.

6 14

doctest - the lightest feature rich C++ single header testing framework - if it can enter boost and if it/boost will benefit from that
by Viktor Kirilov 23 May '16

23 May '16

Hello! I just released doctest - https://github.com/onqtam/doctest All the info about it can be found on github. So do you think it can enter the boost project? How much work will it take to get it into boost except for adding boost in the title? Will it or boost benefit from that addition? Also I've sort-of followed the Best Practice Handbook (I consider it very valuable) as much as possible - https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook Any feedback will be greatly appreciated. Thanks!

10 19

Rebooting Boost: Call for Lightning Talks @ CppCon
by Niall Douglas 23 May '16

23 May '16

At C++ Now a number of informal meetings showed there to be frustrations with the current ecosystem around the Boost C++ Libraries (to paraphrase a founder of Boost, "Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*". Recent and recurrent boost-dev discussions have raised the lack of cmake based tooling; lack of ABI management and the consequent ODR violation when mixing Boost versions in the same process; the anti-social behaviour of Boost towards library end users, new ideas, new blood and the wider C++ community; and the chronic lack of maintenance of up to half the Boost libraries. One question which needs to be answered is whether a clean reboot of Boost from the first principles of proving high quality C++ libraries well suited for use with the latest C++ standard is viable. This new collection of C++ libraries would be started completely from scratch (even if some existing libraries were ported into the new organisation), so ANYTHING is possible. All we need is a critical mass of library developers willing to collaborate on developing a shared infrastructure mutually beneficial to all participants, whether library developer or library end user. To that end of discovering if this critical mass is there, five minute lightning talk topics are requested for CppCon this September on this topic: "What design pattern, practice or idiom should a standards aspiring collection of C++ 14/17 libraries share?" Please keep each talk topic focused on a single design pattern, practice or idiom (see suggested talk format below). Each speaker may submit up to THREE talk topics (not all may be accepted if there are a lack of slots, so please rank them in order of preference). Please send your talk topics to me privately by email, only if sufficient numbers present to fill a session will your name and your talk topic be shared with the CppCon Programme Committee. We'll try to arrange a short panel session at the end so attendees can ask questions of the speakers. After the lightning talk we'll arrange a restaurant so all the speakers and any interested attendees can dine together, followed by a night in a Bellevue bar. If after the dust has settled it is felt there is a critical mass sufficient to reboot a brand shiny new edition of Boost, we'll start development! I should *stress* that it is up to the CppCon Programme Committee whether these lightning talks are approved or not. I'll just copy and paste your proposed talk to the CppCon PC as-is. If insufficient lightning talk topics are received by me to fill a 60 minute session, I'll withdraw this talk proposal from CppCon. Suggested talk format ================ Five minutes is not much time, so here is a suggested lightning talk outline: 1. A current widely practiced library design pattern (show example). 2. The problems it generates for library users or maintainers. 3. Your proposed alternative design pattern (show example). 4. The problems the alternative design pattern fixes. 5. Any mockup, prototype or even live demo (!) of the alternative design pattern in action. Suggested talk themes might be documentation, packaging, distribution, testing, tooling, quality assessment, barriers to entry, governance, strategy, important gaps in the standard libraries, automation and deprecation/removal policies. Here is an example of such a lightning talk: 1. Current design pattern: Library v1.00: namespace boost { namespace lib { void foo(size_t, char); } } User code: boost::lib::foo(100, 'n'); 2. Problem: Library v1.01: namespace boost { namespace lib { void foo(char, size_t); } } User code: boost::lib::foo(100, 'n'); // oh oh! 3. Alternative: Library v1.00: namespace boost { namespace lib { inline namespace v100 { void foo(size_t, char); } } } #define BOOST_LIB_NAMESPACE_V100 boost::lib::v100 Library v1.01: namespace boost { namespace lib { inline namespace v101 { void foo(char, size_t); } } } #define BOOST_LIB_NAMESPACE_V101 boost::lib::v101 User code: // Mount v100 of Boost.Lib into "lib" namespace lib=BOOST_LIB_NAMESPACE_V100; lib::foo(100, 'n'); // ABI stable! No ODR violation possible! 4. Problems fixed: a) Mixing incompatible versions of individual Boost libraries in the same process (or even translation unit) is now safe. b) Libraries can now depend on other libraries without worrying about breaking code which depends on them which uses a different version of the same dependency. This greatly helps reduce change ripple effects. c) Forward compatibility or alternative implementation shims are now very easy to implement e.g. library users can externally configure either Boost.Filesystem or std::experimental::filesystem for your library to use, your code simply refers to _some_ Filesystem TS implementation e.g. namespace filesystem = FILESYSTEM_TS_IMPLEMENTATION; filesystem::path mypath; -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

8 10