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

Analogous to DESTDIR for Boos installation
by Leo Cacciari 29 Sep '17

29 Sep '17

Hi, I need to prepare a binary distribution of Boost for deploying on company hosts. For this, I need to configure libraries with a prefix of say /usr/local, doing as per documentation ./bootstrap.sh --prefix=/some/path where /some/path is the actual path where the libraries and header flles will be installed on the various hosts. To prepare the package to be distributed (the actual packaging system used is irrelevant here, simply assuming a tar.gz would do) I need, however, to "install" everything under some other path, say /path/to/package/content. When using gnu packages, I usually do something like ./configure --prefix=/some/path make make DESTDIR=/path/to/package/content install and then I can prepare and distribute my package. I'm unable to find an analogous procedure for Boost. More exactly, I do not found a way to invoke the install phase of b2 with a different prefix than the one specified to the stage phase through the --prefix options to boostrap.sh I solved the problem in a unsatisfactory way by manually copying the files from both the source and the build directory to the content folder, but I'd really like to have an automated way to do it. Is this possible? If yes, how? And if not, does anyone have a better idea than manual copying? Thanks for the help -- Leo Cacciari Aliae nationes servitutem pati possunt. Populi Romani est propria libertas.

2 1

[review] The review period of Boost.DoubleEnded has been extended with one week. Now ends 7th of October.
by Thorsten Ottosen 28 Sep '17

28 Sep '17

Dear users and members of Boost, People have been requesting extra time for the review of Boost.DoubleEnded. We therefore continue one week extra, so the final date will be October the 7th. kind regards Thorsten Original review announcement ------------------------------------------ I'm proud to announce that the formal review of Benedek Thaler's Boost.DoubleEnded library starts today, September 21, and runs through September 30. This library is the result of Benedek's participation in Google Summer of Code 2015. The library may be downloaded from https://github.com/erenon/double_ended and the documentation may be found here: http://erenon.hu/double_ended/ Anyone is welcome to post a review and/or take part in subsequent discussions (see below for review guidelines). Introduction ------------ This is a container library that provides two containers: A. boost::devector B. boost::batch_deque Both containers provides efficient push_front and push_back operations, hence the name DoubleEnded. The boost::devector class can be seen as an extension of std::vector with efficient support for push_front (so boost::devector provides contiguous storage). In addition, it provides a customizable small buffer optimization like boost::small_vector(*). It furthermore allows for customization of the growth factor such that the user can decide if a reallocation should allocate 1.5 or 2 or whatever more memory. And finally it provides new functionality that does not exist in normal vector implementations -- this functionality allow the class to excel in performance in certain situations like serialization or transfer of data from sources that require a preallocated buffer. The boost::batch_deque is similar to std::deque, but with two important twists. Like std::deque, it provides reference stability when calling push_front/push_back. Reference stability is crucial for programs that uses intrusive containers e.g. using Boost.Intrusive (**). boost::batch_deque has the following main advantages: 1. It allows the user to specify the segment size 2. It allows for external iteration over the segments Taken together, they provide a very efficient and flexible basis for intrusive containers. Access to the segments also increases performance for tasks such as serialization. Finally, boost::batch_deque may be seen as an efficient alternative to std::vector if you want to replace a percent-wise memory overhead with a constant memory overhead and have no need for contiguous storage. Review guidelines ----------------- Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Boost.DoubleEnded as a Boost library. Please be explicit about your decision. Some other questions you might want to consider answering: - 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 which compiler(s)? 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? More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html Kind regards Thorsten, Review manager (*) boost::small_vector: https://tinyurl.com/ycslp4ot (**) http://www.boost.org/doc/libs/1_64_0/doc/html/intrusive.html -- Best regards, Thorsten Jørgen Ottosen, Ph.D. Director of Research +45 23308797 Dezide (www.dezide.com)

1 0

[geometry] Runtime dimensionality
by Florian Lindner 28 Sep '17

28 Sep '17

Hello, I just started yesterday looking into boost.geometry to use on our own legacy system of Vertices (Points) in Meshes. I'm quite impressed how easy it is to adapt to existing code and got it working (with some workarounds) really quick. However, some problems remain. We have a Vertex object, with a dimension determined at runtime. The actual position is saved as VECTOR_T (usually an Eigen::VectorXd (double vector of arbitrary dimension)). One can get the coordinates using "const Eigen::VectorXd& Vertex::getNormal()" I was able to adapt to geometry by adding getters/setts for the dimensions: double getX() and getY() and BOOST_GEOMETRY_REGISTER_POINT_2D_GET_SET(mesh::Vertex, double, cs::cartesian, getX, getY, setX, setY) and it works! But in theory the vertices can be of arbitrary dimension, in practice it's usually 1, 2 or 3. What is the best way to adapt our Vertex object to geometry? - Change our Vertex so that it meets the model::point requirements. It worked so far, for the access I use: template<size_t Dimension> struct access<Vertex, Dimension> { static double get(Vertex const& p) { return p.getCoords()[Dimension]; } static void set(Vertex& p, double const& value) { Eigen::VectorXd vec = p.getCoords(); vec[Dimension] = value; p.setCoords(p); } }; In our code we rarely set the entries of an vector, so the code is a but ugly. Will likely change that to a compile-time get<Dim>() as a member of Vertex. My biggest problem is the dimensionality template<> struct dimension<Vertex> : boost::mpl::int_<2> {}; but I have no idea currently how to get that for an Eigen::VectorXd at compile-time? Do you have any idea? Thanks! Florian

5 8

Problem updating code to boost 1.64
by Tim Burgess 26 Sep '17

26 Sep '17

Hi, I have an application that I'm resurrecting. I originally coded it using Visual Studio 2010 with the boost that was current at the time (not sure what version that was). The following line of code used to build fine: if (CurrentAction[ 0].As <std::wstring>().compare( wstrFunctionName) == 0) With my current boost 1.64, I get the following error: >c:\users\tim\projects\surfacereader\screenreaderfunctionsdlg.cpp(146): error C2039: 'As': is not a member of 'boost::any' The intent of the code is as follows: If CurrentAction[ 0] (which is a boost::any) contains an std::wstring value, compare it to wstrFunctionName. Can anybody offer some guidance, please? Best wishes. Tim Burgess

2 1

[review][Fit] Review Results
by Matt Calabrese 24 Sep '17

24 Sep '17

Hello everyone, It is my privilege to announce that the Boost library count will once again be incremented as Paul Fultz II's library Fit has been accepted into Boost without conditions. Further details about this decision follow, but before that I'd like to thank Paul for all of the hard work he has put into Fit. Thanks also to everyone who participated in the review, with additional thanks to Vicente who was the review manager for the previous Fit review and who also provided a very detailed review and discussion during this review period. //////////////////////////////////////////////////////////////////////////////// Overview //////////////////////////////////////////////////////////////////////////////// Complete Reviews Considered: Zach Laine: Accept Vicente J. Botet Escriba: Accept John P. Fletcher: Accept Robert Ramey: Accept Jason Rice: Accept Barrett Adair: Accept Lee Clagett: Accept Glen Fernandes: Accept Louis Dionne: Accept Partial Reviews/Discussions Considered: Edward Diener Andrea Bocci Further Discussions (Previous Review): Steven Watanabe Peter Dimov Vladimir Batov Gavin Lambert Rob Stewart Bjorn Reese Manu Sanchez Artyom Beilis //////////////////////////////////////////////////////////////////////////////// Summary //////////////////////////////////////////////////////////////////////////////// Though not all responders reviewed every single aspect of the library, the reviews together adequately covered everything that is necessary for a decision to be made. This decision is made with additional confidence coming from usage of the library by some reviewers going back since during or before the initial review in early 2016. //////////////////////////////////////////////////////////////////////////////// Improvements Since Previous Review //////////////////////////////////////////////////////////////////////////////// This time around we received several more complete reviews than in the previous review period making it easier to be confident in a decision. A couple of notable changes since the 2016 review include: * Improved documentation * Default semantics for "capture" no longer try to determine whether to capture by reference or by value based on the argument being an lvalue or an rvalue (users can still get this via basic_capture) * Improved ADL awareness (internal calls are qualified) Throughout all of the discussions in this second review period, there were no explicit rejections of the library as a whole, though there were several recommendations from participants. A selection of those are listed here, though no changes are strictly required for acceptance: //////////////////////////////////////////////////////////////////////////////// Current Concerns //////////////////////////////////////////////////////////////////////////////// ////////// Design concerns: * Inheritance from user-callables has some potential pitfalls * Generated "infix" operators are "gimmicky" and don't add much value/may cause confusion * Placeholders should live in their own namespace ////////// Documentation concerns (not a complete list): * More examples requested * It is not always clear what files need to be #included for certain facilities in early examples * Better rationale for ConstFunctionObjects * Raw code is not linked from the examples ////////// Suggested name changes from reviewers: * Suggested rename of "partial()" to "partial_apply()" or "curry()" * Suggested rename of "conditional()" to "invoke_first()" or "call_first_of()" * Suggested rename of "apply" to "invoke" * Refer to "Callables" instead as "Invocables" (due to C++17 direction) * Library name "Fit" is not indicative of what it provides //////////////////////////////////////////////////////////////////////////////// Regarding the Author //////////////////////////////////////////////////////////////////////////////// Paul has been active in the Boost community for several years now. He is aware of his responsibilities going forward and I am confident that he will be a reliable maintainer for Fit for the foreseeable future (or whatever the library may be called). //////////////////////////////////////////////////////////////////////////////// Comments on the Name Boost.Fit //////////////////////////////////////////////////////////////////////////////// Note that what I say here is my personal opinion as a member of the community and does not necessarily reflect the opinions of others in the community nor of those in the steering committee. A few reviewers voiced that they would like to see a change of the library name "Fit". While multiple people did suggest this, my opinion is that this should be up to the author to choose whether or not he will change the name before it is added to boost and so I do not think it would be appropriate for us to strictly require or encourage such a change. If the author found the arguments against the name compelling, then he is welcome to change the name, but he should not feel obligated to do so. As a quick note on that, we have several high quality and highly regarded libraries in Boost with names that may not directly tell users what the library is for. Based on their popularity, I do not believe that it has significantly negatively affected their usage or ability to be found. A library name also may be important to an author as a creative outlet and I think it would be... poor form us to force such a change in this particular case and in other cases unless there are very strong reasons (i.e. the name is overly or intentionally misleading or there are legal concerns). I am not convinced that the current name is misleading enough to strictly require a change. As for existing precedent, some examples of libraries already in Boost with names that do not directly tell the user what the library is for include some of Boost's most highly regarded libraries such as Boost.Spirit (including Qi and Karma), Boost.Phoenix, Boost.Wave, Boost.Hana, and the recently accepted Boost.Beast. //////////////////////////////////////////////////////////////////////////////// Thanks again to everyone who participated in this review and in the previous review, and once again, congratulations to Paul on his library's acceptance into Boost. -- -Matt Calabrese -- -Matt Calabrese

1 0

[review] The review of Boost.DoubleEnded starts today: September 21 - September 30
by Thorsten Ottosen 21 Sep '17

21 Sep '17

Dear users and members of Boost, I'm proud to announce that the formal review of Benedek Thaler's Boost.DoubleEnded library starts today, September 21, and runs through September 30. This library is the result of Benedek's participation in Google Summer of Code 2015. The library may be downloaded from https://github.com/erenon/double_ended and the documentation may be found here: http://erenon.hu/double_ended/ Anyone is welcome to post a review and/or take part in subsequent discussions on the boost developer list (see below for review guidelines). Introduction ------------ This is a container library that provides two containers: A. boost::devector B. boost::batch_deque Both containers provides efficient push_front and push_back operations, hence the name DoubleEnded. The boost::devector class can be seen as an extension of std::vector with efficient support for push_front (so boost::devector provides contiguous storage). In addition, it provides a customizable small buffer optimization like boost::small_vector(*). It furthermore allows for customization of the growth factor such that the user can decide if a reallocation should allocate 1.5 or 2 or whatever more memory. And finally it provides new functionality that does not exist in normal vector implementations -- this functionality allow the class to excel in performance in certain situations like serialization or transfer of data from sources that require a preallocated buffer. The boost::batch_deque is similar to std::deque, but with two important twists. Like std::deque, it provides reference stability when calling push_front/push_back. Reference stability is crucial for programs that uses intrusive containers e.g. using Boost.Intrusive (**). boost::batch_deque has the following main advantages: 1. It allows the user to specify the segment size 2. It allows for external iteration over the segments Taken together, they provide a very efficient and flexible basis for intrusive containers. Access to the segments also increases performance for tasks such as serialization. Finally, boost::batch_deque may be seen as an efficient alternative to std::vector if you want to replace a percent-wise memory overhead with a constant memory overhead and have no need for contiguous storage. Review guidelines ----------------- Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision. Some other questions you might want to consider answering: - 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 which compiler(s)? 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? More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html Kind regards Thorsten, Review manager (*) boost::small_vector: https://tinyurl.com/ycslp4ot (**) http://www.boost.org/doc/libs/1_64_0/doc/html/intrusive.html

1 0

Linker error when using Boot regex on AIX
by Jyoti Sharma 18 Sep '17

18 Sep '17

I am using boost_1_61_0. In my code I have: #include <boost/regex.hpp> static boost::regex testxp("["); I have these libraries: libboost_regex.a libboost_regex.so I can see these libraries have symbols: LIBRARY: Shared object libboost_regex.so: 136 symbols imported. LIBRARY: Shared object libboost_system.so: 7 symbols imported. To build my program I have added these linking options: -Wl,-bnoquiet -Wl,-Bstatic -lboost_regex -lboost_system -Wl,-Bdynamic But I get this error during linking: ld: 0711-317 ERROR: Undefined symbol: .boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::do_assign(char const*, char const*, unsigned int) But that symbol is there: machine:/home> nm libboost_regex.so nm libboost_regex.so |grep do_assign ._ZN5boost11basic_regexIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE9do_assignEPKcS7_j T 268508592 machine:/home> c++filt ._ZN5boost11basic_regexIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE9do_assignEPKcS7_j .boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::do_assign(char const*, char const*, unsigned int)

2 3

Last Day for Boost Community Dinner Sign up
by Jon Kalb 18 Sep '17

18 Sep '17

Boost Users, Today is the last day to register for the Boost Community Dinner at CppCon. http://sched.co/Bhcr You do not need to be registered to attend CppCon to register for the Boost Community Dinner: https://cppcon.org/registration/ If you are going to be in the Seattle area a week from Tuesday, join us for a rare face-to-face get together of the Boost Community. See you there. Jon

1 0

[fiber] pooled_fixedsize_stack
by DePizzottri 14 Sep '17

14 Sep '17

Hi, I'm trying to replace fixedsize_stack with pooled_fixedsize_stack in my application witch spawns many fibers to reduce allocations, and got random crashes. For reproduction it is enough to replace fixedsize_stack with pooled_fixedsize_stack in performance\fiber\skynet_stealing_detach.cpp. Playing with stack size parameter does not help. Can anyone give some tip how to use pooled stack with fiber correctly? -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Users-f2553780.html

3 5

Help trying to compile boost 1_65_1 on Windows (Visual Studio 2017) with LZMA filter support
by Diego Luna 12 Sep '17

12 Sep '17

Hello everyone, this is my first post. Like the subject says, I need some help compiling boost 1_65_1 on Windows (Visual Studio 2017) on 64 bits with LZMA filter support. I've been compiling boost on Windows and Linux for some time without any problems, but the LZMA support in Windows, caused me some problems. I've downloaded and compiled the LZMA lib (XZ utils from https://tukaani.org/xz/) producing static (lib) and shared(dll+lib) libraries, in release and debug variants, then I have written the following user config jam (I think the problem is in the syntax of the file): ########################################## ## Using Python 3.6 (64 bits). ## using python : 3.6 : C:\\APPS\\PROGRAMMING\\Python36-64\\python.exe : C:\\APPS\\PROGRAMMING\\Python36-64\\include : C:\\APPS\\PROGRAMMING\\Python36-64\\libs : <address-model>64 ; ## Using lzma library 5.2.3. ## ## using lzma : 5.2.3 : <name>liblzma <include>C:\\APPS\\PROGRAMMING\\LIBRARIES\\lzma\\include <search>C:\\APPS\\PROGRAMMING\\LIBRARIES\\lzma\\lib64 : <variant>release <link>shared ; using lzma : 5.2.3 : <name>liblzmad <include>C:\\APPS\\PROGRAMMING\\LIBRARIES\\lzma\\include <search>C:\\APPS\\PROGRAMMING\\LIBRARIES\\lzma\\lib64 : <variant>debug <link>shared ; using lzma : 5.2.3 : <name>liblzma_static <include>C:\\APPS\\PROGRAMMING\\LIBRARIES\\lzma\\include <search>C:\\APPS\\PROGRAMMING\\LIBRARIES\\lzma\\lib64 : <variant>release <link>static ; using lzma : 5.2.3 : <name>liblzma_staticd <include>C:\\APPS\\PROGRAMMING\\LIBRARIES\\lzma\\include <search>C:\\APPS\\PROGRAMMING\\LIBRARIES\\lzma\\lib64 : <variant>debug <link>static ; ########################################## The command line for the actual compiling (after bootstrap), (omitting the path to the other libraries for shortness, those are linked\compiled without any problem) is: .\b2 -j6 --user-config=.\user-config-64.jam --build-type=complete -q -sZLIB_SOURCE="%ZLIB_ROOT%" -sBZIP2_SOURCE="%BZIP2_ROOT%" -sICU_PATH="%ICU_LIB%" toolset=msvc-14.1 link="static,shared" threading=multi ^ variant="debug,release" architecture=x86 address-model=64 runtime-link=shared stage --debug-symbols=on --debug-store=database --debug-configuration -d2 The output is: notice: found boost-build.jam at E:/DATA/TMP/boost/boost_1_65_1/boost-build.jam notice: loading Boost.Build from E:/DATA/TMP/boost/boost_1_65_1/tools/build/src notice: Searching 'C:\WINDOWS' 'C:\Users\bakaneko' 'C:\APPS\TOOLS\UNIX-HOME' 'C:\Users\bakaneko' 'E:\DATA\TMP\boost\boost_1_65_1\tools/build/src' 'E:/DATA/TMP/boost/boost_1_65_1/tools/build/src/kernel' 'E:/DATA/TMP/boost/boost_1_65_1/tools/build/src/util' 'E:/DATA/TMP/boost/boost_1_65_1/tools/build/src/build' 'E:/DATA/TMP/boost/boost_1_65_1/tools/build/src/tools' 'E:/DATA/TMP/boost/boost_1_65_1/tools/build/src/contrib' 'E:/DATA/TMP/boost/boost_1_65_1/tools/build/src/.' for site-config configuration file 'site-config.jam'. notice: Configuration file 'site-config.jam' not found in 'C:\WINDOWS' 'C:\Users\bakaneko' 'C:\APPS\TOOLS\UNIX-HOME' 'C:\Users\bakaneko' 'E:\DATA\TMP\boost\boost_1_65_1\tools/build/src' 'E:/DATA/TMP/boost/boost_1_65_1/tools/build/src/kernel' 'E:/DATA/TMP/boost/boost_1_65_1/tools/build/src/util' 'E:/DATA/TMP/boost/boost_1_65_1/tools/build/src/build' 'E:/DATA/TMP/boost/boost_1_65_1/tools/build/src/tools' 'E:/DATA/TMP/boost/boost_1_65_1/tools/build/src/contrib' 'E:/DATA/TMP/boost/boost_1_65_1/tools/build/src/.'. notice: Loading explicitly specified user configuration file: E:\DATA\TMP\boost\boost_1_65_1\user-config-64.jam notice: Searching 'E:\DATA\TMP\boost\boost_1_65_1' for user-config configuration file 'user-config-64.jam'. notice: Loading user-config configuration file 'user-config-64.jam' from 'E:/DATA/TMP/boost/boost_1_65_1'. notice: [python-cfg] Configuring python... notice: [python-cfg] user-specified version: "3.6" notice: [python-cfg] user-specified cmd-or-prefix: "C:\APPS\PROGRAMMING\Python36-64\python.exe" notice: [python-cfg] user-specified includes: "C:\APPS\PROGRAMMING\Python36-64\include" notice: [python-cfg] user-specified libraries: "C:\APPS\PROGRAMMING\Python36-64\libs" notice: [python-cfg] user-specified condition: "<address-model>64" notice: [python-cfg] Checking interpreter command "C:\APPS\PROGRAMMING\Python36-64\python.exe"... notice: [python-cfg] running command 'DIR /-C /A:S "C:\APPS\PROGRAMMING\Python36-64\python.exe" 2>&1' notice: [python-cfg] running command 'C:\APPS\PROGRAMMING\Python36-64\python.exe -c "from sys import *; print('version=%d.%d\nplatform=%s\nprefix=%s\nexec_prefix=%s\nexecutable=%s' % (version_info[0],version_info[1],platform,prefix,exec_prefix,executable))" 2>&1' notice: [python-cfg] ...requested configuration matched! notice: [python-cfg] Details of this Python configuration: notice: [python-cfg] interpreter command: "C:\APPS\PROGRAMMING\Python36-64\python.exe" notice: [python-cfg] include path: "C:\APPS\PROGRAMMING\Python36-64\include" notice: [python-cfg] library path: "C:\APPS\PROGRAMMING\Python36-64\libs" notice: [python-cfg] DLL search path: "C:\APPS\PROGRAMMING\Python36-64" notice: [python-cfg] Checking for NumPy... notice: [python-cfg] running command 'C:\APPS\PROGRAMMING\Python36-64\python.exe -c "import sys; sys.stderr = sys.stdout; import numpy; print(numpy.get_include())"' notice: [python-cfg] NumPy enabled notice: [lzma] Using pre-installed library notice: [lzma] Condition <link>shared <variant>release notice: [lzma] Using pre-installed library notice: [lzma] Condition <link>shared <variant>debug notice: [lzma] Using pre-installed library notice: [lzma] Condition <link>static <variant>release notice: [lzma] Using pre-installed library notice: [lzma] Condition <link>static <variant>debug notice: Searching '.' for project-config configuration file 'project-config.jam'. notice: Loading project-config configuration file 'project-config.jam' from '.'. notice: [msvc-cfg] msvc-14.0 detected, command: 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\cl.exe' notice: [msvc-cfg] msvc-11.0 detected, command: 'C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\cl.exe' notice: [msvc-cfg] msvc-14.1 detected, command: 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25503\bin\HostX64\arm\cl.exe' notice: will use 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25503\bin\HostX64\arm\cl.exe' for msvc, condition <toolset>msvc-14.1 'notice: [generate-setup-cmd] 14.1 is 14.1' 'notice: [generate-setup-cmd] 14.1 is 14.1' 'notice: [generate-setup-cmd] 14.1 is 14.1' 'notice: [generate-setup-cmd] 14.1 is 14.1' notice: [msvc-cfg] condition: '<toolset>msvc-14.1/<architecture>/<address-model>', setup: 'call "C:\Users\bakaneko\AppData\Local\Temp\b2_msvc_14.1_vcvars32_.cmd" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-14.1/<architecture>/<address-model>32', setup: 'call "C:\Users\bakaneko\AppData\Local\Temp\b2_msvc_14.1_vcvars32_.cmd" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-14.1/<architecture>x86/<address-model>', setup: 'call "C:\Users\bakaneko\AppData\Local\Temp\b2_msvc_14.1_vcvars32_.cmd" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-14.1/<architecture>x86/<address-model>32', setup: 'call "C:\Users\bakaneko\AppData\Local\Temp\b2_msvc_14.1_vcvars32_.cmd" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-14.1/<architecture>/<address-model>64', setup: 'call "C:\Users\bakaneko\AppData\Local\Temp\b2_msvc_14.1_vcvarsx86_amd64_.cmd" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-14.1/<architecture>x86/<address-model>64', setup: 'call "C:\Users\bakaneko\AppData\Local\Temp\b2_msvc_14.1_vcvarsx86_amd64_.cmd" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-14.1/<architecture>ia64/<address-model>', setup: 'call "C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Auxiliary/Build/vcvarsall.bat" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-14.1/<architecture>ia64/<address-model>64', setup: 'call "C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Auxiliary/Build/vcvarsall.bat" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-14.1/<architecture>arm/<address-model>', setup: 'call "C:\Users\bakaneko\AppData\Local\Temp\b2_msvc_14.1_vcvarsx86_arm_.cmd" >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-14.1/<architecture>arm/<address-model>32', setup: 'call "C:\Users\bakaneko\AppData\Local\Temp\b2_msvc_14.1_vcvarsx86_arm_.cmd" >nul ' notice: [zlib] Building zlib from source as boost_zlib notice: [zlib] Condition notice: [zlib] found zlib source in C:\APPS\PROGRAMMING\LIBRARIES\zlib\src_inc notice: [bzip2] Building bzip from source as boost_bzip2 notice: [bzip2] Condition notice: [bzip2] found bzip source in C:\APPS\PROGRAMMING\LIBRARIES\bzip2\src notice: [lzma] Using pre-installed library notice: [lzma] Condition Performing configuration checks - 32-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes - symlinks supported : no - junctions supported : yes - hardlinks supported : yes - C++11 mutex : yes - Boost.Config Feature Check: cxx11_auto_declarations : yes - Boost.Config Feature Check: cxx11_constexpr : yes - Boost.Config Feature Check: cxx11_defaulted_functions : yes - Boost.Config Feature Check: cxx11_final : yes - Boost.Config Feature Check: cxx11_hdr_mutex : yes - Boost.Config Feature Check: cxx11_hdr_tuple : yes - Boost.Config Feature Check: cxx11_lambdas : yes - Boost.Config Feature Check: cxx11_noexcept : yes - Boost.Config Feature Check: cxx11_nullptr : yes - Boost.Config Feature Check: cxx11_rvalue_references : yes - Boost.Config Feature Check: cxx11_template_aliases : yes - Boost.Config Feature Check: cxx11_thread_local : yes - Boost.Config Feature Check: cxx11_variadic_templates : yes - icu (64-bit) : yes warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - lzma : yes - iconv (libc) : no - iconv (separate) : no - native-atomic-int32-supported : yes - message-compiler : yes - native-syslog-supported : no - pthread-supports-robust-mutexes : no - compiler-supports-visibility : no - compiler-supports-ssse3 : yes - compiler-supports-avx2 : yes - gcc visibility : no - long double support : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. - libbacktrace builds : no - addr2line builds : no - WinDbg builds : yes - WinDbgCached builds : yes - lzma : yes (cached) - lzma : yes - lzma : yes (cached) Component configuration: - atomic : building - chrono : building - container : building - context : building - coroutine : building - date_time : building - exception : building - fiber : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - log : building - math : building - metaparse : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - signals : building - stacktrace : building - system : building - test : building - thread : building - timer : building - type_erasure : building - wave : building ...patience... ...patience... ...patience... ...patience... ...patience... ...found 29592 targets... ...updating 2728 targets... ... When the compiling is done the related libraries (iostream) are: boost_iostreams-vc141-mt-1_65_1.dll boost_iostreams-vc141-mt-1_65_1.lib boost_iostreams-vc141-mt-gd-1_65_1.dll boost_iostreams-vc141-mt-gd-1_65_1.lib libboost_iostreams-vc141-mt-1_65_1.lib libboost_iostreams-vc141-mt-gd-1_65_1.lib The problem is that both, "boost_iostreams-vc141-mt-gd-1_65_1.dll" and "boost_iostreams-vc141-mt-1_65_1.dll" were linked to the debug version of the LZMA dll (libzmad.dll), and examining the log, both "libboost_iostreams-vc141-mt-gd-1_65_1.lib" and "libboost_iostreams-vc141-mt-1_65_1.lib" were statically linked to the debug version of the static LZMA library (liblzma_staticd.lib). I tried with some more combinations in the user jam file, but without success, and in most cases failing to detect LZMA. If you require any further information to help find the problem, please, let me know, I'd appreciate any help with this problem. Sorry for my English, best regards, Diego. P.S: The config log can be found here: config.log <https://www.dropbox.com/s/kkut7kuka2jgi57/config.log?dl=0>.

1 0

Re: [Boost-users] [stacktrace] Getting a stacktrace from unhandled exception in windows
by Don 12 Sep '17

12 Sep '17

-------- Original Message -------- Subject: Boost-users Digest, Vol 4770, Issue 1 From: boost-users-request(a)lists.boost.org To: boost-users(a)lists.boost.org Date: 9/10/2017 10:56 PM > Subject: Re: [Boost-users] [stacktrace] Getting a stacktrace from unhandled exception in windows > From: Stian Zeljko Vrba <vrba(a)quine.no> > Date: 9/10/2017 10:54 PM > > Unless you need the stacktrace to be logged to a text file, I suggest you look at this system-provided >facility: https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).… ><https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181%28v=vs.85…> > > ...> IOW, you can get out more information than with boost.stacktrace with zero coding. > >> *Sent:* Monday, September 11, 2017 1:27:47 AM >> *To:* boost-users(a)lists.boost.org >> *Subject:* [Boost-users] [stacktrace] Getting a stacktrace from unhandled exception in windows >>>> I am trying use boost stacktrace to get a stack dump when my program encounters an unhandled exception >> under windows. I have installed a signal handler as described in the stacktrace documentation, and it >> gets called. However, the resulting stack trace is after everything has been unwound. >> >> For example, when I force a failure by dereferenceing a null pointer many levels down in my function >> hierarchy, the stack trace shows: >> >> 0# boost::stacktrace::detail::this_thread_frames::safe_dump_to_impl<char const *> at f:\home\tools\boost\boost\stacktrace\safe_dump_to.hpp:68 >> 1# boost::stacktrace::safe_dump_to at f:\home\tools\boost\boost\stacktrace\safe_dump_to.hpp:120 >> 2# my_signal_handler at f:\home\test\main.cpp:233 >> 3# 0x5171407B >> 4# my_signal_handler at f:\home\test\main.cpp:235 >> 5# 0x51713883 >> 6# __tmainCRTStartup at f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c:603 >> 7# WinMainCRTStartup at f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c:403 >> 8# BaseThreadInitThunk in kernel32 >> 9# RtlInitializeExceptionChain in ntdll >> 10# RtlInitializeExceptionChain in ntdll >> >> This is not particularly helpful, of course -- I want to know the call stack at the point of the >> failure. Is there any way to get that? What am I missing? Thanks for the suggestion, but yes, I want to log the data to a log file. It seems from the stacktrace documentation that this should work. Don

1 0

[stacktrace] Getting a stacktrace from unhandled exception in windows
by Don 11 Sep '17

11 Sep '17

I am trying use boost stacktrace to get a stack dump when my program encounters an unhandled exception under windows. I have installed a signal handler as described in the stacktrace documentation, and it gets called. However, the resulting stack trace is after everything has been unwound. For example, when I force a failure by dereferenceing a null pointer many levels down in my function hierarchy, the stack trace shows: 0# boost::stacktrace::detail::this_thread_frames::safe_dump_to_impl<char const *> at f:\home\tools\boost\boost\stacktrace\safe_dump_to.hpp:68 1# boost::stacktrace::safe_dump_to at f:\home\tools\boost\boost\stacktrace\safe_dump_to.hpp:120 2# my_signal_handler at f:\home\test\main.cpp:233 3# 0x5171407B 4# my_signal_handler at f:\home\test\main.cpp:235 5# 0x51713883 6# __tmainCRTStartup at f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c:603 7# WinMainCRTStartup at f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c:403 8# BaseThreadInitThunk in kernel32 9# RtlInitializeExceptionChain in ntdll 10# RtlInitializeExceptionChain in ntdll This is not particularly helpful, of course -- I want to know the call stack at the point of the failure. Is there any way to get that? What am I missing? Thanks, Don

2 2

Re: [Boost-users] [boost] Fit review - viboes
by P F 10 Sep '17

10 Sep '17

> On Sep 10, 2017, at 4:53 AM, Vicente J. Botet Escriba <vicente.botet(a)wanadoo.fr> wrote: > > > First sorry for the formatting of my original post. > > Le 09/09/2017 à 22:22, P F a écrit : >> >>> On Sep 9, 2017, at 6:27 AM, Vicente J. Botet Escriba via Boost <boost(a)lists.boost.org <mailto:boost@lists.boost.org>> wrote: >>> >>> Wondering if some parts should be moved to Boost.TypeTraits or reused from there (is_callable). >> >> But would that imply a C++98 compatible trait? Of course, I don’t see a reason to dump every trait used in boost into Boost.TypeTraits. > > I'm not talking about any traits. is_callable is special in the sense there is an equivalent in the C++ standard (is_invocable). > I don't think we should require that all the traits in Boost.Traits should be compatible C++98 when we are already in C++17. Ah yes, but I don't see why they need to be in Boost.TypeTraits. >> >>> >>> I'm missing the std::invoke function. >> >> What do you mean? std::invoke is provided by C++17. There is fit::apply, which will work like std::invoke except fit::apply also uses constexpr and is defined as a function object(so it can be passed to other functions). > > Why not call it invoke? I was trying to stay consistent with boost libraries. >>> If the user can use those classes the documentaion must document them. I guess they are useful to build other adaptors. It is not clear whether the defined functions would use SFINAE or just fail when used with types that don't respect the requirements. While I'm generally for SFINAE, I understand that it will not be the case in order to improve the compile time. >> >> The goal is to be as transparent as possible. So if `foo(f)(x)` is equivalent to `f(x)`, then if `f(x)` causes substitution failure, then `foo(f)(x)` causes substitution failure. The same is true for constexpr and noexcept on compilers that support those well enough. > > E.g. > > assert(compose(f, g)(xs...) == f(g(xs...))); > > If f and g don't compose, would compose(f, g) SFINAE the operator() or just compile fail. If `f(g(xs…))` is a substitution failure then `compose(f, g)(xs…)` is a substitution failure. > > If it SFINAE, I could use compose(f, g) to check if f and g are composable. You need to check `compose(f, g)(xs…)`. >> >>> It is not clear if the functions can be final function objects or not. >> >> They can be. There is no such restriction mentioned for the `Callable` or `ConstCallable` concept. > > Oh, I see it now. > > I believe there is however an issue when you have more than one final function objet. Do you have a test with two function objects? > If I remember the issue was because we can not inherit from two wrapper classes doing perfect forwarding. > If you don't have the issue, I will base my implementation of the proposed overload on your implementation ;-) I added tests with two final objects and see no problem. I am not sure the issue you were seeing. >>> >>> Possible files contains details that could be shared in Boost or used from other Boost libraries >>> >>> https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/move.hpp <https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/move.hpp> - I believe Hana use something like this also to reduce the dependencies (compile footprint) >>> https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/forward.… <https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/forward.…> >> >> Well hana uses a static_cast. Here, I use a macro which uses a static_cast if possible, and then I fallback to a function on compilers that can’t handle the static_cast. > > What I mean is that IMHO Boost should solve these issues in a single way. If we don't want to use directly e.g. <utility> because it is heavy, we should provide the lighter components in Boost. I don't believe it is a good approach to redefine them in each library that needs such basic facilities.. Yes, I agree there should be a library for this. However, this doesn’t exists yet. In the future, I can factor this out and put it in a separate library, but right now, I am proposing the Fit library. >> >>> https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/noexcept… <https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/noexcept…> >>> https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/and.hpp <https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/and.hpp> - I believe Hana use something like this also to reduce the dependencies (compile footprint) >> >> Well, I dont know of a library in boost that implements the fast_and algorithm that works on gcc 4.6+ and msvc. > > We have std::conditional. If we have a better option (for some compiler version) this should go to the Core library as any library could profit from it. It should not go into Core, there should be a separate library for this. If we just dump random stuff into Core, it will become like Utility. > This is a basic feature. >> >>> https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/compress… <https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/compress…> >> >> I dont know of a library that implements this. There is Boost.CompressedPair, but that implementation wouldn’t work at all for the Fit library. > > My comment included shared. If your compressed pair is better, we should improve Boost.CompressedPair. Perhaps, but this class is to solve very specific cases for the Fit library, so its built and tested around that. Some compilers have problems dealing with complex inheritance when using constexpr, so it is not as aggressive about empty optimization as Boost.CompressedPair. >>> >>> Quite good butthe description of the semantic of the provided functions would need some extra wording. Maybe a section that states that the semantic expression is part of the constraints on the types. >> >> What do you mean is part of the constraints on the type? > > Usually we describe the expressions that the types must support on the requirements. You use a semantic clause as requirement. What I mean is that the semantic clause implies the expression must be well formed and so is a requirement on the concerned types. The expression is not required to be well-formed. > That is the semantic expression is used to define what the function does and is also contains constraints of a not named Concept. What I would like is split the requirements and what the function does. It doesn’t describe requirements on the types as those are listed in the documentation already. Rather it is showing the semantically equivalent behavior. So when you write `compose(f, g)(xs…)` you could paste `f(g(xs…))` and the program should be practically equivalent even when the replacement happens in a decltype, noexcept, constexpr, or substitution failure. >> >>> >>> *Documentation:* >>> >>> In general: >>> >>> * Navigation only from the top of the page >>> >>> * Hyper links missing. >>> >>> * There is no link to real code from the examples. >> >> Most of the examples are a full running program that can be pasted in. > > Humm, I don't see the include on the code fragments, the needed using namespace, … Those don’t, I will try to setup a more fuller example. >> >>> >>> >>> In particular: >>> >>> *http://pfultz2.github.io/Fit/doc/html/doc/src/gettingstarted.html* <http://pfultz2.github.io/Fit/doc/html/doc/src/gettingstarted.html*> >>> >>> An explanation of the BOOST_FIT_LIFT limitations would be more than welcome. >> >> Good point. > Could you tell us here what they are? in detail? The limitation is in constexpr, but this only applies to c++14. This is because `BOOST_FIT_LIFT` uses a generic lambda. >> >>> >>> Typo: last right parenthesis in >>> >>> // Pipable sum >>> BOOST_FIT_STATIC_LAMBDA_FUNCTION(sum) = pipable([](auto x, auto y) >>> { >>> return x + y; >>> }); >>> >>> It is not clear if the following is correct in the body of a function >>> >>> auto sum = pipable([](auto x, auto y) >>> { >>> return x + y; >>> }; >> >> That needs to be corrected. > > Could you confirm that the previous code without using the BOOST_FIT_STATIC_FUNCTION is valid? Which one? You can’t write `BOOST_FIT_STATIC_FUNCTION(sum)` in c++14, however, in c++17 that is possible. > If yes I believe that the documentation could use this form as far as it is inside the body of a function. I was trying to demonstrate how to write functions other people can use. >>> >>> >>> *http://pfultz2.github.io/Fit/doc/html/doc/src/example_overloading.html* <http://pfultz2.github.io/Fit/doc/html/doc/src/example_overloading.html*> >>> >>> Typo: >>> >>> Before >>> // Check that T has member function for operator* and ope > >>> After // Check that T has member function for operator* and operator-> > > Note the typo above. Yea got it. >> *http://pfultz2.github.io/Fit/doc/html/doc/src/more_examples.html* <http://pfultz2.github.io/Fit/doc/html/doc/src/more_examples.html*> >>> >> >>> >>> My question is how both pipe operator overloads interact. >> >> How so? > > My bad. Each overload applies to different types, so that there shouldn't be no conflict. > > BTW, is operator|() defined only for pipable_adaptor<F>? Essentially yes. > > Could the user define a function object that is a pipable_adaptor for your library and it is also a pipable_xxx for the range library? What do you mean? > >> >>> >>> >>> >> >>> >>> Static Function Adaptor >>> >>> I would say "It has an additional requirement that the *class****function* is |DefaultConstructible|:" > > Don't forget this one. got it. >>> >>> >>> >>> *http://pfultz2.github.io/Fit/doc/html/doc/src/concepts.html* <http://pfultz2.github.io/Fit/doc/html/doc/src/concepts.html*> >>> ConstFunctionObject >>> >>> I would like to note that this concept is not representable using the Concept TS as it is quantifying universally on the Ts (args) parameters. >>> >>> The same applies to UnaryFunctionObject, BinaryFunctionObject >>> >>> Wondering if the documentation should use the term Concepts then. >> >> The purpose of the Concepts section is to document the type requirements. The current standard may not be able to check those type requirements in its current form, but there could be future versions of C++ that can check these type requirements. > > No, they couldn't if they are based on the Concept TS. The Concept TS doesn't have universal quantification, and I believe it wouldn't never had it from what the authors think about this feature. I agree, but it doesn’t mean we won’t have a future sematic-based concepts added that actually will help simplify generic programming. >> >>> >>> >>> The use of expresion "Is an object with ..." is confusing. What are we qualifying the type or the instance? >> >> This means the type is an object(ie scalar, array, union, or class). Of course, an array or union cannot have a call operator, so this only applies to classes and scalars that are pointers. > I believe it is better to use the term "type" here. It is a “type” but fulfills the requirements of `std::is_object`. >> >>> >>> EvaluatableFunctionObject >>> >>> It is not clear why this kind of FunctionObjects is useful >> >> This mainly used by the `fit::eval` and `fit::apply_eval` functions. > > I mean, it is not clear in this section, and some clarification is needed here. >> >>> >>> >>> Callable >>> >>> I believe we have moved to call this Invocable in the standard. But again, I believe that you want to quantify universally the arguments, isn't it? >> >> That is possible to check with the current C++(hence `is_callable`). This should be renamed to `Invocalbe` and `is_invocable`. > > Well is_invocable requires to know the type of the arguments. I believe that your Callable doesn't require to know with with types the function can be called. Could you confirm? Callable needs the type of the arguments, that is how `is_callable` is written. >>> >>> UnaryCallable >>> The name doesn't convey that it is *Const*Callable > > Any concern here? Since there is no standard UnaryCallable, I thought maybe I could sneak const in. I guess not. I will rename them to UnaryConstCallable. >>> >>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/compose.html <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/compose.html> *The requirements don't state clearly the constraints on the input parameters of f and the result of g, except by the semantic expression. This is a general remark. I suspect that you mean the semantic expression must be well formed. But, is this SFINAE friendly or is this a requirement? >> >> It is sfinae-friendly. > Could you add it to the reference documentation. This is an important feature. > In the standard they use "This function should not participate in overload resolution until ... or something like that. Is this really necessary? I think I would need to document when I change the semantic equivalence of the expression, not when I preserve it. I think it would be better in the definitions section to discuss the transparency aspect of the adaptors. >>> >>> Typo "Proposal for C++ Proposal for" >>> P0051 original proposal uses overload_linearly/overload (as Boost.Hana) instead of conditional/match. Wondering if those names aren't more clear. >> >> I really hate the name overload_linearly. Its long and doesn’t describe what it does. > > I don't find that conditional/match describe what they do. This is the eternal naming issue :) Its called `match` so it picks the best match using C++ overload resolution. Its also used for a form of pattern matching in visitors. I could use the name `overload`, but there a different ways of overloading. This is why I chose `match`. Its called `conditional` because it takes functions with conditions, and picks the first one. Perhaps the name `select` or `prefer` could be used. I am not sure. >>> >>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/implicit.html* <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/implicit.html*> >>> >>> Is implicit a StaticFunctionAdaptor? >> >> Yes. >> >>> Shouldn't StaticFunctionAdaptors have Functions as parameters? >> >> What do you mean? > That implicit has a template, not a class :( I should make the definition more flexible then. >> >>> Why this pattern respect the DRY principle (we don't repeat S), I believe it abuses of implicit conversions. >> >> Well, there is a caveat when someone uses ``auto`, like in your example: >> >> auto ptr = create_msg(); > yes, this is the caveat of returning a proxy that is convertible to anything. Could you warm the user in the documentation of this possible bad usage? >> >> There is a guard to prevent this, but it doesn’t work in C++17. > Could you elaborate? The guaranteed elision is in C++17 prevents this. As the class returned can only be copied by implicit conversion, by the copy elision makes this possible. >> >>> http://pfultz2.github.io/Fit/doc/html/include/boost/fit/indirect.html <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/indirect.html> >>> Wondering if it could be worth adding some preconditions as I guess that the function call >>> >>> indirect(f)(xs...) >>> >>> will be undefined if f is null >> >> That is true if `f` is a pointer, but is not true for all dereference operators. > > For example? http://pfultz2.github.io/Fit/doc/html/doc/src/faq.html#q-is-the-reinterpret… >>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/mutable.html <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/mutable.html> *Example of bad usage would be welcome.**Why Fit uses always const? **Why not use a reference to the function object instead? >> >> There is no way to safely manage the lifetime with a reference. > I was talking of reference_wrapper. > > IIUC, mutable should be used *only* to wrap existing functions that where no const but that don't modify the object (but it is a3rd party code and cannot be changed). I'm wrong? I believe, or if the mutations dont matter(perhaps it is just a cache). >>> Is there a safe way to use MutableFunctionObjects with Fit? >> >> Yes, you can use `std::ref. > > But reference_wrapper is a ConstFunctionObject. > I mean when mutable_ is safe? The 3rd party use case? Yes pretty much. > Do you have a good example of MutableFunctionObject that is safe? Well if the mutations don’t matter. Perhaps there is a cache, and so if the value isn’t there it just recomputes it. > After all I wonder if Mutable is the correct name. In C++ mutable means modifiable by a const function. I'll suggest NonConst as the function applicable to non-const objects. Well mutable is an actual keyword in the language, that is why I chose that. >>> http://pfultz2.github.io/Fit/doc/html/include/boost/fit/protect.html <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/protect.html> It is not clear to me what this useful for. Could you elaborate? >> >> When you want `bind` or `lazy` to capture a bind expression instead of evaluating it. > > and ... could you elaborate? Could you show how we can do it without fit::protect and with? You can’t do it without fit::protect, unless you use boost::protect. >> >>> Is there a typo here >>> assert(lazy(f)(protect(lazy(g)(_1)))() == f(lazy(g)(_1))) ^ Shouldn't it be assert(lazy(f)(protect(lazy(g)),_1)() == f(lazy(g)(_1))) >> >> Nope, that is correct. > > It is incoherent with the example. So maybe the example is wrong > > auto lazy_apply = lazy(apply)(protect(lazy_id), _1);` > > Or I'm missing something In the semantic requirements it assumes only a unary function. I could add a binary version in the semantic requirements. >> >>> >>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/result.html*** <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/result.html***> >>> This adaptor converts explicitly the result of the call to the type. Have you considered `convert_to`? >> >> It also adds a `result_type` to the function. Its mainly used to annotate function with the result type, which can be useful for fit::fix or Boost.Variant visitors. The documentation could make this clearer. > > Yes, I know that knowing the result type allows to optimize visitors. What is the main intent? to force the conversion or to have a way to retrieve the result type of a function object? Both actually. > The name should convey the main intent. > We have std::result_of until C++14 and invoke_result since C++17 to get the result type. Those aren’t the same as they try to deduce the type. The result adaptor provides a way to know the result type without deduction. >> >>> >>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/reveal.html* <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/reveal.html*> >>> >>> as_failures, with_failures, .... /adaptors/ don't appear on the index. >> >> You mean the table of contents? Yea, for them to appear there they need to be moved to a different section, with a header for each section. > You have items in the index that don't have his own file, e.g. http://pfultz2.github.io/Fit/doc/html/include/boost/fit/placeholders.html#u… <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/placeholders.html#u…>, so you should be able to add to it anything without needed a file, isn't it? Yes, but these would go under the adaptors section, which they don’t belong. >>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/static.html*** <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/static.html***> >>> >>> What are the differences of this adaptor and the macro STATIC_FUNCTION? >> >> STATIC_FUNCTION just declares a function objects at namespace or global scope, which requires the function to be constexpr constructible. The `static_` adaptor is to declare an adaptor that does not have a constexpr constructor. > > It is weird the example don't show the specific case as it uses static_ at global global scope. Could you show another example that is not at the namesapce o global scope. The purpose is to use at global or namespace scope, but the example should be update to use `BOOST_FIT_STATIC_FUNCTION`. > > Why static_ couldn't declare its default constructor constexpr? > I believe the description is on the other sense, which is why it is confusing. static_ requires a default constructor but don't requires the constructor to be constexpr and don't provides one constexpr default constructor It does provide constexpr constructor. Which is why it is useful because you can constepxr initialize a function object without a constexpr constructor. > , but I suspect that if the default constructor is constexpr it should work also. IIUC, you are saying that if it is the case then it is better to use the macro BOOST_FIT_STATIC_FUNCTION. They both can be used together. Although `static_` can be used at class scope. >>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/unpack.html* <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/unpack.html*> >>> >>> Why name it unpack instead of apply like in C++17? >> >> First, it doesn’t have the same signature as std::apply. > > Because you curry the function? Kind of. It is an adaptor. It also can take multiple sequences. >> Secondly, its very confusing, as ‘apply' generally means function applications especially in boost. So I would like to avoid this confusion. > > We are doing a function application here, isn't it? Eventually yes, but so does all the other adaptors. It doesn’t mean the other adaptors should be named apply either. >> >>> Need to introduce the Sequence concept and how it is customized? >> >> Hmm that is probably a better way to define it. >> >>> unpack_sequence? How unpack_sequence is used by unpack? >>> >>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/unpack_sequence.html*** <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/unpack_sequence.htm…> >>> Why unpack_sequence, and not the tuple-like traits? >> >> Not every sequence could be defined with indices. > For example? fit::pack has no index-based access, or if the sequence is defined as: auto seq = [](auto f) { reuturn f(1, 2, 3); }; >> >>> Is unpack_sequence defined if the class defines the tuple-like traits? >> >> No because they are not sfinae-friendly. > Why? Could you elaborate? The standard mandates that they are not sfinae-friendly. See: https://stackoverflow.com/a/41708982/375343 <https://stackoverflow.com/a/41708982/375343> As such there is no way to know if a type implements the std tuple-like traits. >> >>> Aside the example, it is not defined what the user must define. >> >> That could probably use more explanation. >> >>> What the member function apply must return? >> >> The result of calling `f`. > > These things need to be defined in the documentation. > > When a user specialize unpack_sequence, what are the constraints of the parameter F. Should it be ConstCallable? It will always be a FunctionObject. >> >>> How the unpack_sequence parameter and the Sequence parameter of member function apply are related? >>> I don't understand >>> >>> template<class F, class Sequence> >>> constexpr static auto apply(F&& f, Sequence&& s) BOOST_FIT_RETURNS >>> ( >>> s(std::forward<F>(f)) >>> ); Is a Sequence a callable taking a Callable or there is a type here? Is there a missing return? >>> >>> I suspect it should be >>> >>> template<class F, class Sequence> >>> constexpr static auto apply(F&& f, Sequence&& s) BOOST_FIT_RETURNS >>> ( >>> std::forward<F>(f)(s0, ,, sk); >>> ); >>> If this is correct, does it means that unpack just forwards to unpack_sequence? >> >> That example, I guess is a little confusing. As the `Sequence` is a function like fit::pack, but yes unpack calls unpack_sequence to do the unpacking for a single sequence. > Please, fix it. >> >>> Does the default specialization make use of INVOKE? >> >> Its not needed, as the function passed to `unpack_sequence` will always have a call operator. > I was talking of what the *default* specialization for tuple does. For any specialization, INVOKE is not necessary. >>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/repeat.html* <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/repeat.html*> >>> >>> Add requirement on the function parameter that must be a Unary function such that f(f(x)) is well formed. >> >> True, but the first call to repeat doesn’t need to be unary. > And what it could be? You lost me. Its the parameters passed by the user. That is `repeat(n)(f)(1, 2)` will call `f(1, 2)` the first time, and every time after that it will call `f` with the result of `f`. >>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/arg.html*** <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/arg.html***> >>> What is the rational for the choice of been 1-based? >> >> This is to match how placeholders work. So arg<1> and _1 are the same number. > I was sure that you had a good reason:) I went back and forth on this, but hana uses the convention. >>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/decay.html* <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/decay.html*> >>> >>> Why not decay_copy? >> >> It doesn’t always copy, like when passing reference_wrapper. > > It copies the reference_wrapper, isn't it? Nope, it returns a reference to the object being wrapped. >> >>> >>> >>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/placeholders.html*** <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/placeholders.html***> >>> Wondering if it is not better to locate them in a placeholders namespace, so that we can avoid possible collisions with other placeholders. >>> >>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/placeholders.html#unamed-placeholder* <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/placeholders.html#u…> >>> >>> The same here >> >> Ah, it could cause collision if users do `using boost::fit`. > Would you move to a nested placeholders namespace? Yes, I added a issue. >>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/apply.html*** <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/apply.html***> >>> Confusion with std::apply. is this related to std::invoke? >> >> Its not like std::apply, its like hana::apply. > > I know that it is not like std::apply, hence the possible confusion. >> Of course, maybe I could rename this to fit::invoke, and then add a fit::apply, that only calls the call operator. > > I don't see any reason to use a different name when the function are curried. fit::apply is not curried. >>> *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/tap.html* <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/tap.html*> >>> >>> How this is related to the tee unix command? >> >> I am not that familiar with unix tee. > https://en.wikipedia.org/wiki/Tee_(command) <https://en.wikipedia.org/wiki/Tee_(command)> It is kind of similar, but its not saving a file. >>> *http://pfultz2.github.io/Fit/doc/html/doc/src/configurations.html***Which <http://pfultz2.github.io/Fit/doc/html/doc/src/configurations.html***Which> ones? >>> > There are none now. Are there some or should this section be removed? Yea, for some reason they dont show. I dont know if something happened with the boost conversion. You can see the pre-boost version of this page here: http://fit.readthedocs.io/en/latest/doc/src/configurations.html <http://fit.readthedocs.io/en/latest/doc/src/configurations.html> Also, I added issues for a lot of the points raised in the email here: https://github.com/pfultz2/Fit/issues <https://github.com/pfultz2/Fit/issues> Let me know if I missed anything. Thanks, Paul

1 0

Re: [Boost-users] Fit review
by Andrea Bocci 09 Sep '17

09 Sep '17

Hi, maybe it's too late, but I hadn't seen this library before on the boost-users list. Would you consider a different name ? In the context of mathematical and statistical analysis, a "fit" is something else entirely - still related to "functions". Reading that "Fit is a header-only ... library that provides utilities for functions..." I was expecting something quite different ;-) Anyway, good job with library itself. Regards, .Andrea

2 1

Re: [Boost-users] [boost] Fit review - viboes
by P F 09 Sep '17

09 Sep '17

> On Sep 9, 2017, at 6:27 AM, Vicente J. Botet Escriba via Boost <boost(a)lists.boost.org> wrote: > > Hi, > > here it is my review. > > I believe that Boost.Fit should be*accepted*. Thanks for the review. > > > > *Design* > > The design is sound and clean. > > I have some concerns respect the the ConstFunctionObjects that I believe should merit an explanation on a rationale section. Why the library support only Const function objects? This is described in the FAQ, but maybe it should be moved to a rationale section. The main reasons are they are error prone, and in C++11 can’t be supported with constexpr. > > Wondering if some parts should be moved to Boost.TypeTraits or reused from there (is_callable). But would that imply a C++98 compatible trait? Of course, I don’t see a reason to dump every trait used in boost into Boost.TypeTraits. > > I'm missing the std::invoke function. What do you mean? std::invoke is provided by C++17. There is fit::apply, which will work like std::invoke except fit::apply also uses constexpr and is defined as a function object(so it can be passed to other functions). > > The_adaptor<> are not documented. Maybe in the definitions section I can go over how `foo(f)` is the same as `foo_adaptor<F>{f}`. > The utility of those classes is not documented. The are mainly useful for when you want to type-based transformations to functions. This is common when you need to pass a function as a template parameter(like with the comparator in std::map, the deleter in std::unique_ptr, or when using Boost.MultiIndex). > If the user can use those classes the documentaion must document them. I guess they are useful to build other adaptors. It is not clear whether the defined functions would use SFINAE or just fail when used with types that don't respect the requirements. While I'm generally for SFINAE, I understand that it will not be the case in order to improve the compile time. The goal is to be as transparent as possible. So if `foo(f)(x)` is equivalent to `f(x)`, then if `f(x)` causes substitution failure, then `foo(f)(x)` causes substitution failure. The same is true for constexpr and noexcept on compilers that support those well enough. > It is not clear if the functions can be final function objects or not. They can be. There is no such restriction mentioned for the `Callable` or `ConstCallable` concept. > *Implementation* > > Not seen in depth. > > It should use as much as possible Boost.Config and/or Boost.Predef Right now it uses sd-6 macros, but it could move to use Boost.Config(probably not Boost.Predef). > > Possible files contains details that could be shared in Boost or used from other Boost libraries > > https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/move.hpp - I believe Hana use something like this also to reduce the dependencies (compile footprint) > https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/forward.… <https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/forward.…> Well hana uses a static_cast. Here, I use a macro which uses a static_cast if possible, and then I fallback to a function on compilers that can’t handle the static_cast. > https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/noexcept… > https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/and.hpp - I believe Hana use something like this also to reduce the dependencies (compile footprint) Well, I dont know of a library in boost that implements the fast_and algorithm that works on gcc 4.6+ and msvc. > https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/compress… <https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/compress…> I dont know of a library that implements this. There is Boost.CompressedPair, but that implementation wouldn’t work at all for the Fit library. > https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/constexp… > https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/intrinsi… <https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/intrinsi…> This probably could be factored out in a separate boost library, which might be useful for other heavy metaprogramming libraries. > https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/pp.hpp > https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/remove_r… > https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/result_o… > https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/static_c… > https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/using.hpp > > It uses a lot of macros that make complex the understanding of what is behind. On the same file https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/compose.hpp and only on 169 lines > BOOST_FIT_INHERIT_CONSTRUCTOR, BOOST_FIT_RETURNS_CLASS, > BOOST_FIT_SFINAE_RESULT, BOOST_FIT_MANGLE_CAST, BOOST_FIT_DECLARE_STATIC_VAR, BOOST_FIT_NOEXCEPT_CONSTRUCTIBLE, > BOOST_FIT_ENABLE_IF_CONSTRUCTIBLE, BOOST_FIT_JOIN *Documentation* Some of those are documented. The others I could add some more comments in the code to what those do exactly. > > Quite good butthe description of the semantic of the provided functions would need some extra wording. Maybe a section that states that the semantic expression is part of the constraints on the types. What do you mean is part of the constraints on the type? > It takes too much pages to see what the library proposes. > For some functions we would need more information, examples. See below the detailed > > *Potential usefulness of the library* > > Very useful. > > *Did you try to use the library? With which compiler(s)? Did you have any problems?*** > Not tried yet. > > *How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?*** > In-depth study of the documentation (about 5 h for this revision). > > *Are you knowledgeable about the problem domain?* > > In general, yes. > > *Were the concerns from the March 2016 review of Fit addressed?*** > I believe ;-) > > Best, > Vicente > > *Documentation:* > > In general: > > * Navigation only from the top of the page > > * Hyper links missing. > > * There is no link to real code from the examples. Most of the examples are a full running program that can be pasted in. > > > In particular: > > *http://pfultz2.github.io/Fit/doc/html/doc/src/gettingstarted.html* > > An explanation of the BOOST_FIT_LIFT limitations would be more than welcome. Good point. > > Typo: last right parenthesis in > > // Pipable sum > BOOST_FIT_STATIC_LAMBDA_FUNCTION(sum) = pipable([](auto x, auto y) > { > return x + y; > }); > > It is not clear if the following is correct in the body of a function > > autosum = pipable([](auto x, auto y) > { > return x + y; > }; That needs to be corrected. > > *http://pfultz2.github.io/Fit/doc/html/doc/src/example_print.html* > > I would suggest to use an heterogeneous tuple in the for_each_tupleexample. > > In addition use some kind of brackets to print the sequences and the tuples would help to identify what is been printed. I was trying to keep the example simple. However, with the print out its a little more confusing. > > > *http://pfultz2.github.io/Fit/doc/html/doc/src/example_overloading.html* > > Typo: > > Before > // Check that T has member function for operator* and ope After // Check that T has member function for operator* and opeerator-> > > I'm not sure the example is_derreferenceable is fair. Using is_detected, might be a little simpler, but it don’t think it would help overall. > > > *http://pfultz2.github.io/Fit/doc/html/doc/src/example_polymorphic_constructors.html* > > Maybe it is worth adding references to the proposals (P0318R0 and P0338R2) > > > *http://pfultz2.github.io/Fit/doc/html/doc/src/more_examples.html* > > Extension Methods > > It is not clear what numbers, filter and transform are in the example. I should add an implementation of those. > > I believe that the range proposal woul include the pipe operator. Although, there are some who don’t see the usefulness of it. > > My question is how both pipe operator overloads interact. How so? > > http://pfultz2.github.io/Fit/doc/html/doc/src/point_free.html > > typo > > Before > > |b(f)(x, y)| > > |after| > > > ||by(f)(x, y)|| > > > *http://pfultz2.github.io/Fit/doc/html/doc/src/definitions.html* > > It woul dbe great to have an example associated to each definition That is a good idea. > > Static Function Adaptor > > I would say "It has an additional requirement that the *class****function* is |DefaultConstructible|:" > > Decorator > I would say "The *resulting* Function Adaptor <http://pfultz2.github.io/Fit/doc/html/doc/src/definitions.html#function-ada…> may be an unspecified or private type.” Ok. > > Typo? > Some parts of the documentation provides > > > > *http://pfultz2.github.io/Fit/doc/html/doc/src/concepts.html* > ConstFunctionObject > > I would like to note that this concept is not representable using the Concept TS as it is quantifying universally on the Ts (args) parameters. > > The same applies to UnaryFunctionObject, BinaryFunctionObject > > Wondering if the documentation should use the term Concepts then. The purpose of the Concepts section is to document the type requirements. The current standard may not be able to check those type requirements in its current form, but there could be future versions of C++ that can check these type requirements. > > > The use of expresion "Is an object with ..." is confusing. What are we qualifying the type or the instance? This means the type is an object(ie scalar, array, union, or class). Of course, an array or union cannot have a call operator, so this only applies to classes and scalars that are pointers. > > Maybe it is worth defining FunctionObject. Trye, although I never use that concept, it would make sense for completeness sake. > > EvaluatableFunctionObject > > It is not clear why this kind of FunctionObjects is useful This mainly used by the `fit::eval` and `fit::apply_eval` functions. > > > Callable > > I believe we have moved to call this Invocable in the standard. But again, I believe that you want to quantify universally the arguments, isn't it? That is possible to check with the current C++(hence `is_callable`). This should be renamed to `Invocalbe` and `is_invocable`. > > Does your definition of INVOKE differs from the one on the standard? No, it shouldn’t, unless the standard doesn’t allow constexpr. > If yes, the differences should be mentioned. If not, the definition on the standard should be referenced. Would cppreference be acceptable? > > You use type T twice with different meaning > > "The type |T| satisfies |Callable| if" > > "if |f| is a pointer to member function of class |T|:" > > I believe that here the T are not the same. True, let me fix that. > > Are final function objects Callable, ConstCallable? Yes, why wouldn’t they be? > > > ConstCallable > The brief description is the same as the one for Callable > Is the definition of the second INVOKE different from the first one? No, it isn’t. The only difference is the f is of type `const T`. > > UnaryCallable > The name doesn't convey that it is *Const*Callable > > Metafunction and MetafunctionClass > it is not clear what those are, there is no brief description. I guess that this applies to f. > What do you mean by a type or a template? I see, that is a little confusing. These should follow the same definitions as in Boost.MPL. > > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/by.html* > > > It is not clear to me what > > by(p)(xs...) == p(xs)... mean > > > An example of `fit::by` without a function argument will be welcome. Good point. > > It is not clear how by_adaptor<Projection, F> and by_adaptor<Projection> can be used by the user? I could add an example using std::map. > Shouldn't those be hidden? No they shouldn’t be hidden. > > This is a genral remak, why F must be ConstCallable? For the same reason everything is ConstCallable. > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/compose.html *The requirements don't state clearly the constraints on the input parameters of f and the result of g, except by the semantic expression. This is a general remark. I suspect that you mean the semantic expression must be well formed. But, is this SFINAE friendly or is this a requirement? It is sfinae-friendly. > Can both function be final function objects? **** In compose? Any of the functions can be final. > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/conditional.html* > It is not clear what king of parameters this function could have (in particular in comparison with P0051). Does it accept function/data members pointers, final classes, references_wrappers, …? Yes, it takes any `ConstCallable` > > Typo "Proposal for C++ Proposal for" > P0051 original proposal uses overload_linearly/overload (as Boost.Hana) instead of conditional/match. Wondering if those names aren't more clear. I really hate the name overload_linearly. Its long and doesn’t describe what it does. > Why do we need to change the Boost.Hana names? Those names were chose before Boost.Hana. I use `conditional` because it was like a conditional block, especially when used with fit::if_. Perhaps, there is a better name. > There is also std::conditional :( Which really should’ve been called std::if_. > > Can more than 2 parameters be final function objects? Yes, of course. > > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/flip.html** > * > IIUC, F must not be BinaryCallable, but Callable with at least two arguments. True, let me update the documentation. > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/implicit.html* > > Is implicit a StaticFunctionAdaptor? Yes. > Shouldn't StaticFunctionAdaptors have Functions as parameters? What do you mean? > I named the `auto_cast` function `explicitly` to do a explicit conversion. > > Other uses of this pattern I've see are to create a buffer able to store a specific struct > > struct S; > S* ptr = create_msg(); > > create_msg returns an class that is convertible to a T* and that allocates sizeof(T) bytes of memory. Ah yes, for that too. > > Why this pattern respect the DRY principle (we don't repeat S), I believe it abuses of implicit conversions. Well, there is a caveat when someone uses ``auto`, like in your example: auto ptr = create_msg(); There is a guard to prevent this, but it doesn’t work in C++17. > Anyway, I wanted just to share another use case for implicit. > > http://pfultz2.github.io/Fit/doc/html/include/boost/fit/indirect.html > Wondering if it could be worth adding some preconditions as I guess that the function call > > indirect(f)(xs...) > > will be undefined if f is null That is true if `f` is a pointer, but is not true for all dereference operators. > > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/infix.html** > * > > One of the asked infix operations is pow. However we would like to evaluate from right to left and have the higher precedence than * x pow ypow z===pow(x, pow(y,z)) > x * ypow z===x * pow(y,z) x pow y* z===pow(x,y) * zWith the proposed infix notation this should be written > x <pow> (y<pow> z)===x * pow(y,z) x * (y<pow> z)===x * pow(y,z) (x <pow> y)* z===pow(x,y) * z > and the following would be surprising > x <pow> y<pow> z===pow(pow(x, y, z) x * y<pow> z===pow(x * y, z) x <pow> y*z===pow(x, y * z) It would work better for swap or compare (proposed operator <=>) as these functions are not associative. I believe a note should prevent the users for such bad use cases, for which it is better to don't define the infix operator. That is a good example to talk about. I will add that. > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/lazy.html* Note p0356r1. It would be good to have a comparison in order either to improve the proposal or your library. That seems more related to fit::partial. > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/match.html* Same comments than for fit::conditional. What are ex typo "Proposal for C++ Proposal for" > Can more than 2 parameters be final function objects? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/mutable.html *Example of bad usage would be welcome.**Why Fit uses always const? **Why not use a reference to the function object instead? There is no way to safely manage the lifetime with a reference. > Is there a safe way to use MutableFunctionObjects with Fit? Yes, you can use `std::ref. > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/partial.html* Are there any constraints on the type of xs. Shouldn't them be MoveConstructibles? That is true, since it decays the parameters. > http://pfultz2.github.io/Fit/doc/html/include/boost/fit/pipable.html > Are there any constraints on the type of x. No. > Shouldn't it be MoveConstructible? No, it is not necessary. Pipable does not capture the parameters by value, since it is almost always used in the same expression(ie `x | f(y)`). > http://pfultz2.github.io/Fit/doc/html/include/boost/fit/protect.html It is not clear to me what this useful for. Could you elaborate? When you want `bind` or `lazy` to capture a bind expression instead of evaluating it. > Is there a typo here > assert(lazy(f)(protect(lazy(g)(_1)))() == f(lazy(g)(_1))) ^ Shouldn't it be assert(lazy(f)(protect(lazy(g)),_1)() == f(lazy(g)(_1))) Nope, that is correct. > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/result.html*** > This adaptor converts explicitly the result of the call to the type. Have you considered `convert_to`? It also adds a `result_type` to the function. Its mainly used to annotate function with the result type, which can be useful for fit::fix or Boost.Variant visitors. The documentation could make this clearer. > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/reveal.html* > > as_failures, with_failures, .... /adaptors/ don't appear on the index. You mean the table of contents? Yea, for them to appear there they need to be moved to a different section, with a header for each section. > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/reverse_fold.html* > > reverse_fold is not right fold, as right fold is right associative, isn't it? True, it is right fold with the arguments flipped. > > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/rotate.html*** > Could you show a concrete use case? > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/static.html*** > > What are the differences of this adaptor and the macro STATIC_FUNCTION? STATIC_FUNCTION just declares a function objects at namespace or global scope, which requires the function to be constexpr constructible. The `static_` adaptor is to declare an adaptor that does not have a constexpr constructor. > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/unpack.html* > > Why name it unpack instead of apply like in C++17? First, it doesn’t have the same signature as std::apply. Secondly, its very confusing, as ‘apply' generally means function applications especially in boost. So I would like to avoid this confusion. > Need to introduce the Sequence concept and how it is customized? Hmm that is probably a better way to define it. > unpack_sequence? How unpack_sequence is used by unpack? > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/unpack_sequence.html*** > Why unpack_sequence, and not the tuple-like traits? Not every sequence could be defined with indices. > Is unpack_sequence defined if the class defines the tuple-like traits? No because they are not sfinae-friendly. > Aside the example, it is not defined what the user must define. That could probably use more explanation. > What the member function apply must return? The result of calling `f`. > How the unpack_sequence parameter and the Sequence parameter of member function apply are related? > I don't understand > > template<class F, class Sequence> > constexpr static auto apply(F&& f, Sequence&& s) BOOST_FIT_RETURNS > ( > s(std::forward<F>(f)) > ); Is a Sequence a callable taking a Callable or there is a type here? Is there a missing return? > > I suspect it should be > > template<class F, class Sequence> > constexpr static auto apply(F&& f, Sequence&& s) BOOST_FIT_RETURNS > ( > std::forward<F>(f)(s0, ,, sk); > ); > If this is correct, does it means that unpack just forwards to unpack_sequence? That example, I guess is a little confusing. As the `Sequence` is a function like fit::pack, but yes unpack calls unpack_sequence to do the unpacking for a single sequence. > Does the default specialization make use of INVOKE? Its not needed, as the function passed to `unpack_sequence` will always have a call operator. > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/capture.html*** > Please, could you show how it is more flexible than lambda captures in C++? You can’t capture by value or reference dependending if it is an lvalue when using lambda captures. > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/if.html* > > What happens when the parameter is false_type? SFINAE? Essentially yes. There is no call operator when its false. > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/limit.html*** > if a function object is overloaded with 2 and 3 parameters, would limit be useful or it is only useful when the number of parameters is fixed? Yes its still useful, as it only sets a max limit. > I believe this is answered in http://pfultz2.github.io/Fit/doc/html/doc/src/partialfunctions.html, however I believe it merits a clarification here. > > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/repeat.html* > > Add requirement on the function parameter that must be a Unary function such that f(f(x)) is well formed. True, but the first call to repeat doesn’t need to be unary. > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/repeat_while.html* > The same here. > > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/arg.html*** > What is the rational for the choice of been 1-based? This is to match how placeholders work. So arg<1> and _1 are the same number. > Could you add a rationale in the doc? Yea. > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/construct.html* > > Maybe add a reference to the factory proposal p03382. Do you have a link? > > What happens when the parameter is not a T is not constructible from the params? SFINAE? Yes. > > What happens when the parameter is not a MetafunctionClass? SFINAE? Yes. > > I believe Boost.Hana uses make instead of construct. That is a possible name. > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/decay.html* > > Why not decay_copy? It doesn’t always copy, like when passing reference_wrapper. > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/identity.html *is identity a function or a function object? do we need identity()(x)? It can be treated as a function. I should update the synopsis to use a function signature instead. > > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/placeholders.html*** > Wondering if it is not better to locate them in a placeholders namespace, so that we can avoid possible collisions with other placeholders. > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/placeholders.html#unamed-placeholder* > > The same here Ah, it could cause collision if users do `using boost::fit`. > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/function_param_limit.html*** > |function_param_limit is not a Metafunction. "|The|function_param_limit| metafunction …" It is a metafunction(doing ::type works), but its actually more like a type trait. > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/is_callable.html*** > F must be Callable can not be a requirement ;-) > > Add reference to C++17 trait is_invocable. > > Wondering if we should have it in type_traits, if not already there. > > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/apply.html*** > Confusion with std::apply. is this related to std::invoke? Its not like std::apply, its like hana::apply. Of course, maybe I could rename this to fit::invoke, and then add a fit::apply, that only calls the call operator. > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/function.html* > > "By default, all functions defined with|BOOST_FIT_STATIC_FUNCTION| use thereveal <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/reveal.html> adaptor to improve error messages." > > How to change this default? There isn’t a way. Perhaps I could add PP define to change it, but I wonder if its better to have some way to change it on a per-variable basis. > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/lift.html*** > WhyBOOST_FIT_LIFT_CLASSdoesn't defines a instance as do BOOST_FIT_STATIC_FUNCTION? That maybe a better approach. Maybe I can call it BOOST_FIT_LIFT_FUNCTION. > > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/pack.html*** > How this is related with fit::capture? fit::capture uses fit::pack, but also does a pack_join to combine the pack and the parameters together. > > *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/tap.html* > > How this is related to the tee unix command? I am not that familiar with unix tee. > > *http://pfultz2.github.io/Fit/doc/html/doc/src/configurations.html***Which ones? > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[gsoc] Change in Google Summer of Code admin
by Niall Douglas 08 Sep '17

08 Sep '17

Dear all, Google Summer of Code 2017 has ended with another successful summer of student coding with probably the highest calibre year we've ever seen. After four years as lead admin for Boost Summer of Code, my time has come to an end. I'll be making way for David Bellot, long time mentor at Boost GSoC and maintainer of Boost.uBLAS. Please join me in welcoming David as new lead admin. I'll be staying on as backup admin next summer to help David settle in. My time as Boost Summer of Code admin has certainly been eventful with lots of surprises, ups and downs. The fact these surprises did not turn into crises is due in large part to a few people in particular who went far beyond the call of duty: * Jon Kalb, who went to bat for the students repeatedly in multiple venues and finding tens of thousands of dollars when it was needed. * Boris Schäling, whom I replaced as lead admin and who acted as backup admin for some years, who also managed to arrange tens of thousands of dollars of sponsorship when it was needed most. * Bryce Adelstein Lelbach, for acting as backup admin these past few years. * Andrew Sutton, the lead GSoC admin before Boris, who gave such detailed and useful early advice and materials on how to best navigate the treacherous waters of Google Summer of Code! And finally to all the mentors who so generously volunteered their time, and to the students every single one of whom successfully finished their projects in my time as admin despite problems with sickness, deaths in close family etc. Some of those students have gone on to become mainstays of the C++ conference circuit, famous names in their own right. I'm sure they would have been so without Google Summer of Code, but I'd like to think that it helped bring them to Boost rather than them getting into C++ via elsewhere. Thank you students! Regards, Niall

5 6

echo server modification causes undefined behaviour
by Peter Koukoulis 07 Sep '17

07 Sep '17

I'm a database developer and I'm using boost for the first time.I've copied the echo server & client example from the Boost website and modified it somewhat so that when I receive a SQL statement from the client I pass pass it onto a function that performs the db execution. Once executed Ireply back to the client how many rows were affected. The code works , if I send only a single request at a time from the synchronous client, so I modified the async server so that the read is a read_until.The change now crashes the server. Could somebody please help ?Attached is the code.

2 3

[release] Boost 1.65.1
by Daniel James 07 Sep '17

07 Sep '17

Release 1.65.1 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/history/version_1_65_1.html> You can also download directly from: <https://dl.bintray.com/boostorg/release/1.65.1/> To install this release on your system, see <http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Vladimir Prus Rene Rivera Marshall Clow Eric Niebler Daniel James Beman Dawes

3 2

[Multi_Index] Mixing composite keys with chained pointer value types
by Nick Gordon 07 Sep '17

07 Sep '17

I have a multi-index container that I'm using to fulfill two search cases. The objects are all derived from `Base`, which is a pure virtual class. To store the `Derived` objects I'm using unique_ptrs as the container value type. However, I need to store the objects uniquely on a composite of a member string, and an enum type used for runtime reflection without dynamic_cast-ing or typeid-ing. So, I want to use a composite key to be unique over both of these things. However, it doesn't compile (why else would I be posting). The minimum source code I can construct to fail using GCC 5.4.0 or Clang 3.9.1 with Boost 1.62 is attached in test.cpp, and the compilation error from my version of clang is attached as compilation-error.txt. I compile it with `clang++ --std=c++14 test.cpp`. I'm not familiar with how the library works, but my surface-level understanding is it seems that the chained_ptr is trying to act on the value type, but the operand being passed is actually one of the composite key expressions. I couldn't find much about how these two mechanisms interact. In my case it's not strictly necessary that I have this type-determining enum value, but it's cheaper than dynamic casting, and it makes my life simpler, because there are also many cases where we want to print the class name of the derived instance. There are other approaches, but I don't want to use them if I can get this working :) -Nick Gordon

2 1

Delete and free all elements of ptr_vector
by Florian Lindner 07 Sep '17

07 Sep '17

Hello, in my project we have a simple ptr_vector that has a member function: void deleteElements () { for ( CONTENT_T * elem : _content ) { assertion ( elem != NULL ); delete ( elem ); } } I want to replace this ptr_vector with boost::ptr_vector. However, I haven't found a way to delete and free all pointers stored in the container. How can I do that? Thanks, Florian

3 5

[Test] Can't build Boost Test 1.65.0 with Visual Studio 2013
by Kerry, Richard 07 Sep '17

07 Sep '17

I've just tried building Boost Test 1.65.0 with Visual Studio 2013 (ie msvc-12) and it doesn't seem to work, showing a compiler internal error. Can anyone advise what I might be doing wrong. Or whether a newer (or older) release fixes this issue. I've also tried 1.64.0 with an identical looking failure. Details below. Regards, Richard. I run : >b2 --with-test (as in the docs, though I'm not specifying address-model, link, --prefix or install. Having tried address-model and link as documented they appear to show the same fault). And then, after some messages, including "- test : building" (and nothing else listed as building), I get some messages starting: ...patience... ...found 1239 targets... ...updating 28 targets... compile-c-c++ bin.v2\libs\chrono\build\msvc-12.0\debug\link-static\threading-multi\chrono.obj chrono.cpp C:\Users\kerryr01\Downloads\Boost\boost_1_65_0\boost/type_traits/common_type.hpp(43) : fatal error C1001: An internal error has occurred in the compiler. (compiler file 'msc1.cpp', line 1325) To work around this problem, try simplifying or changing the program near the locations listed above. Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information Internal Compiler Error in C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\cl.exe. You will be prompted to send an error report to Microsoft later. call "C:\Users\kerryr01\AppData\Local\Temp\b2_msvc_12.0_vcvarsall_x86.cmd" >nul cl /Zm800 -nologo @"bin.v2\libs\chrono\build\msvc-12.0\debug\link-static\threading-multi\chrono.obj.rsp" ...failed compile-c-c++ bin.v2\libs\chrono\build\msvc-12.0\debug\link-static\threading-multi\chrono.obj... This is followed by a number of similar blocks of messages relating to: chrono.obj, thread_clock.obj, process_cpu_clocks.obj, cpu_timer.obj, auto_timers_construction.obj, execution_monitor.obj and others. [Blue line] Richard Kerry BNCS Engineer, SI SOL Telco & Media Vertical Practice T: +44 (0)20 3618 2669 M: +44 (0)7812 325518 4 Triton Square, Regent’s Place, London NW1 3HG richard.kerry(a)atos.net<mailto:richard.kerry@atos.net> [Atos logo] This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.</ Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading names used by the Atos group. The following trading entities are registered in England and Wales: Atos IT Services UK Limited (registered number 01245534), Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud Company Limited (registration number 08011902). The registered office for each is at 4 Triton Square, Regent’s Place, London, NW1 3HG.The VAT No. for each is: GB232327983. This e-mail and the documents attached are confidential and intended solely for the addressee, and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email.

2 2

flat_(multi)map/set and Compare::is_transparent
by TONGARI J 06 Sep '17

06 Sep '17

Hi, Since C++14, the standard introduces transparent comparators for heteregeneous lookup, but seems that the Boost's flat counterparts don't take advantage of this yet. Is there any plan to support transparent comparators? Thanks.

2 1

[Boost.Container] Boost.Container support for transparent comparators
by dariomt＠gmail.com 05 Sep '17

05 Sep '17

Hi, I see this trac ticket [1] with a feature request, and I'd like to know if there has been any progress on it. It doesn't look like it is in the latest release yet. Thank you! [1] https://svn.boost.org/trac10/ticket/11780

3 3

Boost 1.65.2 Release Candidate 2
by Daniel James 03 Sep '17

03 Sep '17

The second release candidates for the 1.65.1 release are now available at: <https://dl.bintray.com/boostorg/release/1.65.1/> The SHA256 checksums are as follows: df7bea4ce58076bd8e9cd63966562d8cf969b431e1c587969e6aa408e51de606 boost_1_65_1_rc2.7z 9807a5d16566c57fd74fb522764e0b134a8bbe6b6e8967b83afefd30dcd3be81 boost_1_65_1_rc2.tar.bz2 a13de2c8fbad635e6ba9c8f8714a0e6b4264b60a29b964b940a22554705b6b60 boost_1_65_1_rc2.tar.gz d1775aef807bd6a14077b450cce2950d8eacd86aaf51015f79e712917f8cc3c2 boost_1_65_1_rc2.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.

1 1

[release] Boost 1.65.1 Release Candidate 1
by Daniel James 01 Sep '17

01 Sep '17

The release candidates for the 1.65.1 release are now available at: <https://dl.bintray.com/boostorg/release/1.65.1/> The SHA256 checksums are as follows: 9b440d8167043c8d70326d8a5d4df98a59abb40be7d68f51e75ea95ea24d84f3 boost_1_65_1_rc1.7z fbd5663c748a88479adb4106c8a12009b149e602dec4b40a4a778381a33cf3ce boost_1_65_1_rc1.tar.bz2 b1b18d658cc0ff8a5030b29f4ed41de1826281fcb52fc1073b106c5802a570bd boost_1_65_1_rc1.tar.gz 542624352b2c3fd6a76c98624f90d2c0e62dd810ec6cc9fdae831677c7aa1fbf boost_1_65_1_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.

2 2

Help on boost::iostreams::gzip_compressor: Linker error
by Uthpal Urubail 31 Aug '17

31 Aug '17

Experts, I am getting below linker error on gzip compressor usage. Any help is highly appreciated. I have already tried linking boost_iostreams.lib & zlib.lib Code Description LNK2001 unresolved external symbol "int const boost::iostreams::zlib::default_compression" (?default_compression@zlib@iostreams@boost@@3HB) & Code Description LNK2019 unresolved external symbol "protected: __cdecl boost::iostreams::detail::zlib_base::~zlib_base(void)" (??1zlib_base@detail@iostreams@boost@@IEAA@XZ) referenced in function "int `public: __cdecl boost::iostreams::detail::zlib_compressor_impl<class std::allocator<char> >::zlib_compressor_impl<class std::allocator<char> >(struct iostreams::detail::zlib_params const &)'::`1'::dtor$0" (?dtor$0@?0???0?$zlib_compressor_impl@V?$allocator@D@std@@@detail@iostreams@boost@@QEAA@AEBUzlib_params@23@@Z@4HA) Regards, UJ

1 0

UDP Echo Server
by Mark Hieber 25 Aug '17

25 Aug '17

Hi,

3 3

[fiber][asio] Problem running http://www.boost.org/doc/libs/1_65_0/libs/fiber/examples/asio/autoecho.cpp
by Mark Hieber 24 Aug '17

24 Aug '17

Hi, I am using cmake 3.9.1 and Boost 1.65.0. I have downloaded the autoecho.cpp file and the corresponding yield.hpp, detail/yield.hpp and round_robin.hpp from http://www.boost.org/doc/libs/1_65_0/libs/fiber/examples/asio. When I run my program (just these 4 files, with no modifications), I get this output: Thread A: started Thread A: A0: echo-server started Segmentation fault Using print statements the seg-fault happens in the io_svc->run(); call. If anyone can help me with this, I would appreciate it. BTW, I am running on Ubuntu 16.04.3 LTS Thanks, Mark

2 1

Portable file I/O with system error codes support
by Oleg Andriyanov 23 Aug '17

23 Aug '17

Hi, I'm looking for a portable way to open a file, read some data from it, and do a proper error reporting in case of error. Apparently std::fstream is not suitable for this task because it does not provide means to retrieve original error code or even some human readable description of what went wrong (checking errno does not count since the standard does not guarantee it is set by any functions in std::fstream). I'm wondering if boost::iostreams can do that, but I've found nothing this far that could help in getting the error code. I've also tried boost::filesystem::fstream, but no luck. Users of large frameworks like Qt have advantage of their portable wrappers for file I/O like QFile. Are there any means in Boost which provide similar functionality? Related StackOverflow question: https://stackoverflow.com/questions/45840686/portable-way-to-read-a-file-in… Thanks.

3 2

[release] Boost 1.65.0
by Daniel James 21 Aug '17

21 Aug '17

Release 1.65.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains two new libraries and numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/history/version_1_65_0.html> You can also download directly from: <https://dl.bintray.com/boostorg/release/1.65.0/> To install this release on your system, see <http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Vladimir Prus, Rene Rivera, Marshall Clow, Eric Niebler, Daniel James, Beman Dawes

1 0

Is there a C++ implementation for numerical quadrature/cubature?
by Easior Lars 20 Aug '17

20 Aug '17

Hi, all in the list! I need some functions to handle numerical quadrature/cubature in C++. I found that only few packages, e.g. GSL, could do this end. However, those ones are not pure C++ implementations. Although, odeint package in Boost can partially satisfy my need. I want to know whether there is a C++ implementation for numerical quadrature/cubature in Boost. Any suggestion? -- Best wishes, Easior ------ "It was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of Light, it was the season of Darkness, it was the spring of hope, it was the winter of despair, we had everything before us, we had nothing before us, we were all going direct to heaven, we were all going direct the other way - in short, the period was so far like the present period, that some of its noisiest authorities insisted on its being received, for good or for evil, in the superlative degree of comparison only." TALES OF TWO CITIES, by Charles Dickens

3 5

[Boost][Container] Why is flat_set default constructor explicit?
by dariomt＠gmail.com 17 Aug '17

17 Aug '17

Hi all, I just found out that all Boost.Container default constructors are implicit (just as I would expect) except for flat_set. Quoting from [1]: explicit flat_set() noexcept(/*snip*/); Effects: Default constructs an empty container. Why is flat_set different than the other containers? Is this an oversight? FWIW this issue is breaking my C++14 code (for both clang and gcc) when switching from std::set to boost::container::flat_set, minimal repro follows: #include <boost/container/flat_set.hpp> #include <set> #ifndef USE_STD_SET using S = boost::container::flat_set<int>; #else using S = std::set<int>; #endif struct A { int i; S s; }; int main() { A a1; // OK A a2 {0, {{}} }; // OK A b1 {}; // FAILS A b2 {0}; // FAILS A b3 {0, {}}; // FAILS } A f() { return {}; // FAILS } Using Bost 1.64.0 in case that matters. Any help appreciated. [1] http://www.boost.org/doc/libs/1_64_0/doc/html/boost/container/flat_set.html…

2 1

Re: [Boost-users] Boost 1.65.0 Release Candidate 4
by Marshall Clow 17 Aug '17

17 Aug '17

On Wed, Aug 16, 2017 at 8:33 PM, Marshall Clow <mclow.lists(a)gmail.com> wrote: > The fourth (and hopefully final) release candidates for the 1.65.0 release > are now available at: > > https://dl.bintray.com/boostorg/release/1.65.0/source/ > [snippage] As always, the release managers would appreciate it if you download > the candidate of your choice and give building it a try. Please report > both success and failure, and anything else that is noteworthy. * Builds successfully with Apple Clang [Apple LLVM version 8.0.0 (clang-800.0.42.1)] with C++03/11/14/1z * Builds successfully with Clang Trunk [clang version 6.0.0 (trunk 310587)] with C++03/11/14 * Built successfully with Clang Trunk [clang version 6.0.0 (trunk 310587)] with C++1z except for Boost.Locale. -- Marshall

2 1

Boost 1.65.0 Release Candidate 4
by Marshall Clow 17 Aug '17

17 Aug '17

The fourth (and hopefully final) release candidates for the 1.65.0 release are now available at: https://dl.bintray.com/boostorg/release/1.65.0/source/ [ Note: The RC1s/RC2s/RC3s are in that directory, too - make sure you get the right files! ] Changes since RC3: * Fix a bug in Boost.Thread where timed waits were waiting for a very long time. Changes since RC2: * Fix a crashing bug in Boost.ASIO * Fix a compilation error when including both <boost/math_fwd.hpp> and <boost/math/common_factor_ct.hpp> * An update to Boost.Spirit to fix compilation errors on Mac OS with -std=c++17 Changes since RC1: * An update to Boost.Config so that the flags BOOST_NO_CXX98_RANDOM_SHUFFLE and BOOST_NO_CXX98_BINDERS are now set appropriately for libc++. (This fixes the compilation errors for Boost.Test) * An update to Boost.Fiber to fix compilation errors * An update to Boost.Wave to fix compilation errors on Mac OS with -std=c++17 The SHA256 checksums are as follows: 5d255d1ff8460d52dffcf9a9b55d908ae704027a66c590ec774096effaea26c1 boost_1_65_0_rc4.7z 911602d830ea5d16483d1e565b9859d120d03f2e5176017226ef391eb9d17fc8 boost_1_65_0_rc4.tar.bz2 369e06dc787d32b0fbaae020f33d814c9e7b77263acb859776968e623035f760 boost_1_65_0_rc4.tar.gz a9c6b8346b05ea43ac4278e80036a9e956ea99fc61f0b7f55469471af2df934c boost_1_65_0_rc4.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. Thanks! -- The release managers

2 1

Where we are 1.65.0
by Marshall Clow 16 Aug '17

16 Aug '17

RC1 came out on Monday, and it had some problems. Specifically: * Some libraries didn't build with ToT clang/libc++ (Locale, Wave and Test) This is because in C++17, some deprecated library features have been removed. [bind1st, mem_fun, auto_ptr, random_shuffle, etc ] Boost.Config has support for these removals, but this was ... incomplete. [ This is on me; I did the partial job of adding these to Config's libc++ support a while back ] Normally, I would be tempted to say "Well, clang 5 is not shipping yet, and so we can put this off until 1.66.0". But both clang 5 and C++17 are imminent (they will both happen well before the 1.66 release, and so I think we should fix this now. Also, a future version of MSVC will have the same library issues. So I have committed a fix for Boost.Config that fixes the Boost.Test issues. Hartmut has fixed most of the Boost.Wave issues. Artymom has a fix for Boost.Locale. Windows/MSVC builds look good across the board. * Boost.Fiber fails to build on Mac OS with anything other than -std=c++03. There is a fix in develop for this; but there's still a bunch of tests failing. * There's a problem from the beta in Boost.Math. The regression regarding boost/math/common_factor_ct.hpp (vs > math_fwd.hpp) seems to be still there. (For details please see the > original mail and replies: > https://lists.boost.org/Archives/boost/2017/07/237452.php) > What I presume is the fix (https://github.com/boostorg/math/pull/75) was > merged into develop about 12 hours ago, some automatic CI tests still > running. * There's a problem with ScopeExit and Visual C++ 2017 With Visual C++ 2017 and /permissive-, ScopeExit is still broken, for which > there's an open PR: > https://github.com/boostorg/scope_exit/pull/3 > Looks good otherwise on MSVC 14.11, tested with /std=cpplatest and > _HAS_AUTO_PTR_ETC=1, targeting Windows 10 and XP, 32 bit and 64 bit, built > as static libraries. >

5 5

constructing rationals from mpfr_floats [multiprecision]
by Dani Brake 15 Aug '17

15 Aug '17

Hi, 1) I am getting signaling due to division by 0. The following lines are faulty: mpfr_float p("1.1"); mpq_rational q(p); signal: integer divide by zero; whereas this succeeds: mpq_rational q(1.1); any one seen this before? i'm on compiler Apple LLVM version 8.0.0 (clang-800.0.38) ,with homebrew-provided boost 1.64, mpfr 3.1.5, gmp 6.1.2. -- 2) I also expected to be able to construct rationals as mpq_rational q("1.1") but it fails to parse using the built-in constructor. i mean, i understand why (1.1 isn't a rational), but given that i can construct a rational from a double, i figured that i'd get something reasonable from "1.1", namely 11/10. -- thanks! dani brake university of wisconsin eau claire ps i am not disabling mixed double-multiprecision arithmetic in this scenario, in case you have been reading my other questions this last week

1 0

Re: [Boost-users] deleting operators to forbid mixed arithmetic? [multiprecision]
by Dani Brake 15 Aug '17

15 Aug '17

Paul and John, Putting a macro bracket around this might make it generally useful, perhaps > something like: > > #ifdef BOOST_MULTIPRECISION_NO_DOUBLE_OPS (BUILTIN_OPS would include > float and long double?) > > … > > template <class Backend> > struct is_compatible_arithmetic_type<double, number<Backend> > : public > mpl::false_ {}; > > say > #endif > > If you find this useful, you could create a GIT Pull Request, or just > email the file changed. You won’t be the only one J. Defining the macro > BOOST_MULTIPRECISION_NO_DOUBLE_OPS could be a way to detect dodgy > conversions that need to be changed to keep full precision. I implemented this in my codebase, and had few ill effects. Some unexpected conversions, but I did find this disabling very useful. Wrapping it in a macro bracket and making it officially supported would be fabulous. I think it should go in number_base.hpp at line 110 or so. If we wanted to make it robust and thorough, I think we need to consider turning off implicit constructors from disabled types, too. I believe that what we have so far only disables arithmetic. Dani

1 0

Re: [Boost-users] Problem building Boost 1.64.0 with Oracle Developer Studio 12.6
by Leo Carreon 15 Aug '17

15 Aug '17

It’s now nearly a week since I sent this email and I have not received a comment from anyone from Boost. Does this mean we have no experience building on Developer Studio 12.6 or Boost doesn’t care whether it works on Solaris or not. I suspect Problem #2 may be a Solaris issue but I’m not sure about Problem #1 because even the guys from Oracle have no comment about it. I would appreciate a comment from the maintainer of Boost.Optional. From: Leo Carreon Sent: Wednesday, August 9, 2017 10:52 AM To: Boost Users Mailing List Subject: Problem building Boost 1.64.0 with Oracle Developer Studio 12.6 Hi Boosters, I have been trying to build Boost 1.64.0 with Oracle Developer Studio 12.6 on Oracle Solaris 11.3 x86_64. There are two errors encountered during the build. They are: 1. Problem with Boost.Optional with this error messages: "libs/log/src/named_scope.cpp", line 118: Error: Use of overloaded binary operator '=' is ambiguous. "./boost/optional/optional.hpp", line 900: Note: Viable candidate 'boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>& boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>::operator=<boost::log::v2_mt_posix::attributes::named_scope_list&>(boost::log::v2_mt_posix::attributes::named_scope_list&)'. "./boost/optional/optional.hpp", line 962: Note: Viable candidate 'boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>& boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>::operator=<boost::log::v2_mt_posix::attributes::named_scope_list&>(boost::log::v2_mt_posix::attributes::named_scope_list&)'. 2. Problem with Boost.Python with this error message: "libs/python/src/numpy/dtype.cpp", line 61: Error: NPY_FLOAT16 is not defined. Note that these two errors are the cause of 9 Boost shared libraries to not be generated. I would appreciate it very much if someone could give me some pointers on how to resolve the above issues. Kind regards, Leo

3 2

[Log][Optional][Python] Problem building Boost 1.64.0 with Oracle Developer Studio 12.6
by Leo Carreon 15 Aug '17

15 Aug '17

Hi, This is a resend with the suggested change on the subject line. I have been trying to build Boost 1.64.0 with Oracle Developer Studio 12.6 on Oracle Solaris 11.3 x86_64 in C++14 mode. There are three errors encountered during the build. They are: 1. Problem with Boost.Log with this error message: >> Assertion: (../lnk/initializer.cc, line 1865) while processing ./boost/log/expressions/message.hpp at line 98. My comment: Acknowledged by Oracle as a compiler issue. 2. Problem with Boost.Optional with this error messages: "libs/log/src/named_scope.cpp", line 118: Error: Use of overloaded binary operator '=' is ambiguous. "./boost/optional/optional.hpp", line 900: Note: Viable candidate 'boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>& boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>::operator=<boost::log::v2_mt_posix::attributes::named_scope_list&>(boost::log::v2_mt_posix::attributes::named_scope_list&)'. "./boost/optional/optional.hpp", line 962: Note: Viable candidate 'boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>& boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>::operator=<boost::log::v2_mt_posix::attributes::named_scope_list&>(boost::log::v2_mt_posix::attributes::named_scope_list&)'. My comment: Ambiguous boost::optional<>::operator=(), possibly a Boost configuration issue or compiler SFINAE issue. I’m not that fluent with SFINAE to be able to figure this out. 3. Problem with Boost.Python with this error message: "libs/python/src/numpy/dtype.cpp", line 61: Error: NPY_FLOAT16 is not defined. My comment: Possibly a Solaris package installation issue due to no support contract. (numpy package fails to install) I would appreciate it very much if someone could give me some pointers on how to resolve the above issues. Kind regards, Leo

1 0

Boost 1.65.0 Release Candidate 3
by Marshall Clow 14 Aug '17

14 Aug '17

The third (and hopefully final) release candidates for the 1.65.0 release are now available at: https://dl.bintray.com/boostorg/release/1.65.0/source/ [ Note: The RC1s and RC2s are in that directory, too - make sure you get the right files! ] Changes since RC2: * Fix a crashing bug in Boost.ASIO * Fix a compilation error when including both <boost/math_fwd.hpp> <boost/math/common_factor_ct.hpp> * An update to Boost.Spirit to fix compilation errors on Mac OS with -std=c++17 Changes since RC1: * An update to Boost.Config so that the flags BOOST_NO_CXX98_RANDOM_SHUFFLE and BOOST_NO_CXX98_BINDERS are now set appropriately for libc++. (This fixes the compilation errors for Boost.Test) * An update to Boost.Fiber to fix compilation errors * An update to Boost.Wave to fix compilation errors on Mac OS with -std=c++17 The SHA256 checksums are as follows: 1d844a958656e76b140292ec1cbfe770d9916166c16e13b59d3dac1df3b7ef40 boost_1_65_0_rc3.7z 3fc2877cf5da4bbb0c91eab058d2e6764155e705e9c3e2dce2a0248936079675 boost_1_65_0_rc3.tar.bz2 e065b53d7f5326cc20d246b518facedb4407391aaf9fd4a1c90001e0c85accab boost_1_65_0_rc3.tar.gz 96b2ba69c6045060d1dfe012218457870200c2c22af60eb855bab5ffb75c13a2 boost_1_65_0_rc3.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. Thanks! -- The release managers

1 1

Re: [Boost-users] deleting operators to forbid mixed arithmetic? [multiprecision]
by Dani Brake 14 Aug '17

14 Aug '17

> > So in principle you just define a full or partial specialization, for > example: > template <class Backend> > struct is_compatible_arithmetic_type<double, number<Backend> > : public > mpl::false_ {}; > and then cross your fingers and hope for the best ;) Thanks for the suggestion, i'll give it a try. \e crosses fingers ~dani

2 1

Re: [Boost-users] deleting operators to forbid mixed arithmetic? [multiprecision]
by Dani Brake 13 Aug '17

13 Aug '17

> > Been there, done that – fallen into the big pit awaiting the unwary mixing > double and multiprecision – again and again… L > I am being bit by this one hard. Converted a bunch of multipliers and tolerances from mpfr_floats to doubles in an effort to simplify some code, and now mixed precision is introducing error. > I think that you don’t really want to delete a family of operator*s – what > you DO want to get a warning when there is loss of significance, similar to > the warning when you fit a double into a float. > > It’s OK to multiply (or other ops) with a double as long as this doesn’t > lose any bits or digits of precision. > > So multiplying by 0.5 is OK, but not by multiplying 0.1 (the > multiprecision type needs FP_type(1)/10 to represent 0.1 as accurately as > possible for the FP type). > Multiplying by 0.1 is a common desire in my household (adaptive precision solving of polynomials). If only the compiler provided a trait bool is_exactly_representable(double) > so that a warning could be issued… > This is a bit tricky, because any double is by definition exactly representable by a double, right?. You would want is_exactly_representable to get the value before being transformed into a double? Another issue I foresee having to deal with is runtime parsing. Forbid the runtime user from feeding doubles problematic numbers. Thanks for the help, Dani

1 0

Re: [Boost-users] Problem building Boost 1.64.0 with Oracle Developer Studio 12.6
by Leo Carreon 12 Aug '17

12 Aug '17

It appears that Problem #1 is possibly a Boost configuration issue but may also be an issue with the compiler to do with enable_if. Two Boost.Optional member functions using enable_if are showing up in the lookup. Can anyone else comment? Problem #2 is possibly a Python package issue which can only be resolved by having a Solaris support contract because I’m unable to install the required packages to resolve the problem. From: Leo Carreon Sent: Wednesday, August 9, 2017 10:52 AM To: Boost Users Mailing List Subject: Problem building Boost 1.64.0 with Oracle Developer Studio 12.6 Hi Boosters, I have been trying to build Boost 1.64.0 with Oracle Developer Studio 12.6 on Oracle Solaris 11.3 x86_64. There are two errors encountered during the build. They are: 1. Problem with Boost.Optional with this error messages: "libs/log/src/named_scope.cpp", line 118: Error: Use of overloaded binary operator '=' is ambiguous. "./boost/optional/optional.hpp", line 900: Note: Viable candidate 'boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>& boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>::operator=<boost::log::v2_mt_posix::attributes::named_scope_list&>(boost::log::v2_mt_posix::attributes::named_scope_list&)'. "./boost/optional/optional.hpp", line 962: Note: Viable candidate 'boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>& boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>::operator=<boost::log::v2_mt_posix::attributes::named_scope_list&>(boost::log::v2_mt_posix::attributes::named_scope_list&)'. 2. Problem with Boost.Python with this error message: "libs/python/src/numpy/dtype.cpp", line 61: Error: NPY_FLOAT16 is not defined. Note that these two errors are the cause of 9 Boost shared libraries to not be generated. I would appreciate it very much if someone could give me some pointers on how to resolve the above issues. Kind regards, Leo

1 0

Re: [Boost-users] Problem building Boost 1.64.0 with Oracle Developer Studio 12.6
by Leo Carreon 12 Aug '17

12 Aug '17

BTW, I forgot to mention a third issue which has been acknowledged by Oracle as a problem with the compiler: 3. Problem with Boost.Log with this error message: >> Assertion: (../lnk/initializer.cc, line 1865) while processing ./boost/log/expressions/message.hpp at line 98. From: Leo Carreon Sent: Wednesday, August 9, 2017 10:52 AM To: Boost Users Mailing List Subject: Problem building Boost 1.64.0 with Oracle Developer Studio 12.6 Hi Boosters, I have been trying to build Boost 1.64.0 with Oracle Developer Studio 12.6 on Oracle Solaris 11.3 x86_64. There are two errors encountered during the build. They are: 1. Problem with Boost.Optional with this error messages: "libs/log/src/named_scope.cpp", line 118: Error: Use of overloaded binary operator '=' is ambiguous. "./boost/optional/optional.hpp", line 900: Note: Viable candidate 'boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>& boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>::operator=<boost::log::v2_mt_posix::attributes::named_scope_list&>(boost::log::v2_mt_posix::attributes::named_scope_list&)'. "./boost/optional/optional.hpp", line 962: Note: Viable candidate 'boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>& boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>::operator=<boost::log::v2_mt_posix::attributes::named_scope_list&>(boost::log::v2_mt_posix::attributes::named_scope_list&)'. 2. Problem with Boost.Python with this error message: "libs/python/src/numpy/dtype.cpp", line 61: Error: NPY_FLOAT16 is not defined. Note that these two errors are the cause of 9 Boost shared libraries to not be generated. I would appreciate it very much if someone could give me some pointers on how to resolve the above issues. Kind regards, Leo

1 0

deleting operators to forbid mixed arithmetic? [multiprecision]
by Dani Brake 12 Aug '17

12 Aug '17

Hi, I'd like to forbid multiplication of Boost.Multiprecision floating point numbers by doubles. Any tips? I think I want to delete a family of operator*s, but am having a hard time coming up with which ones. Thanks, Dani Brake University of Wisconsin Eau Claire

3 2

Boost 1.65.0 Release Candidate 2
by Marshall Clow 12 Aug '17

12 Aug '17

The second release candidates for the 1.65.0 release are now available at: https://dl.bintray.com/boostorg/release/1.65.0/source/ [ Note: The RC1's are in that directory, too - make sure you get the right files! ] Changes from RC1: * An update to Boost.Config so that the flags BOOST_NO_CXX98_RANDOM_SHUFFLE and BOOST_NO_CXX98_BINDERS are now set appropriately for libc++. (This fixes the compilation errors for Boost.Test) * An update to Boost.Fiber to fix compilation errors * An update to Boost.Wave to fix compilation errors on Mac OS with -std=c++17 The SHA256 checksums are as follows: 786ccb478a82ef526fb8649841d2e863af90d7ea31217bb2e938d87aff06cf23 boost_1_65_0_rc2.7z 83dbc7179271825c55a59c26f30cf9de53bb8b42006d920948bad709f5372af9 boost_1_65_0_rc2.tar.bz2 493cbf33a8837b44f87e3ac8a37ec32b9a0a27b8cdb03eac6237a16027a03809 boost_1_65_0_rc2.tar.gz 40e4ccbd52322f9a8cb6e1829075c810d8aad8851f3efb2b3da7fcff6963e14d boost_1_65_0_rc2.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. Thanks! -- The release managers

2 4

[serialization] archive testing
by Sergey Spiridonov 09 Aug '17

09 Aug '17

Hi, 1. The following works with xml_archive: cd boost_1_64_0/libs/serialization/test bjam -sBOOST_ARCHIVE_LIST=xml_archive.hpp 2. Example from documentation[1] does not work for me. Documentation tells[1]: -------------------------- To test a new archive, for example, portable binary archives, with the gcc compiler, make a header file portable_binary_archive.hpp and invoke bjam with -sBOOST_ARCHIVE_LIST=portable_binary_archive.hpp This process in encapsulated in the shell or cmd script library_test whose command line is library_test --toolset=gcc -sBOOST_ARCHIVE_LIST=portable_binary_archive.hpp ------------------------- [1] http://www.boost.org/doc/libs/1_64_0/libs/serialization/doc/archive_referen… I created boost_1_64_0/libs/serialization/test/portable_binary_archive.hpp with following lines: #include <libs/serialization/example/portable_binary_oarchive.hpp> typedef portable_binary_oarchive test_oarchive; typedef std::ofstream test_ostream; #include <libs/serialization/example/portable_binary_iarchive.hpp> typedef portable_binary_iarchive test_iarchive; typedef std::ifstream test_istream; #define TEST_STREAM_FLAGS (std::ios_base::openmode)0 1. There is no "library_test" script in boost_1_64_0.tar.bz2. 2. cd boost_1_64_0/libs/serialization/test bjam -sBOOST_ARCHIVE_LIST=portable_binary_archive.hpp fails with many linking errors like that: ../../../bin.v2/libs/serialization/test/test_array_portable_binary_archive.test/gcc-6.3.0/debug/test_array.o: In function `portable_binary_oarchive::save(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)': /home/ss/src/boost_1_64_0/libs/serialization/test/../../../libs/serialization/example/portable_binary_oarchive.hpp:105: undefined reference to `boost::archive::basic_binary_oprimitive<portable_binary_oarchive, char, std::char_traits<char> >::save(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' What am i doing wrong? -- Best regards, Sergey Spiridonov GAMIC mbH, Roermonder Str. 151, 52072 Aachen, Germany Phone +49 241 889110 CEO Paul Malkomes Amtsgericht Aachen HRB 4029 VAT-ID: DE 121 677 540 Please use support(a)gamic.com for support requests and bug reports

1 0

[heap] Singular handle issue with MSVC iterator debug facilities
by Mateusz Loskot 09 Aug '17

09 Aug '17

Hi, Using VS2017 and Boost 1.64, I'm compiling a program which uses boost::heap::d_ary_heap. In debug configuration (with default _ITERATOR_DEBUG_LEVEL), I'm observing issues at run-time when a handle of item on the heap is compared against default-constructed instance of handle_type. BTW, the handle_type compiled in is based on std::list::iterator as defined in boost::heap::detail::priority_queue_mutable_wrapper. The issue is that MSVC iterator debug facilities break execution with File: c:\program files (x86)\microsoft visual studio\2017\professional\vc\tools\msvc\14.10.25017\include\list Line: 290 Expression: list iterators incompatible AFAIU, handle_type{}; seems to yield handle h object wrapping singular iterator. Below, minimal example to reproduces the problem is included. While debugging the sample, Visual C++ debugger does not show the iterator wrapped by the handle as default-constructed with null node pointer. Instead, it displays garbage: ((???, ???), ???) // ------------------------------------------------------------------ #include <cstdint> #include <functional> #include <boost/heap/d_ary_heap.hpp> using NodeID = std::uint32_t; using EdgeWeight = std::int32_t; using HeapData = std::pair<EdgeWeight, NodeID>; using HeapContainer = boost::heap::d_ary_heap< HeapData, boost::heap::arity<4>, boost::heap::mutable_<true>, boost::heap::compare<std::greater<HeapData>>>; using HandleType = HeapContainer::handle_type; int main() { HeapContainer heap; auto const handle = heap.push(std::make_pair(100, 1)); handle == HandleType{}; // _DEBUG_ERROR("list iterators incompatible"); return 0; } // ------------------------------------------------------------------ Is this a known MSVC drawback while working with boost::heap::d_ary_heap or above the handle_type is actually misused? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Boost 1.65.0 Release Candidate 1
by Marshall Clow 09 Aug '17

09 Aug '17

The release candidates for the 1.65.0 release are now available at: https://dl.bintray.com/boostorg/release/1.65.0/source/ The SHA256 checksums are as follows: 0f1352a7738f24b39b564263b66a8c38bc7d984b57406396400474602e961ad3 boost_1_65_0_rc1.7z c2a022d4d6706668ea94b8e799a76e38929e0e34db884ef451fa9d5db6103238 boost_1_65_0_rc1.tar.bz2 7e84a27276792209d48357a0671348768dbf4dd1d4eadbf01b855274208f148d boost_1_65_0_rc1.tar.gz 537c42771b2351b4ea3eb8e9a13a3423edcd155323d2c14c4606cd23fc22d09f boost_1_65_0_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. Thanks! -- The release managers

4 5

[filesystem] Pull request needs attention
by Robert Dailey 09 Aug '17

09 Aug '17

I have fixed a crash I found due to static initialization ordering in boost filesystem. I have a proposed fix here: https://github.com/boostorg/filesystem/pull/47 It hasn't gotten any attention yet, so I'm hoping someone can offer some advice and/or merge the PR for me. Thanks in advance.

2 1

Problem building Boost 1.64.0 with Oracle Developer Studio 12.6
by Leo Carreon 09 Aug '17

09 Aug '17

Hi Boosters, I have been trying to build Boost 1.64.0 with Oracle Developer Studio 12.6 on Oracle Solaris 11.3 x86_64. There are two errors encountered during the build. They are: 1. Problem with Boost.Optional with this error messages: "libs/log/src/named_scope.cpp", line 118: Error: Use of overloaded binary operator '=' is ambiguous. "./boost/optional/optional.hpp", line 900: Note: Viable candidate 'boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>& boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>::operator=<boost::log::v2_mt_posix::attributes::named_scope_list&>(boost::log::v2_mt_posix::attributes::named_scope_list&)'. "./boost/optional/optional.hpp", line 962: Note: Viable candidate 'boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>& boost::optional<boost::log::v2_mt_posix::attributes::named_scope_list>::operator=<boost::log::v2_mt_posix::attributes::named_scope_list&>(boost::log::v2_mt_posix::attributes::named_scope_list&)'. 2. Problem with Boost.Python with this error message: "libs/python/src/numpy/dtype.cpp", line 61: Error: NPY_FLOAT16 is not defined. Note that these two errors are the cause of 9 Boost shared libraries to not be generated. I would appreciate it very much if someone could give me some pointers on how to resolve the above issues. Kind regards, Leo

1 0

Re: [Boost-users] [filesystem] Pull request needs attention
by Robert Dailey 08 Aug '17

08 Aug '17

On Tue, Aug 8, 2017 at 12:07 PM, Daniela Engert <dani(a)ngrt.de> wrote: > Am 08.08.2017 um 18:20 schrieb Robert Dailey via Boost-users: >> I have fixed a crash I found due to static initialization ordering in >> boost filesystem. I have a proposed fix here: >> https://github.com/boostorg/filesystem/pull/47 > > There is actually an even older (from april) pull request > https://github.com/boostorg/filesystem/pull/43 (by me) open on the very > same subject. > > Ciao > Dani Ah I didn't realize someone else had solved this problem. I will close mine in favor of yours. I don't quite understand why they're trying to share globals/statics between threads without some synchronization, but it's not my battle to deal with. I just want the code to work and not crash my application. Thanks for the reply.

1 0

make file starting out
by Peter Koukoulis 08 Aug '17

08 Aug '17

Hi I am new to setting up make files, and even newer to Boost. I've been using Geany on Ubuntu to learn Boost. When I compile and link using a single file with the following : g++ -g -Wall -std=c++14 -o "%e" "%f" -lboost_thread -DBOOST_THREAD_VERSION=5 -lboost_system -ldl then everything works as expected, for the following that is: #include <iostream> #include <boost/thread.hpp> #include <boost/thread/mutex.hpp> #include <boost/bind.hpp> #include <boost/asio.hpp> class t { private: boost::asio::io_service ios; std::unique_ptr<boost::asio::io_service::work> work_ios; boost::thread_group tg; int f; boost::mutex mx; public: // Constructor t( int p ) : work_ios{std::make_unique<boost::asio::io_service::work>(ios)}, f{p} { if(p>0) p = boost::thread::hardware_concurrency()*2; for ( int i = 0; i < p; ++i ) tg.create_thread( boost::bind( &boost::asio::io_service::run, &ios ) ); } // Destructor ~t () { work_ios.reset(); tg.join_all(); ios.stop(); } template <typename Job> void run_job( Job job ) { boost::unique_lock< boost::mutex > lock( mx ); if ( 0 == f ) return; --f; ios.dispatch( boost::bind( &t::wrap_job, this, boost::function< void() >(job) )); } private: void wrap_job( boost::function< void() > job ) { try { job(); } catch ( const std::exception& ) {} boost::unique_lock< boost::mutex > lock( mx ); ++f; } }; int main() { t tp{2}; tp.run_job( [] () { std::cout << "some work \n"; } ); return 0; } But when I attempt to split "t" into a .h and .cpp file with a separate file for main to test with, my linking does not work. The make output is: g++ test_t.o t.o -o test_t test_t.o: In function `__static_initialization_and_destruction_0(int, int)': test_t.cpp:(.text+0x6e9): undefined reference to `boost::system::generic_category()' test_t.cpp:(.text+0x6f5): undefined reference to `boost::system::generic_category()' The files look as follows: # the makefile: CC=g++ CFLAGS=-c -Wall -std=gnu++14 -lboost_system -lboost_thread -DBOOST_THREAD_VERSION=5 -ldl -lpq all: test_t test_t: t.o test_t.o $(CC) test_t.o t.o -o test_t t.o: t.cpp $(CC) $(CFLAGS) t.cpp test_t.o: test_t.cpp $(CC) $(CFLAGS) test_t.cpp clean: rm *o test_t.o test_t // .h file #ifndef T_H_ #define T_H_ #include <boost/thread.hpp> #include <boost/thread/mutex.hpp> #include <boost/bind.hpp> #include <boost/asio.hpp> class t { private: boost::asio::io_service ios; std::unique_ptr<boost::asio::io_service::work> work_ios; boost::thread_group tg; int f; boost::mutex mx; public: t( int p = 0 ); ~t(); template <typename Job> void run_job( Job job ) { boost::unique_lock< boost::mutex > lock( mx ); if ( 0 == f ) return; --f; ios.dispatch( boost::bind( &t::wrap_job, this, boost::function< void() >(job) )); } private: void wrap_job( boost::function< void() > job ) { try { job(); } catch ( const std::exception& ) {} boost::unique_lock< boost::mutex > lock( mx ); ++f; } }; #endif // .cpp file #include "t.h" // Constructor t::t( int p ) : work_ios{std::make_unique<boost::asio::io_service::work>(ios)}, f{p} { if(p>0) p = boost::thread::hardware_concurrency()*2; for ( int i = 0; i < p; ++i ) tg.create_thread( boost::bind( &boost::asio::io_service::run, &ios ) ); } // Destructor t::~t () { work_ios.reset(); tg.join_all(); ios.stop(); } // main file #include <iostream> #include "t.h" int main() { t tp{4}; tp.run_job( [] () { std::cout << "some work \n"; } ); return 0; } Could somebody point out how the make file should look like ? thanks pkl

4 3

boost::asio::async_read Error Operation canceled
by jupiter 07 Aug '17

07 Aug '17

Hi, I have a client program written by someone who is no longer available. The client program can send a message via async_write to server, but when the server responded back, the client boost::asio::async_read got an error of Operation cancelled. Searching from the Internet, it said the program was caused mostly by using this which should be fixed by using shared_from_this(). But in my client program it does not use this or shared_from_this, could someone explains if it uses some default format implies to this or shared_from_this in following example? (What (=) means, some kind of lambda function?) boost::asio::async_read(this->socket, boost::asio::buffer(this->messageHeader), [=](const boost::system::error_code &error, const uint32_t length) {this->readMessageHeader(error, length);}); Thank you. Kind regards.

1 0

Boost.Test change between 1.56 and 1.64
by Dominique Devienne 06 Aug '17

06 Aug '17

1.56 class BOOST_TEST_DECL test_tree_visitor { public: // test tree visitor interface virtual void visit( test_case const& ) {} virtual bool test_suite_start( test_suite const& ) { return true; } virtual void test_suite_finish( test_suite const& ) {} protected: BOOST_TEST_PROTECTED_VIRTUAL ~test_tree_visitor() {} }; 1.64 class BOOST_TEST_DECL test_tree_visitor { public: // test tree visitor interface virtual bool visit( test_unit const& ) { return true; } virtual void visit( test_case const& tc ) { visit( (test_unit const&)tc ); } virtual bool test_suite_start( test_suite const& ts ){ return visit( (test_unit const&)ts ); } virtual void test_suite_finish( test_suite const& ) {} protected: BOOST_TEST_PROTECTED_VIRTUAL ~test_tree_visitor() {} }; To list test suites and test cases of our test exes, I implemented a custom visitor in Boost 1.56 and simply did const auto& master_ts = but::framework::master_test_suite(); but::traverse_test_tree(master_ts, visitor); This is broken in 1.64, none of the old methods from the visitor are called, and thus no suites or cases are discovered. Two out of 3 of the old methods are forwards to the new visit() method, and obviously the implementation only calls the new visit(). The forwarding should be in the other direction for backward-compatibility. Looking for visit/visitor in http://www.boost.org/doc/libs/1_64_0/libs/test/doc/html/boost_test/change_l… yield nothing. Can someone please shed some light on this incompatible change? Thanks, --DD

2 2

Boost statechart
by Georg Gast 02 Aug '17

02 Aug '17

Hi, as the last changelog entry in statechart is from 1.46. Is it still maintained? Greetings Georg

1 0

[review][mp11] Review report
by Bjorn Reese 02 Aug '17

02 Aug '17

I. VERDICT Mp11 is accepted unconditionally into Boost. There were 14 accept votes and 1 conditional accept vote. See list at end of this report. II. DESIGN Reviewers evaluated the design as very good. Many agreed with the design principle of using template aliases on type lists, which means that Mp11 can be used on std, boost, and custom type lists. Integration with MPL was discussed. This resulted in a new header file <boost/mp11/mpl.hpp> that enables the conversion between mp_list (and std::tuple) and MPL sequences. A version of mp_eval_if that can apply a metafunction to type lists in both the true and false branch was requested. This is not possible due to C++ limitations (template parameter pack must be at the end.) Instead two alternatives were suggested: (1) use a nested mp_eval_if in the true branch, or (2) use mp_if<>::type with mp_defer in both branches. Extra metafunctions were added for working with map and sets: mp_is_set, mp_is_map, and mp_map_keys which returns a list of all keys. No review without a discussion about names. The mp_ prefix received most comments. The prefix is used to avoid collision between mp11 names and C++ keywords. The argument against the mp_ prefix was that MPL and other Boost libraries already have established trailing underscore as the naming convention. The argument in favor is that the mp_ prefix is better suited for later C++ standardization. Other names that deviate from MPL, such as apply versus fn, were also pointed out, and the names of tuple operations were also discussed. III. IMPLEMENTATION The reviewers who looked at the implementation were generally pleased with its quality and simplicity. A faster version of mp_find was proposed during review. On reviewer pointed out that const lists causes obscure compilation errors. IV. DOCUMENTATION The evaluation of the documentation was more mixed. Some found it good, while others found it too terse. A recurring comment was that the documentation is missing beginner-level explanations and examples. For instance, the tuple_cat example was mentioned as being too advanced for an introduction. More examples with higher-order metafunctions (e.g. mp_bind) was requested. The reference documentation does not state the pre-conditions of the metafunctions. For example, what happens when indices are out of bounds? The description of map (list of lists) lead to confusion. Mp11 map entries have one unique key-type, and zero or more value-types. The ability to have multiple value-types per key-type makes it possible to emulate multi-maps. Some where unsure whether C++11 or C++14 was required for the library. There were plenty of other useful comments that I will omit from the review report for the sake of brevity. V. USEFULNESS The library was generally deemed useful. It was discussed if C++11 (and later) makes it too easy to write our own metaprogramming utilities, and thus not needing a metaprogramming library. This was not directed at Mp11 in particular. Some of the arguments in favor of a metaprogramming library were better performance and portability. I would like to add another advantage of a metaprogramming library, namely that it gives us a common vocabulary. VI. CONCLUSION The library fulfills the quality and usefulness criteria without major outstanding issues. The library is therefore cleared to be included into Boost. My main recommendation as review manager is to make the documentation more beginner-friendly before the library is added to Boost. This is a recommendation, not a requirement. VII. PARTICIPANTS The following formal reviews were posted: * Barrett Adair : Accept * Brook Milligan : Accept * Edward Diener : Accept * Glen Fernandes : Accept * Jason Rice : Accept * Joaquin M López Muñoz : Conditional accept * John P Fletcher : Accept * Lee Clagett : Accept * Paul Fultz : Accept * Peter Koch Larsen : Accept * Robert Ramey : Accept * Roberto Hinz : Accept * Vijayan : Accept * Vinnie Falco : Accept * Zach Laine : Accept I would like to thank all participants for their efforts. I would also like to thank Peter Dimov for bringing such a high-quality library to Boost.

2 1

boost-users@lists.boost.org
by phillip mobley 02 Aug '17

02 Aug '17

Hello all, I am a new user to boost. I am currently using the serialization library to save my data structures to a file. However, I am currently running into a few issues. At first, I was getting a lot of undefined errors. After reading on multiple forums, I realized that I forgot to link the serialization library to the project. Once done, all of the errors went away. Except for one. I am getting this error: /usr/local/boost_1_64_0/boost/serialization/throw_exception.hpp:36: undefined reference to `boost::archive::archive_exception::archive_exception(boost::archive::archive_exception const&)' I have been spinng my head around this for a few days. Did I forget to add in another referene somewhere? My code is setup in the same manner as the simple tutorial found on the boost::serialization page. This error only pops up when I have the line: boost::archive::text_oarchive oa(ofs); When I have this line commented out, I do not get the above error. Again, I am wondering if I forgot to reference something in my program but I am not sure. Any help will be greatly appreciated. <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

1 0

Which socket read get first when both asio::async_read and asio::read are active?
by jupiter 02 Aug '17

02 Aug '17

Hi, I have a socket server program to activate in asio::async_read for receive any messages initiated from client. But when the server sends a message to the client, it uses sync write and flowing a sync read (asio::read) to immediately receive the response. The issue I can think of is who will get first read when both asio::async_read and asio::read are active? Thank you. Kind regards.

2 2

Boost.Fusion macro expansion
by Robert Jones 01 Aug '17

01 Aug '17

Hi Peeps Can anyone tell me what's wrong with this? I think macro expansion is going awry, but I'm not sure why. Do I really have to typedef the map<...> type to keep Fusion happy? Thx. #include<string> #include<map> #include <boost/fusion/adapted/struct/define_struct.hpp> #include <boost/fusion/include/define_struct.hpp> BOOST_FUSION_DEFINE_STRUCT( (demo), curves, ((std::map<std::string, std::string>), futures) ((std::map<std::string, std::string>), credit_curves) ) int main( ) { return 0; } > make fusion.cpp|9 col 39| error: invalid declarator before ‘)’ token || ((std::map<std::string, std::string>), futures) Kind Regards Rob.

3 3

Ranges
by Robert Jones 29 Jul '17

29 Jul '17

I realise this isn't strictly about Boost, but I'd appreciate if someone could say a few words about the current state of ranges in the standard, Boost or elsewhere. I'm familiar with the current Boost.Range, but thought there was a newer and rather different range library from Eric Neibler which was Boost compatible but not formally part of Boost, is that right? Are either of these part of the C++ standard, either now or planned, or is there anything else planned for the standard? Thx. Kind Regards Rob.

2 1

[filesystem] Strange "Function not implemented" exception from directory_iterator
by Robert Dailey 28 Jul '17

28 Jul '17

I'm using a recursive_directory_iterator on an Android ARM device (armeabi-v7a, clang compiler, API 15, LLVM STL). The exception I get comes from directory_iterator_increment in operations.cpp (when it does the dir_itr_increment() call and checks the `temp_ec` variable, there is a throw below that). The what() of the exception says: boost::filesystem::directory_iterator::operator++: Function not implemented: "/data/ziosk/content/Common/DemoMode/font" I doubt this is a permissions issue. Which function is not implemented? Is this a POSIX / LIBC issue? I have no idea at this point...

2 4

Boost.ProgramOptions issues porting from 1.56 to 1.64
by Dominique Devienne 28 Jul '17

28 Jul '17

I have an SVN-like "multi-command" single executable, i.e. exe [global-options] command [command-options] It uses two levels of option parsing. First level: typedef std::vector<std::string> UnparsedArgs; inline boost::program_options::typed_value<UnparsedArgs>* anyArgs() { return boost::program_options::value<UnparsedArgs>(); } options_description global_all_desc("Global Options", columns); global_all_desc.add_options() ("command", txtArg(), "Command to execute") ("cmdargs", anyArgs(), "Arguments for command") ...; // from http://stackoverflow.com/questions/15541498 // see also https://gist.github.com/randomphrase/10801888 po::positional_options_description pos; pos .add("command", 1) .add("cmdargs", -1); variables_map global_args; parsed_options parsed = po::command_line_parser(argc, argv) .options(global_all_desc) .positional(pos) // for implicit command and cmdargs above .allow_unregistered() // for command-specific arguments. .run(); po::store(parsed, global_args); std::vector<std::string> cmd_args = po::collect_unrecognized( parsed.options, po::include_positional ); Second level parsed_options reparsed = po::command_line_parser(cmd_args) .options(cmd_all_desc) .run(); po::store(reparsed, args_); // JIRA FOO-426 for (const auto& option : reparsed.options) { if (option.position_key >= 0) { std::ostringstream oss; for (const auto& token : option.original_tokens) { oss << token << ' '; } auto s = oss.str(); s.resize(s.size() - 1); err() << "Error: Too many commands: " << command() << ' ' << s << endl; return 1; } } in this particular case, the option that fails is ( "new", txtArgOpt(), "Creates a new group" ), with txtArgOpt() as below: inline boost::program_options::typed_value<std::string>* txtArg() { return boost::program_options::value<std::string>(); } inline boost::program_options::typed_value<std::string>* txtArgOpt(const std::string& implicit_value = "") { return txtArg()->implicit_value(implicit_value); } in the case that fails, the first parsing works fine, and remains ["--new", "groupA"] as cmd_args. in 1.56, reparsed.options contains 1 element: - [0] {string_key="new" position_key=-1 value={ size=1 } ...} boost::program_options::basic_option<char> + string_key "new" std::basic_string<char,std::char_traits<char>,std::allocator<char> > position_key -1 int - value { size=1 } std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > [size] 1 __int64 [capacity] 1 __int64 + [0] "GroupA" std::basic_string<char,std::char_traits<char>,std::allocator<char> > + [Raw View] 0x0000000009fae6c0 {...} std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > * - original_tokens { size=2 } std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > [size] 2 __int64 [capacity] 2 __int64 + [0] "--new" std::basic_string<char,std::char_traits<char>,std::allocator<char> > + [1] "GroupA" std::basic_string<char,std::char_traits<char>,std::allocator<char> > + [Raw View] 0x0000000009fae6e0 {...} std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > * unregistered false bool case_insensitive false bool but in 1.64, it contains 2 elements: - [0] {string_key="new" position_key=-1 value={ size=0 } ...} boost::program_options::basic_option<char> + string_key "new" std::basic_string<char,std::char_traits<char>,std::allocator<char> > position_key -1 int - value { size=0 } std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > [capacity] 0 __int64 + [allocator] allocator std::_Compressed_pair<std::_Wrap_alloc<std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,std::_Vector_val<std::_Simple_types<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,1> + [Raw View] {...} std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > - original_tokens { size=1 } std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > [capacity] 1 __int64 + [allocator] allocator std::_Compressed_pair<std::_Wrap_alloc<std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,std::_Vector_val<std::_Simple_types<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,1> + [0] "--new" std::basic_string<char,std::char_traits<char>,std::allocator<char> > + [Raw View] {...} std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > unregistered false bool case_insensitive false bool - [1] {string_key="" position_key=0 value={ size=1 } ...} boost::program_options::basic_option<char> + string_key "" std::basic_string<char,std::char_traits<char>,std::allocator<char> > position_key 0 int - value { size=1 } std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > [capacity] 1 __int64 + [allocator] allocator std::_Compressed_pair<std::_Wrap_alloc<std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,std::_Vector_val<std::_Simple_types<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,1> + [0] "GroupA" std::basic_string<char,std::char_traits<char>,std::allocator<char> > + [Raw View] {...} std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > - original_tokens { size=1 } std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > [capacity] 1 __int64 + [allocator] allocator std::_Compressed_pair<std::_Wrap_alloc<std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,std::_Vector_val<std::_Simple_types<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,1> + [0] "GroupA" std::basic_string<char,std::char_traits<char>,std::allocator<char> > + [Raw View] {...} std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > unregistered false bool case_insensitive false bool This is copy/pasted from VS, sorry, a little hard to read, but basically 1.56 has #0 string_key = "new" position_key = -1 value = ["groupA"] original_tokens = ["--new", "groupA"] unregistered = false case_insensitive = false while 1.64 has 2 items: #0 string_key = "new" position_key = -1 value = [] original_tokens = ["--new"] unregistered = false case_insensitive = false #1 string_key = "" position_key = 0 value = ["groupA"] original_tokens = ["groupA"] unregistered = false case_insensitive = false as-if the arg to --new was now a positional parameter, instead of an optional arg to --new. And this triggers the work-around code that errors out I had put in place to catch cases when the old 1.56 code wouldn't complain about extra arguments (e.g. "exe ... cmd1 cmd1_args cmd2" would be silently accepted, despite the extra cmd2, or "exe ... cmd --arg1 read-only" was accepted, when "exe ... cmd --arg1 --read-only" was expected), and this even though the second parsing doesn't have .allow_unregistered(). I'm trying to understand what's going on; obviously there's some kind of semantic change with optional argument to switches. Could anyone shed some light on this please? I'm not sure how to proceed now. TIA, -DD

2 4

error: 'function' in namespace 'boost' does not name a template type
by jupiter 28 Jul '17

28 Jul '17

Hi, Cannot I define a following boost function? Any workarounds? typedef boost::function<bool (const uint32_t, const std::shared_ptr<boost::asio::streambuf> &)> Subscriber_t; Thank you. Kind regards,

2 2

using ssl::context in boost 1.53 versions
by dipti Burli 27 Jul '17

27 Jul '17

Hi , I am currently using boost 1.53 version. cannot upgrade to latest version. Using ssl asio. Here is my requirement. I need to support tls1.1.and tls1.2 protocol in the server, but not tls1.0 . As there are no options for tls1.1. and tls1.2 ,and context is not present with relevant tls1.1 and tls1.2 versions, I created the ssl::context with tlsv1 method and used long ssl_disallowed = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_TLSv1 | SSL_OP_NO_TLSv1_1 | SSL_OP_NO_TLSv1_2; ssl_disallowed &= ~SSL_OP_NO_TLSv1_2; ssl_disallowed &= ~SSL_OP_NO_TLSv1_1; SSL_CTX_set_options(myBoostSslcontext.native_handle(), ssl_disallowed|SSL_OP_SINGLE_DH_USE); But handshake seems to be failing for any other versions other than tlsv1. Can you please let me know how to I set the options so that my sserver can accept tls connections on tls1.1 and tls1.2 with boost version 1.53. Thanks in advance. Dipti

1 0

[mpl] [msm] wrong number of template arguments (120, should be at least 0)
by Alessandro Marzialetti 27 Jul '17

27 Jul '17

Hello, I'm working on a msm with a big transition table (120 elements) I already tried with #define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS then #define BOOST_MPL_LIMIT_LIST_SIZE <custom value> But I can't go over a size of 50 (including "boost/mpl/vector/vector50.hpp") Any idea on how I can make a bigger table? Thanks, Alessandro <http://www.boost.org/doc/libs/1_63_0/libs/mpl/doc/refmanual/cfg-no-preproce…>

3 2

[Boost Graph Dijkstra Shortest Path]: Could not deduce template argument
by Choppin, Simon 26 Jul '17

26 Jul '17

Hello all, I use boost graph library for some point cloud processing and have had great success. However, I'm struggling to compile Dijkstra shorted path on MSVC v140. I am using boost library 1.53 and compiling in 64 bit. I used the example as a starting point but when I try to compile I get the error: Error C2784 'E boost::detail::get(boost::detail::underlying_edge_desc_map_type<E>,const boost::detail::reverse_graph_edge_descriptor<EdgeDesc> &)': could not deduce template argument for 'boost::detail::underlying_edge_desc_map_type<E>' from 'double *' I understand the fundamental problem that the template can't deduce type, however I'm struggling to source the problem. My graph type is: typedef adjacency_list < vecS, vecS, undirectedS, no_property, property <edge_weight_t, double> > WeightedGraph; Because I'm using MSVC I use the suggested non parameter name version: property_map<WeightedGraph, vertex_index_t>::type indexmap = get(vertex_index, GraphW); property_map<WeightedGraph, edge_weight_t>::type weightmap; std::vector<Vertex> p(num_vertices(GraphW)); std::vector<double> d(num_vertices(GraphW)); Vertex s = vertex(indices.first, GraphW); Vertex s_end = vertex(indices.second, GraphW); dijkstra_shortest_paths (GraphW, s, &p[0], &d[0], weightmap, indexmap, std::less<double>(), closed_plus<double>(), (double)(std::numeric_limits<double>::max)(), (double)0, Custom_visitor(s_end) ); I'm using a custom visitor to stop processing early as in this stackoverflow post: https://stackoverflow.com/questions/32047840/make-boost-dijkstra-algorithm-… Any ideas? All help greatly appreciated. Simon C

1 0

how to generate PDF formate documentations of Boost?
by easior 23 Jul '17

23 Jul '17

Hi, all in the list. I plan to build boost documentation in pdf format for latest version of boost. However, it's no luck to me even following the link: http://www.boost.org/doc/libs/1_40_0/doc/html/boostbook/getting/started.html. I can only find HTML formatted documentation for boost. I don't know what about the relationship between boost and doxygen. I also have no idea about the mechanism of the boostbook. Any suggection? Thanks in advance, Easior Lars

4 4

Boost Regex - Alternation documentation example
by Nick 21 Jul '17

21 Jul '17

According to the Boost Regex documentation for Alternation (http://www.boost.org/doc/libs/1_64_0/libs/regex/doc/html/boost_regex/syntax…) Quoting a piece of the documentation: ----- |abc is not a valid expression, but (?:)|abc is and is equivalent, also the expression: (?:abc)?? has exactly the same effect. ----- Is the last expression: (?:abc)?? correct? Why does it need two '?' operators instead of only one? If I try this expression with the input "abc" the Boost engine does not match "abc" as I'd have expected. However the expression: (?:abc)? matches as expected. Nick

2 2

MS controlled email domains - not going to work
by Michael Caisse 20 Jul '17

20 Jul '17

The irony in sending this message is that the people who need to see it probably wont get it. We are having trouble with hotmail.com, live.com, msn.com, and outlook.com. Microsoft is filtering the dedicated IP address used by the mail lists and most recently has responded with: Not qualified for mitigation [ip address] Our investigation has determined that the above IP(s) do not qualify for mitigation. These IP(s) have previously received mitigations from deliverability support, and have failed to maintain patterns within our guidelines, so they are ineligible for additional mitigation at this time. We have tried to explain multiple times that the IP address has a new owner but we seem to be stuck in almost an auto-response loop. We will continue to try and get service unblocked; however, I would recommend that you dump your MS controlled accounts for Boost mail lists and use another service. michael -- Michael Caisse Ciere Consulting ciere.com

2 1

[review][beast] Beast Review Results
by Michael Caisse 20 Jul '17

20 Jul '17

In an effort to get you all to just read this announcement sequentially, I will start with the result: Beast is ACCEPTED into Boost without conditions The entire community is served when the Boost review process works well and I would like to personally thank each of you who took your valuable time and worked to make Boost better. We had 21 formal reviews submitted from a demographic that included both seasoned participants and first-time reviewers. It is gratifying to have such participation for what some might see as a niche library. * Thank you Vinnie for your effort to assemble a high-quality package for review and for your responsiveness on the mail-lists. GitHub, and Slack. * Thank you to the individuals that submitted their first Boost review. * Thank you to the veteran contributors and authors for continuing to devote energy to the community. I found the discussion surrounding the library beneficial and I know that Vinnie walked away with actionable items to improve Beast. -------------------- The Stats: -------------------- While the review process is not exactly tallying up votes and casting a verdict, we can gain some insight of the general, gross-scale opinion of the library. Official reviews were received from: Reviewer Accept | Reject ------------------------------------------ * Zach Laine : X * Nik Bougalis : X * Artyom Beilis : X * Peter Dimov : X * Klemens Morgenstern : X * Glen Fernades : X * Marcel Ebmer : X * Scott Determan : X * Stanislav Karchebnyy : X * Michael Larson : X * Vadim Zeitlin : X * Jared Wyles : X * Niall Douglas : X * Barrett Adair : X * Gyorgy Szekely : X * Daniela Engert : X * Jens Weller : X * Phil Endecott : X * Bjorn Reese : X * Rüdiger Berlich : X * Christopher Kohlhoff : X Most of the reviewers agreed on the inclusion of Beast into Boost and at the same time that Beast isn't a great name for the library. (Just say Boost.Beast 10-times-fast). Vinnie has a FAQ item discussing the name and his continuing use is deliberate. He has heard the petitions to change and weighed them. -------------------- Concerns: -------------------- A variety of concerns and comments were made during the review. An impressive number of items were addressed in code or documentation during the review period itself. Some of the stated concern for rejection included: * Too many templates * Run-time polymorphism / OO would be better. * Library scope is too small and provides no real value to users - This is clearly one of those value judgements and for some users the not-in-scope nature of Beast made the feature set not compelling enough to use or have as a Boost library. Other users spent time converting existing projects to use Beast. This included projects previously running POCO, libcurl, and homegrown solutions. Beast has existing commercial and open-source users. The library clearly meets the needs of some users. * Premature optimization * Security concerns * Poor support for HTTP chunking - Vinnie proposed and then later made changes addressing the chunking concerns. Unfortunately, the reviewer with the complaint did not respond to multiple requests for feedback. * Licensing - Four files have dual licenses (BSL and another). Boost's legal counsel is reviewing the situation and we hope to have guidance by the end of this week. I have not placed a condition on the acceptance of Beast based on the legal feedback because Vinnie knows licensing issues must be remedied before the repository is merged into Boost. -------------------- The Upsides: -------------------- There were lots of great things said about the Beast package. Some of these include: * Great documentation * High quality implementation. * Thorough test suites * Already being used by commercial entities and others * Lots of successful real-life conversions of existing clients/servers * Extremely responsive developer (do you sleep Vinnie?) -------------------- An Author as much as a Library: -------------------- Accepting a library into Boost is also accepting an author. Boost authors have enormous latitude in the control and modifications of their libraries. Vinnie has shown dedication to addressing issues, listening to constructive input, making changes when appropriate, and protecting his vision of what the Beast is. I believe Vinnie will serve the community well as a contributor. -------------------- Final Thoughts: -------------------- Reviews are hard. It is hard to have your work torn apart and remain considerate. It is hard to repeat answers to previously asked questions. It is hard to explain specific use-cases and why it is important a library supports them. It is difficult to critique a large body of work. It is hard to stick with conversations to make overall improvements. I was impressed with the participants in the review. We are all opinionated and passionate -- likely a prerequisite to being part of the Boost community. Thank you all for making Boost better. I'm looking forward to seeing additional libraries and application built with Beast. -- Michael Caisse Ciere Consulting ciere.com

2 2

Re: [Boost-users] CMake Announcement from Boost Steering Committee
by Oliver Kowalke 20 Jul '17

20 Jul '17

I'm one of the maintainers of the CMake Boost support ( https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindBoost.cmake Roger, can Cmake be used for boost.context? Especially this library required to know the architecture, ABI, binary format, address model ... in order to select the right assembler?

3 3

Boost 1.65.0 Beta 1 Release Candidate 2
by Marshall Clow 19 Jul '17

19 Jul '17

The second release candidates for the 1.65.0 beta release are now available at: https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/boost_1_65_0_beta… https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/boost_1_65_0_beta… https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/boost_1_65_0_beta… https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/boost_1_65_0_beta… The SHA256 checksums are as follows: d54d29568c4e4933cbfe40a292b6cb84a7f68121e34f6a83f7d0f7c652b6b2d8 boost_1_65_0_beta1_rc2.7z 092676557513e992347d30dd0cd058fb8af2a401e5da4f4413f5b577852d726b boost_1_65_0_beta1_rc2.tar.bz2 31fa3c807e2205e18f7d5c74f77f540677f7b0937af1e37f595c137e1e87bf84 boost_1_65_0_beta1_rc2.tar.gz 83c8d8b76fa9591572226a1a49fd191d76db3011b52b907cbbc8d37d46213bd2 boost_1_65_0_beta1_rc2.zip This RC contains a single fix to the stacktrace library. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. Thanks! -- The release managers

7 10

CMake Announcement from Boost Steering Committee
by Jon Kalb 18 Jul '17

18 Jul '17

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

8 7

Re: [Boost-users] CMake Announcement from Boost Steering Committee
by Oliver Kowalke 18 Jul '17

18 Jul '17

Cmake file for boost.context is missing support for segmented stack (split-stack), valgrind ...? Is the Cmake port is not complete?

1 0

Boost 1.65.0 Beta 1
by Marshall Clow 16 Jul '17

16 Jul '17

Boost release 1.65.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/> The SHA256 checksums are as follows: d54d29568c4e4933cbfe40a292b6cb84a7f68121e34f6a83f7d0f7c652b6b2d8 boost_1_65_0_beta1.7z 092676557513e992347d30dd0cd058fb8af2a401e5da4f4413f5b577852d726b boost_1_65_0_beta1.tar.bz2 31fa3c807e2205e18f7d5c74f77f540677f7b0937af1e37f595c137e1e87bf84 boost_1_65_0_beta1.tar.gz 83c8d8b76fa9591572226a1a49fd191d76db3011b52b907cbbc8d37d46213bd2 boost_1_65_0_beta1.zip Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

5 5

Boost Regex Back Reference Issue
by Nick 14 Jul '17

14 Jul '17

According to the Boost documentation for Back references (http://www.boost.org/doc/libs/1_64_0/libs/regex/doc/html/boost_regex/syntax…) which seems to be the same at least from 1.37 - 1.64. Quoting a piece of the documentation: ----- For example the expression: ^(a*).*\1$ Will match the string: aaabbaaa But not the string: aaabba ----- I'm finding two issues with the example cited. 1. It seems to me that the example of the string which should not match, should actually match. Ultimately, shouldn't the engine match the marked sub-expression with the first 'a' in order to satisfy the backreference? I tested this example with Oniguruma and with PHP's PCRE and they both matched the string noted here to not match. But also, since the marked sub-expression is (a*) then I wonder what the behavior would be if it couldn't make a match on 'a', since the '*' will allow for zero matches. In fact, it seems like everything in the pattern is effectively "optional" due to the '*' operator. I'm a novice with Perl, but unless I made a mistake, it will match unconditionally: print "It matches\n" if "aaabba" =~ /^(a*).*\1$/; It matches print "It matches\n" if "aaabbac" =~ /^(a*).*\1$/; It matches print "It matches\n" if "" =~ /^(a*).*\1$/; It matches print "It matches\n" if "x" =~ /^(a*).*\1$/; It matches print "It matches\n" if "xyz" =~ /^(a*).*\1$/; It matches print "It matches\n" if "123" =~ /^(a*).*\1$/; It matches 2. The other issue is that when I try this example with the string which is posted to not match, the Boost regex engine runs for a while and ultimately crashes with a memory error. (seems like it might be an endless loop of some sort). Is that a bug? Nick

3 4

boost::unordered_map takes too long when I have only two elements in it
by Ram 14 Jul '17

14 Jul '17

Hi, I am using a boost::unordered_set but I sometimes have just two elements in it. It takes a long time then. Is it wrong if I have too few elements? Thanks, Ram

3 3

rational - 1.64 version shear?
by Nicholas Devenish 14 Jul '17

14 Jul '17

With boost/rational.hpp, the code: boost::rational<int> a{1}; long b{1}; auto c{a * b}; Works fine up to 1.63.0, but fails to compile in 1.64+ on the multiplication with "error: invalid operands to binary expression". This seems to be due to some restructuring that changed the way multiplications are declared, which (as far as I can tell), meant the operation declaration became conditional on number of representable digits. This breaking change isn't listed on the release notes or the ::rational documentation, so I'm wondering if it was accidental and therefore a bug (whose behaviour might change), or a deliberate change to prevent downcasting and just undocumented? Nick (I've come onto a project stuck on 1.56 and trying to update it)

2 1

⁨[process] problem with boost::process::on_exit
by Sandy Martel 14 Jul '17

14 Jul '17

The code below outputs: 1- child about to sleep for 2s 2- child about to sleep for 4s 3- child finish sleeping for 2s 6- sleep 4s child finished 5- child finish sleeping for 4s 4- sleep 2s child finished in a posix environment. I would expect the output to be in-order, looks like I get the wrong on_exit notification for the child processes I launch. Q: is this a bug or am I doing something wrong ? What is the correct way to get notified of specific process termination ? Regards, Sandy. code: #include <boost/process.hpp> #include <boost/asio.hpp> #include <thread> #include <iostream> int main( int argc, char **argv ) { if ( argc > 2 && strcmp( argv[1], "sleep" ) == 0 ) { auto s = atoi(argv[2]); std::cout << (s/2) << "- child about to sleep for " << s << "s" << std::endl; std::this_thread::sleep_for( std::chrono::seconds(s) ); std::cout << (s+1) << "- child finish sleeping for " << s << "s" << std::endl; return 0; } namespace bp = boost::process; boost::asio::io_service ios; // launch a child that will sleep for 2s auto c1 = bp::child( argv[0], "sleep", "2", ios, bp::on_exit( [](int, const std::error_code&) { std::cout << "4- sleep 2s child finished" << std::endl; }) ); // wait a bit, make sure the child startup for my test std::this_thread::sleep_for( std::chrono::milliseconds(10) ); // launch a child that will sleep for 4s auto c2 = bp::child( argv[0], "sleep", "4", ios, bp::on_exit( [](int, const std::error_code&) { std::cout << "6- sleep 4s child finished" << std::endl; }) ); // wait for the notifications ios.run(); }

1 0

[serialization] "Archive" type turns into abstract class during save/load!
by r＠primef.actor 13 Jul '17

13 Jul '17

In a member load function function I call a static method that loads another archive file, i.e. something like this: ```c++ struct Bar; struct Foo { std::shared_ptr<Bar> data; template <class Archive> void load(Archive& archive, const unsigned /*version*/) { std::string key; archive >> key; data = Bar::loadSomewhere<Archive>(std::move(key)); } }; struct Bar { template <class Archive> std::shared_ptr<Bar> loadSomewhere(std::string key) { std::ifstream input(key); Archive ar(input); std::shared_ptr<Bar> bar(new Bar()); ar >> *bar; return bar; } }; ``` The problem is that `Bar::loadSomewhere` is passed a `boost::archive::polymorphic_iarchive`, while I invoke the serialization library with a `boost::archive::xml_iarchive`. This is an abstract class, so I can't instantiate it! So somewhere down the road the `xml_iarchive` is turned into a `polymorphic_iarchive`. I would like to prevent this from happening, because I instantiate an `Archive` object in the `Bar::loadSomewhere` function. How can I get around this problem?

1 0

Re: [Boost-users] Boost 1.65.0 Beta 1 Release Candidate 2
by Matthieu Brucher 11 Jul '17

11 Jul '17

This happens a lot when people develop on gcc or visual studio and then try building with clang. Having a function and a class with the same name is bound to generate errors. So properly should be tagged as a bug. Le 11 juil. 2017 11:14 AM, "Raffi Enficiaud via Boost-users" < boost-users(a)lists.boost.org> a écrit : Le 11.07.17 à 02:14, Marshall Clow via Boost-users a écrit : The second release candidates for the 1.65.0 beta release are now > available at: > > > https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/ > boost_1_65_0_beta1_rc2.7z > > https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/ > boost_1_65_0_beta1_rc2.tar.bz2 > > https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/ > boost_1_65_0_beta1_rc2.tar.gz > > https://dl.bintray.com/boostorg/beta/1.65.0.beta.1/source/ > boost_1_65_0_beta1_rc2.zip > > The SHA256 checksums are as follows: > > d54d29568c4e4933cbfe40a292b6cb84a7f68121e34f6a83f7d0f7c652b6b2d8 > boost_1_65_0_beta1_rc2.7z > 092676557513e992347d30dd0cd058fb8af2a401e5da4f4413f5b577852d726b > boost_1_65_0_beta1_rc2.tar.bz2 > 31fa3c807e2205e18f7d5c74f77f540677f7b0937af1e37f595c137e1e87bf84 > boost_1_65_0_beta1_rc2.tar.gz > 83c8d8b76fa9591572226a1a49fd191d76db3011b52b907cbbc8d37d46213bd2 > boost_1_65_0_beta1_rc2.zip > > > This RC contains a single fix to the stacktrace library. > > As always, the release managers would appreciate it if you download > the candidate of your choice and give building it a try. Please report > both success and failure, and anything else that is noteworthy. > > Thanks! > > -- The release managers > Hi, I have this error during the build on OSX. Built with: ./b2 cxxflags="-std=c++11 -stdlib=libc++" linkflags="-stdlib=libc++" --without-log --layout=versioned install ...on 14200th target... common.mkdir bin.v2/libs/fiber/build/darwin-4.2.1/release/threading-multi common.mkdir bin.v2/libs/fiber/build/darwin-4.2.1/release/threading- multi/numa darwin.compile.c++ bin.v2/libs/fiber/build/darwin-4.2.1/release/threading- multi/numa/pin_thread.o libs/fiber/src/numa/pin_thread.cpp:23:10: warning: pin_thread() not supported [-W#pragma-messages] # pragma message "pin_thread() not supported" ^ 1 warning generated. darwin.compile.c++ bin.v2/libs/fiber/build/darwin-4.2.1/release/threading- multi/numa/topology.o libs/fiber/src/numa/topology.cpp:23:10: warning: topology() not supported [-W#pragma-messages] # pragma message "topology() not supported" ^ libs/fiber/src/numa/topology.cpp:27:14: error: use of undeclared identifier 'topology'; did you mean 'fibers::numa::topology'? std::vector< topology > topology() { ^~~~~~~~ fibers::numa::topology ./boost/fiber/numa/topology.hpp:38:21: note: 'fibers::numa::topology' declared here std::vector< node > topology(); ^ libs/fiber/src/numa/topology.cpp:27:14: error: template argument for template type parameter must be a type std::vector< topology > topology() { ^~~~~~~~ /Applications/Xcode8.1.app/Contents/Developer/Toolchains/Xco deDefault.xctoolchain/usr/bin/../include/c++/v1/vector:456:17: note: template parameter is declared here template <class _Tp, class _Allocator = allocator<_Tp> > ^ 1 warning and 2 errors generated. "g++" -ftemplate-depth-128 -O3 -Wall -dynamic -gdwarf-2 -fexceptions -Wno-inline -fPIC -arch x86_64 -std=c++11 -stdlib=libc++ -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_DYN_LINK=1 -DBOOST_DISABLE_ASSERTS -DBOOST_FIBERS_DYN_LINK=1 -DBOOST_FIBERS_SOURCE -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DNDEBUG -I"." -c -o "bin.v2/libs/fiber/build/darwin-4.2.1/release/threading-multi/numa/topology.o" "libs/fiber/src/numa/topology.cpp" ...failed darwin.compile.c++ bin.v2/libs/fiber/build/darwin -4.2.1/release/threading-multi/numa/topology.o... _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

Boost 1.65.0 Beta 1 Release Candidate 1
by Marshall Clow 09 Jul '17

09 Jul '17

The release candidates for the 1.61.0 release are now available at: https://dl.bintray.com/boostorg/beta/boost_1_65_0_beta1_rc1.7z https://dl.bintray.com/boostorg/beta/boost_1_65_0_beta1_rc1.tar.bz2 https://dl.bintray.com/boostorg/beta/boost_1_65_0_beta1_rc1.tar.gz https://dl.bintray.com/boostorg/beta/boost_1_65_0_beta1_rc1.zip The SHA256 checksums are as follows: cd7429340bb4aae38e0ad2e9f59c39e66335302c41577956123e55fc1e2a28ee boost_1_65_0_beta1_rc1.7z fda076f7b3c994524d9cd41926c72f4a9b7c017bef310a055956fdd0bed7c358 boost_1_65_0_beta1_rc1.tar.bz2 0d1473041f7a9fa9ce1e256c870cc52af6f98abf723cf4f1ac61c2b45f45d38a boost_1_65_0_beta1_rc1.tar.gz f45bbb75b84cdc0c66f8a571d77c518cfbac076d7a6fc7937c4812f0f242a792 boost_1_65_0_beta1_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. Thanks! -- The release managers

2 1

building for msvc-14.1
by Isaac Lascasas 09 Jul '17

09 Jul '17

Hello I have serious problems building boost for vs2017. My win10 install has just visual studio community 2017 installed right now, with windows SDK 10.0.15063.0 and 8.1. I run the vs2017 x64 native prompt and then I do something like this: b2 -j12 toolset=msvc-14.1 address-model=64 architecture=x86 link=static threading=multi runtime-link=shared --build-type=minimal stage --stagedir=stage/x64 some headers give weird stl container errors: c:\libs\boost_1_64_0__64\boost/archive/detail/basic_serializer_map.hpp(47): error C2039: 'set': is not a member of 'std' Thanks, Isaac.

1 0

[review] Mp11 review starts in one week
by Bjorn Reese 08 Jul '17

08 Jul '17

The formal review of Peter Dimov's Mp11 library is scheduled for July 15 - July 24, 2017 [1]. Mp11 is a C++11 metaprogramming library for compile-time manipulation of data structures that contain types. It’s based on template aliases and variadic templates and implements the approach outlined in the article "Simple C++ metaprogramming" [2] and its sequel [3]. These articles are useful background information for the review. * Mp11 aims to make simple usage simple, and to support complex usage without complicating the simple use cases. * Mp11 works on any type-list, whether its own type-list mp_list, or standard type-lists such as std::tuple and std::variant, or user-defined type-lists. * Mp11 works with any meta-function, such as C++11 or Boost type-traits, or user-defined type-traits. Mp11 can be found here: * Documentation: https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html * Source code: https://github.com/pdimov/mp11/tree/master [1] http://www.boost.org/community/review_schedule.html [2] http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [3] http://pdimov.com/cpp2/simple_cxx11_metaprogramming_2.html

1 0

Serialization support for small_vector
by Brian Wood 07 Jul '17

07 Jul '17

Shalom I've added support for small_vector to the C++ Middleware Writer. While testing the support, I got a warning about dereferencing a type-punned pointer breaking strict-aliasing rules. That was on line 340 of small_vector.hpp. I was using g++ 7.1 on FreeBSD/ TrueOS. I used the following "Middle" code for testing: message-lengths variable example_messages -out (message_id_8, ::boost::container::small_vector<int32_t,30>) -in (::boost::container::small_vector<int32_t,30>) } >From what I could tell the serialization/deserialization worked fine. If small_vector were broken out into a separate library that would be helpful from my perspective. It would make it easier for me to add small_vector to my example code. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

2 1

[serialization] unable to link on OS X when MACOSX_DEPLOYMENT_TARGET=10.7
by Pavol Juhas 06 Jul '17

06 Jul '17

Hello, I'd like to build the boost_serialization library with a compatibility setup for Mac OS X version 10.7, because I need to use it with Anaconda Python binaries, which are built for OS X 10.7. The OS X compatibility version can be set either by passing `-mmacosx-version-min=10.7` as a compile and link option or by setting environment variable MACOSX_DEPLOYMENT_TARGET=10.7. If I do so, the boost_serialization library builds without complaints, however I am not able to link it with my test program. Here are the steps I take to compile boost_serialization and the test program starting from a fresh boost 1.64.0 tree: # -------------------------------------------------------------- $ export MACOSX_DEPLOYMENT_TARGET=10.7 $ ./bootstrap.sh $ ./b2 -j4 variant=release link=shared --with-serialization stage # The stage/lib directory now contains libboost_serialization.dylib. # Use it to build a test program from tarchive.cpp: $ c++ tarchive.cpp -I. -Lstage/lib -lboost_serialization Undefined symbols for architecture x86_64: "boost::archive::basic_binary_oprimitive<boost::archive::binary_oarchive, char, std::char_traits<char> >::init()", referenced from: boost::archive::binary_oarchive_impl<boost::archive::binary_oarchive, char, std::char_traits<char> >::init(unsigned int) in tarchive-5e24a9.o "boost::archive::basic_binary_oprimitive<boost::archive::binary_oarchive, char, std::char_traits<char> >::save(std::string const&)", referenced from: void boost::archive::save_access::save_primitive<boost::archive::binary_oarchive, std::string>(boost::archive::binary_oarchive&, std::string const&) in tarchive-5e24a9.o ... # -------------------------------------------------------------- The only thing the test program (attached) does is to instantiate the boost::archive::binary_oarchive class. The procedure above works fine when MACOSX_DEPLOYMENT_TARGET is set to 10.9 or higher. Am I missing some option that would fix the failed linking when building for OS X 10.7? I suppose this could be related to object visibility options as the serialization library is compiled with "-fvisibility=hidden" and "-fvisibility-inlines-hidden" options. Thank you, Pavol

2 3

[review][beast] Five-days Remaining
by Michael Caisse 06 Jul '17

06 Jul '17

Hi all - We are half-way through the review and have some great involvement and exchanges and a few reviews already. I hope if you haven't written a review yet that you still will. Please provide whatever effort you can afford toward the review process. Boost depends on community involvement. You might have noticed that I have solicited input from you regardless of your experience with the domain. I personally think it is a mistake to have input only from domain experts. True innovation often comes from "outsiders". If you have no experience with Asio or with HTTP, how approachable is this library? Were you able to understand the documents? Could you use the examples? Were you able to build something of your own? Domain experts -- you know the dark corners of the domain. The hard parts that have caused you hours of lost sleep and the need to hack around an existing library or to write your own. How does Beast address your concerns and the problems you have experienced in the past? Is it flexible enough to be put into your tool chest? So far we have reviews from: * Marcel Ebmer * Peter Dimov * Artyom Beilis * Zach Lain * Nik Bougalis * Klemens Morgenstern * Glen Fernandes If I missed a review from you, please let me know! Happy Coding! michael -- Michael Caisse Ciere Consulting ciere.com

1 0

performance tuning on boost version 1_64_0
by Connie Zhang 05 Jul '17

05 Jul '17

Hello, I recently upgrade boost version of a visual C++ program from an old version of 1_58_0 to 1_64_0. Compared to the original executable, the newly upgraded one runs very slow (more than 6 times longer) even I disable the debug mode and set the optimization to /ox in visual environment. The other difference between the old and the upgrade ones is the visual studio version. The old one is on 2010 and the new one 2013. Anyone has any idea for why it behaves like this? Which kind of performance tuning I need to look into? Thank you so much for your help! Connie Sent from Yahoo Mail. Get the app

4 4

[serialization]Nans and infinity in wide xml archive
by Elizabeta 04 Jul '17

04 Jul '17

Hi I am using wide xml boost serialization archive. Because of the problem with loading of nans and infinities I tried the nonfinite facet as in the code snippet. This works, expect it messes with the encoding of the xml arhive which is no longer UTF-8 like before the using the facet, and I believe it is because of the no_codecvt flag which is passed to the archive. But without this flag the loading of nans/infinity does not work. How to use the facet and keep the wanted UTF-8 encoding ? float d = std::numeric_limits<float>::quiet_NaN; { std::wofstream oss("C:\\test.xml"); std::locale locale1(oss.getloc(), new boost::math::nonfinite_num_put<wchar_t>); oss.imbue(locale1); xml_woarchive oar(oss, no_codecvt); oar << BOOST_SERIALIZATION_NVP(d); } { float d; std::wifstream iss("C:\\test.xml"); std::locale locale1(iss.getloc(), new boost::math::nonfinite_num_get<wchar_t>); iss.imbue(locale1); xml_wiarchive iar(iss, no_codecvt); iar >> BOOST_SERIALIZATION_NVP(d); std::cout << d << std::endl; } -- View this message in context: http://boost.2283326.n4.nabble.com/serialization-Nans-and-infinity-in-wide-… Sent from the Boost - Users mailing list archive at Nabble.com.

3 5

Log: Coloring logging output
by Florian Lindner 04 Jul '17

04 Jul '17

Hello, I try to create a formatter that can display logging messages (or just prints the severity level in different colors). Given a format string like: default_formatter = "%SeverityFormat% %Message%"; /// A custom formatter that handles the Severity formatting class severity_formatter_factory : public boost::log::formatter_factory<char> { public: formatter_type create_formatter(boost::log::attribute_name const& name, args_map const& args) { namespace expr = boost::log::expressions; return expr::stream << "|" << "\033[32m" << expr::attr<boost::log::trivial::severity_level >("Severity") << "|"; } }; and register with bl::register_formatter_factory("SeverityFormat", boost::make_shared<severity_formatter_factory>()); it basically works, i.e. the output is colored (all green) and the severity name is printed. But how can I get the actual severity of the message that is about to be formatted inside the formatter? So I can act on that and color warn messages red and info messages green? What I found on the internets, e.g. https://stackoverflow.com/questions/38309479/how-to-add-color-coding-to-boo… http://www.boost.org/doc/libs/1_64_0/libs/log/doc/html/log/tutorial/formatt… was using the sink->set_formatter method, which gives me, afaik, no possbility to configure using a format string. But I'm open to any ideas... Thanks, Florian

1 0

Why cannot asio tcp socket server detect TCP disconnection when the client device lost power?
by jupiter 03 Jul '17

03 Jul '17

Hi, The asio tcp server can detect the disconnection when the client program stop. But I have small device when it lost power, the server won't be able to detect the TCP disconnection. Does the boost socket has TCP timeout? What is an effective way to handle this situation other than running heartbeat in user level? Thank you. Kind regards, - j

6 10

[review][beast] Review of Beast starts today : July 1 - July 10
by Michael Caisse 01 Jul '17

01 Jul '17

The formal review of Vinnie Falco’s Beast library will take place from July 1 through July 10, 2017. Please consider participating in this review. The success of Boost is partially a result of the quality review process which is conducted by the community. You are part of the Boost community. I will be grateful to receive a review based on whatever level of effort or time you can devote. Beast is a C++ header-only library serving as a foundation for writing interoperable networking libraries by providing low-level HTTP/1, WebSocket, and networking protocol vocabulary types and algorithms using the consistent asynchronous model of Boost.Asio. Beast is designed for: * Symmetry: Algorithms are role-agnostic; build clients, servers, or both. * Ease of Use: Boost.Asio users will immediately understand Beast. * Flexibility: Users make the important decisions such as buffer or thread management. * Performance: Build applications handling thousands of connections or more. * Basis for Further Abstraction: Components are well-suited for building upon. A branch has been made for the review. You can find Beast for review at these links: * Documentation : <http://vinniefalco.github.io/stage/beast/review/> * Source code : <https://github.com/vinniefalco/Beast/tree/review> * The FAQ answers real questions that come up : <http://vinniefalco.github.io/stage/beast/review/beast/design_choices/faq.ht…> A lightning talk from CppCon 2016 introducing Beast can be found here: <https://www.youtube.com/watch?v=uJZgRcvPFwI> Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Beast as a Boost library. Please be explicit about your decision. Some other questions you might want to consider answering: - 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 which compiler(s)? 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? More information about the Boost Formal Review Process can be found here: <http://www.boost.org/community/reviews.html> Thank you for your effort in the Boost community. Happy coding - michael -- Michael Caisse Ciere Consulting ciere.com

1 0

Boost_1_64_0 compile errors - gcc 5.3.0
by Michael Miller 30 Jun '17

30 Jun '17

Hello, Qt Creator 4.3.1 Based on Qt 5.9.1 gcc version 5.3.0 Trying to use Boost in my program. I’m getting the following compile errors. Any suggestions, Please. Regards In file included from C:\boost\boost_1_64_0/boost/numeric/ublas/vector.hpp:21:0, from C:\boost\boost_1_64_0/boost/numeric/ublas/matrix.hpp:18, from lib\math/lc_quadratic.h:30, from lib\engine\rs_arc.cpp:37: C:\boost\boost_1_64_0/boost/numeric/ublas/storage.hpp: In member function 'void boost::numeric::ublas::unbounded_array<T, ALLOC>::serialize(Archive&, unsigned int)': C:\boost\boost_1_64_0/boost/numeric/ublas/storage.hpp:299:18: error: 'make_array' is not a member of 'boost::serialization' ar & serialization::make_array(data_, s); ^ C:\boost\boost_1_64_0/boost/numeric/ublas/storage.hpp: In member function 'void boost::numeric::ublas::bounded_array<T, N, ALLOC>::serialize(Archive&, unsigned int)': C:\boost\boost_1_64_0/boost/numeric/ublas/storage.hpp:494:18: error: 'make_array' is not a member of 'boost::serialization' ar & serialization::make_array(data_, s); ^ In file included from C:\boost\boost_1_64_0/boost/numeric/ublas/vector.hpp:21:0, from C:\boost\boost_1_64_0/boost/numeric/ublas/matrix.hpp:18, from lib\math/lc_quadratic.h:30, from lib\engine\rs_circle.cpp:42: C:\boost\boost_1_64_0/boost/numeric/ublas/storage.hpp: In member function 'void boost::numeric::ublas::unbounded_array<T, ALLOC>::serialize(Archive&, unsigned int)': C:\boost\boost_1_64_0/boost/numeric/ublas/storage.hpp:299:18: error: 'make_array' is not a member of 'boost::serialization' ar & serialization::make_array(data_, s); ^ C:\boost\boost_1_64_0/boost/numeric/ublas/storage.hpp: In member function 'void boost::numeric::ublas::bounded_array<T, N, ALLOC>::serialize(Archive&, unsigned int)': C:\boost\boost_1_64_0/boost/numeric/ublas/storage.hpp:494:18: error: 'make_array' is not a member of 'boost::serialization' ar & serialization::make_array(data_, s); ^ In file included from lib\math/lc_quadratic.h:30:0, from lib\engine\rs_circle.cpp:42: C:\boost\boost_1_64_0/boost/numeric/ublas/matrix.hpp: In member function 'void boost::numeric::ublas::c_matrix<T, M, N>::serialize(Archive&, unsigned int)': C:\boost\boost_1_64_0/boost/numeric/ublas/matrix.hpp:5977:18: error: 'make_array' is not a member of 'boost::serialization' ar & serialization::make_array(data_, N); ^

1 0

[poly_collection] Boost.PolyCollection release version ready
by Joaquin M López Muñoz 29 Jun '17

29 Jun '17

Hello, For those who are following the development of this lib, I'd like to announce that the release version of Boost.PolyCollection for Boost 1.65 is already committed to the master branch of Boost. Much of the to-do list prepared by Ion at the end of the review has been implemented. The main features left as roadmap are listed at: http://www.boost.org/doc/libs/master/doc/html/poly_collection/future_work.h… As for the improvements already included, let me comment on what I feel are the most important: * The implementation has been refactored to avoid internal virtual calls at places where the type of the segment involved is known at compile time. Also, segment lookup (the process to get to the segment for U from typeid(U)) has been greatly sped up by means of a std::type_info* cache. These two improvements result in a combined reduction of around 25-30% in insertion times. There's an API breaking change though: no longer is std::type_index used and const std::type_info &'s have to be directly provided instead --this is likely to go unnoticed by those of you already using the lib. * Polymorphic collections now satisfy standard requirements on allocator use as stated in [container.requirements.general]/3 (or, more precisely, the natural interpretation for polymorhpic containers of this clause). This is explicitly described in the reference. As a result, polymorphic collections can now use std::scoped_allocator_adaptor without any problem. * Added segment(typeid(U))/segment<U>() convenience funtions returning a range object over the selected segment. This allows us to write: for(const auto& x:c.segment(typeid(warrior))){ ... } * Collection-level max_size() and capacity() have been removed as I didn't seem to find sensible semantics for them. Segment-level max_size() and capacity() are kept, of course. * Hopefully the tutorial section on boost::function_collection is a bit clearer now. The library works OK for MSVC>=14.0,GCC>=5.0,Clang>=3.7. Unfortunately, Intel fails for test_algorithm: https://lists.boost.org/Archives/boost/2017/06/236016.php If someone's interested in helping fix that, please step up. Thank you, Joaquín M López Muñoz

4 4

C++11 ABI stability
by Marek Skalický 29 Jun '17

29 Jun '17

Hi, mongo-cxx-driver notices this: "Important note about C++11/C++14: The boost libraries do not offer a stable ABI across different versions of the C++ standard. As a result, you must ensure that your application, the C++ driver, and boost are all built with the same language standard. In particular, if you are building the C++ driver with C++11 enabled, you must also build your application with C++11 enabled, and link against a C++11 compiled boost. " [1] Is it true? What changes with new standard? (or is this only related to ABI change in gcc introduced by c++11?) I'm interested mainly in libraries: filesystem, chrono, thread, system and regex Thanks, Marek [1] http://mongodb.github.io/mongo-cxx-driver/legacy-v1/installation/#s cons-options-when-compiling-the-c-driver

6 7

[boost] [beast] Formal "review" branch frozen
by Vinnie Falco 29 Jun '17

29 Jun '17

The "review" branch of Beast is now available and frozen for modifications. It contains the snapshot of the repository which will undergo the Boost formal review starting on July 1 and lasting for 10 days. Currently the review branch is even with the master branch, at version 70. The review branch repository is here: https://github.com/vinniefalco/Beast/tree/review The review documentation snapshot: http://vinniefalco.github.io/stage/beast/review/ Autobahn WebSocket Implementation Test Report: http://vinniefalco.github.io/autobahn/index.html Beast is a C++ header-only library serving as a foundation for writing interoperable networking libraries by providing low-level HTTP/1, WebSocket, and networking protocolvocabulary types and algorithms using the consistent asynchronous model of Boost.Asio. Beast empowers users to create their own libraries, clients, and servers using HTTP/1 and WebSocket. Code will be easier and faster to implement, understand, and maintain, because Beast takes care of the low-level protocol details. Please don't forget to "star" the repository on GitHub, the increased exposure will vitalize Beast and Boost with the new generation of programmers! Thanks! -- Follow me on Github: https://github.com/vinniefalco

1 0

Regression in Boost.Variant with gcc6.3 in C++03 mode
by dariomt＠gmail.com 28 Jun '17

28 Jun '17

Hi, This is the simplest possible repro I could get: #include <boost/variant.hpp> class A {}; class B : private A {}; typedef boost::variant<A, B> variant_t; int main() { B b; variant_t v (b); } This used to work with Boost 1.59.0 but fails with 1.64.0 Using wandbox I've found that: - it started failing in 1.62.0 - clang does not have this problem - newer and older versions of gcc do have the same problem The error is miles long. I think the important parts are: boost/type_traits/is_convertible.hpp:149:53: error: 'A' is an inaccessible base of 'B' error: no matching function for call to 'boost::variant<A, B>::variant(B&)' It seems the metaprogramming messes up due to the private inheritance, and decides that the variant<A,B> is *not* constructible from B Workarounds are very welcome! Switching to C++14 is not an option (yet). Regards

3 8

Compiling Boost_1_6_0 under linux.
by Michael Miller 27 Jun '17

27 Jun '17

Hello, I’m trying to compile Boost_1_64_0 under linux, without success. Debian 9 gcc version 6.3.0 Terminal commands:- cd tools/build ./bootstrap.sh ./b2 install --prefix=~/boost/boost_1_64_0 No Boost (executable) appears. Am I missing something? Regards

2 2

Build error C3083
by James 26 Jun '17

26 Jun '17

Hi, I am trying to build an application that uses the boost libraries. I am seeing build error C3083 in bind_mf_cc.hpp. The error states: Error C3083 'core': the symbol to the left of a '::' must be a type This is the offending code section : template<class Rt2, class R, class T, class A1> typename boost::enable_if_c<!boost::core::is_same<Rt2,R>::value, _bi::bind_t<Rt2, _mfi::BOOST_BIND_MF_NAME(mf0)<R,T>, typename _bi::list_av_1<A1>::type>>::type BOOST_BIND(R(BOOST_BIND_MF_CC T::*f) (), A1 a1) { typedef _mfi::BOOST_BIND_MF_NAME(mf0)<R, T> F; typedef typename _bi::list_av_1<A1>::type list_type; return _bi::bind_t<Rt2, F, list_type>(F(f), list_type(a1)); } And the line giving the trouble is the line beginning: typename boost::enable_if_c<!boost::core::is_same<Rt2,R>::value, Can anyone help me correct the line to fix this issue please? Thanks.

5 11