July 2018 - Boost - lists.boost.org

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

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

49 200

Re: [boost] [ Interest? ] [ out_ptr ] Tiny C++ Abstraction for C-Style Output Pointers
by Bjorn Reese 11 May '19

11 May '19

On 06/28/18 21:03, ThePhD via Boost wrote: > out_ptr is a small abstraction for making types such as > std::unique_ptr, std::shared_ptr, boost::shared_ptr, and the upcoming > std::retain_ptr > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0468r0.html> work > work C-Style output functions as a parameter, addressing the need of > wanting to be able to do "my_c_api_init( foo, bar, &my_smart_ptr );". It's Does out_ptr have other use-cases than C interoperability?

7 14

[RFC] unique_val (handles, IDs, descriptors...)
by Miguel Ojeda 15 Oct '18

15 Oct '18

Hi all, While working on a medium-sized project, I had to wrap quite some handles, IDs, descriptors, etc. into RAII classes. Somehow, writing those and making them movable seemed more verbose than needed. I searched in the STL and Boost for something already implemented, but nothing seemed to come up. I decided to write my own prototype to see whether I was missing something important; but actually using it in my project felt quite natural and simple. At this point, I asked for a second opinion from a well-known expert (thanks Scott!) and he agreed that it seemed like a reasonable idea but, of course, he would also be surprised if others haven't come up with something similar. So I polished it up a bit and uploaded it to: https://github.com/ojeda/unique_val Below you have the introduction inlined [1]. If you have the time, please take a look (specially to the Rationale) and let me know your comments. The code itself is very short and straightforward. If you already have this class/template in Boost somewhere that I missed, please let me know! Otherwise, if you think this could be interesting to put into Boost in some existing library (not sure which) or as a new tiny library, I would be glad to make the effort to expand it, clean it up, etc. Thank you! Miguel [1] """ A single-header header-only library for representing unique values (handles, IDs, descriptors...) that default to a value on move for C++11, C++14 and C++17. It simplifies writing resource-owning classes (RAII) with move semantics support for resources with handles, IDs or descriptors that are supposed to be used as unique values, not as unique pointers. For instance, it can be used with non-pointer handlers (like the `int` file/socket descriptors in POSIX) and with opaque pointer handlers (like the `HWND` handles in the Win32 API). As such, it can be used as an alternative to `std::unique_ptr` with or without custom deleter, specially for resources that use a non-pointer type or resources that are not simply heap-allocated. It does not have any overhead compared to using the original type. It supports booleans, integers, pointers and enumerations. The default value can be different than the default-constructed value (i.e. different than 0, nullptr, etc.). """

7 13

Trac
by Robert Ramey 07 Sep '18

07 Sep '18

Could we agree to stop using the Trac system? The github issues/pr system is much more functional. I propose we close the trac system to new issues - be of course leave it available for reference. Robert Ramey

21 57

Guidelines on copyright notice maintenance
by Mateusz Loskot 06 Sep '18

06 Sep '18

Hi, The license guidelines [1] include instructions on "How should Boost programmers apply the license to source and header files?" Unless I've missed it, there seem to be lack of guidelines about how to maintain (existing) copyright notices. I don't aim to resurrect the old lengthy thread from Sept 2015 on validity of copyright notices. In that thread, however, some guidelines or conventions were expressed: [2] "because copyright is only claimed for changes meeting a certain threshold of originality" [3] "It's up to those people to add a line if they so decide. Copyright only covers expressions of creativity." Those suggests, there seem to be common understanding on if/how/when it is recommended or even necessary to update copyright notice in a source file of a Boost library. Wouldn't it be helpful to captured those as guidelines in the BSL FAQ. Would there be someone knowledgeable about it and willing to make the update or at least explain it here? (I will make it into HTML and PR to boostorg/website) I understand David and Beman, primary authors of the page [1], may no longer be available. [1] https://www.boost.org/users/license.html [2] https://lists.boost.org/Archives/boost/2015/09/225565.php [3] https://lists.boost.org/Archives/boost/2015/09/225570.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

No Viable function warning
by randydom 03 Sep '18

03 Sep '18

Hello i've the bellow function : __declspec(dllexport) int TrySendData(_isocket * isocket,char * ibuff,int ilen) { boost::system::error_code ignored_error; boost::asio::write(isocket->socket(), boost::asio::buffer(ibuff,ilen), boost::asio::transfer_all(), ignored_error); if(ignored_error) return 0; return 1; } I get a *No Viable function* warning , can someone tells me why or helps me in fixing this warning . Thank you . -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

Original STL Library Documentation has been recovered and is now safe forever.
by Robert Ramey 02 Sep '18

02 Sep '18

The Standard Template Library is the foundation of modern C++. The creation and publication of this code and its documentation set a new standard for the formal specification of what a computer program should do, how it should be designed and how it should be formally documented. These pages were maintained first by Silicon Graphics and then later by Hewett-Packard. In January of 2018 these pages were removed by H-P. This is a historic blunder. I have recovered the original STL Library Document and hosted them here: http://www.rrsd.com/software_development/stl/index.htm Robert Ramey

8 10

Strange libstdc++ versions in travis-ci testers
by Andrzej Krzemienski 15 Aug '18

15 Aug '18

Hi Everyone, Maybe someone could help me understand the configuration on the travis-ci testers. Whenever I push a new commit I get a number of failures from travis-ci about missing std::is_trivially_default_constructible from the standard library; like here: https://travis-ci.org/boostorg/optional/builds/397519342?utm_source=email&u… Some tests with Boost.Predef indicate that they are clang compiler 3.X, and clang 5 with libstdc++ of strange version nubers: macro BOOST_LIB_STD_GNU gives values 450400026 and 460700026, which would correspond to releases 2015-04-26 and 2016-07-26, but when I look at the release notes for GCC there are no releases mentioned of these dates: https://gcc.gnu.org/news.html Maybe someone knows what versions of libstdc++ these are? Or maybe I am missing something obvious? Regards, &rzej;

5 12

Re: [boost] [Boost-users] [release] Boost 1.68.0 Beta 1 -> warnings in gil, locale, geometry, asio, ublas, interprocess, atomic
by Frédéric 09 Aug '18

09 Aug '18

Here are some more warnings while using the libraries: * gil: boost/gil/extension/toolbox/image_types/indexed_image.hpp:190:5: warning: les qualificatifs de type sont ignorés sur le type retourné par la fonction [-Wignored-qualifiers] const std::size_t num_colors() const { return _num_colors; } ^~~~~ boost/gil/extension/dynamic_image/any_image_view.hpp:41:63: warning: unused parameter 'v' [-Wunused-parameter] template <typename T> result_type operator()(const T& v) const { return num_channels<T>::value; } boost/gil/extension/dynamic_image/algorithm.hpp:147:70: warning: unused parameter 'src' [-Wunused-parameter] template <typename V, typename Value> static void apply(const V& src, const Value& val) { throw std::bad_cast();} ^ boost/gil/extension/dynamic_image/algorithm.hpp:147:88: warning: unused parameter 'val' [-Wunused-parameter] template <typename V, typename Value> static void apply(const V& src, const Value& val) { throw std::bad_cast();} ^ boost/gil/extension/dynamic_image/image_view_factory.hpp:178:140: warning: unused parameter 'cc' [-Wunused-parameter] typename color_converted_view_type<any_image_view<ViewTypes>, DstP, CC>::type color_converted_view(const any_image_view<ViewTypes>& src,CC cc) {~ ^ boost/gil/extension/dynamic_image/image_view_factory.hpp:201:144: warning: unused parameter 'cc' [-Wunused-parameter] typename color_converted_view_type<any_image_view<ViewTypes>, DstP, CC>::type any_color_converted_view(const any_image_view<ViewTypes>& src,CC cc) {~ ^ boost/gil/io/device.hpp:446:31: warning: unused parameter 'data' [-Wunused-parameter] void write( const byte_t* data ^ boost/gil/io/device.hpp:447:31: warning: unused parameter 'count' [-Wunused-parameter] , std::size_t count ) ^ boost/gil/io/device.hpp:471:35: warning: unused parameter 'data' [-Wunused-parameter] std::size_t read( byte_t* data ^ boost/gil/io/device.hpp:472:35: warning: unused parameter 'count' [-Wunused-parameter] , std::size_t count ) ^ * locale: boost/locale/utf.hpp:224:17: warning: cette instruction peut poursuivre son chemin [-Wimplicit-fallthrough=] c = (c << 6) | ( tmp & 0x3F); ^ boost/locale/utf.hpp:225:13: note: ici case 2: ^~~~ boost/locale/utf.hpp:231:17: warning: cette instruction peut poursuivre son chemin [-Wimplicit-fallthrough=] c = (c << 6) | ( tmp & 0x3F); ^ boost/locale/utf.hpp:232:13: note: ici case 1: ^~~~ * geometry: boost/geometry/formulas/vertex_longitude.hpp:340:32: warning: unused parameter 'lon1' [-Wunused-parameter] static inline CT apply(CT& lon1, ^ boost/geometry/formulas/vertex_longitude.hpp:341:32: warning: unused parameter 'lat1' [-Wunused-parameter] CT& lat1, ^ boost/geometry/formulas/vertex_longitude.hpp:343:32: warning: unused parameter 'lat2' [-Wunused-parameter] CT& lat2, ^ boost/geometry/formulas/vertex_longitude.hpp:344:38: warning: unused parameter 'vertex_lat' [-Wunused-parameter] CT const& vertex_lat, ^ boost/geometry/formulas/vertex_longitude.hpp:345:32: warning: unused parameter 'alp1' [-Wunused-parameter] CT& alp1, ^ boost/geometry/formulas/vertex_longitude.hpp:346:44: warning: unused parameter 'azimuth_strategy' [-Wunused-parameter] Strategy const& azimuth_strategy) ^ boost/geometry/strategies/spherical/intersection.hpp:544:81: warning: unused parameter 'b2' [-Wunused-parameter] Point2 const& b1, Point2 const& b2, // in ^ boost/geometry/algorithms/detail/envelope/segment.hpp:156:61: warning: unused parameter 'lon1' [-Wunused-parameter] static inline void compute_box_corners(CalculationType& lon1, ^ boost/geometry/algorithms/detail/envelope/segment.hpp:158:61: warning: unused parameter 'lon2' [-Wunused-parameter] CalculationType& lon2, ^ boost/geometry/strategies/spherical/intersection.hpp:544:81: warning: unused parameter 'b2' [-Wunused-parameter] Point2 const& b1, Point2 const& b2, // in ^ * asio (windows 32 and 64 bits with mingw w64 + g++ 8.2.0) : /softs/win32-mingw-8.2.0/release/boost/include/boost/asio/detail/impl/win_iocp_socket_service_base.ipp: Dans la fonction membre « boost::system::error_code boost::asio::detail::win_iocp_socket_service_base::cancel(boost::asio::> /softs/win32-mingw-8.2.0/release/boost/include/boost/asio/detail/impl/win_iocp_socket_service_base.ipp:253:51: warning: transtypage entre types de fonctions incompatibles de « FARPROC » {aka « int (__attribute__((stdcall)) *)()> cancel_io_ex_t cancel_io_ex = (cancel_io_ex_t)cancel_io_ex_ptr; ^~~~~~~~~~~~~~~~ * ublas: /softs/lin64-gcc-8.2.0/debug/boost/include/boost/numeric/ublas/matrix_expression.hpp:2224:17: warning: cette instruction « if » ne protège pas… [-Wmisleading-indentation] if (it2_ != it2_end_) ^~ /softs/lin64-gcc-8.2.0/debug/boost/include/boost/numeric/ublas/matrix_expression.hpp:2227:21: note: …cette instruction, mais l'indentation de cette dernière est trompeuse car elle fait croire qu'elle est gardée par le « if » if (it2_ != it2_end_) { ^~ boost/numeric/ublas/functional.hpp:1673:57: warning: unused parameter 'size_i' [-Wunused-parameter] size_type upper_element (size_type i, size_type size_i, size_type j, size_type size_j) { ^ boost/numeric/ublas/functional.hpp:1673:88: warning: unused parameter 'size_j' [-Wunused-parameter] size_type upper_element (size_type i, size_type size_i, size_type j, size_type size_j) { ^ * interprocess (windows mingw-w64 + g++ 8.2.0 32/64 bits): In file included from boost/interprocess/errors.hpp:41, from boost/interprocess/exceptions.hpp:24, from boost/interprocess/sync/file_lock.hpp:24, from Progs/delypse-transfer.cpp:32: boost/interprocess/detail/win32_api.hpp:189:8: warning: « struct boost::interprocess::winapi::IUnknown_BIPC » a des fonctions virtuelles et un destructeur non virtuel accessible [-Wnon-virtual-dtor] struct IUnknown_BIPC ^~~~~~~~~~~~~ boost/interprocess/detail/win32_api.hpp:200:8: warning: la classe de base « struct boost::interprocess::winapi::IUnknown_BIPC » a un destructeur non virtuel accessible [-Wnon-virtual-dtor] struct IWbemClassObject_BIPC : public IUnknown_BIPC ^~~~~~~~~~~~~~~~~~~~~ boost/interprocess/detail/win32_api.hpp:200:8: warning: « struct boost::interprocess::winapi::IWbemClassObject_BIPC » a des fonctions virtuelles et un destructeur non virtuel accessible [-Wnon-virtual-dtor] boost/interprocess/detail/win32_api.hpp:306:8: warning: la classe de base « struct boost::interprocess::winapi::IUnknown_BIPC » a un destructeur non virtuel accessible [-Wnon-virtual-dtor] struct IWbemContext_BIPC : public IUnknown_BIPC ^~~~~~~~~~~~~~~~~ boost/interprocess/detail/win32_api.hpp:306:8: warning: « struct boost::interprocess::winapi::IWbemContext_BIPC » a des fonctions virtuelles et un destructeur non virtuel accessible [-Wnon-virtual-dtor] boost/interprocess/detail/win32_api.hpp:345:8: warning: la classe de base « struct boost::interprocess::winapi::IUnknown_BIPC » a un destructeur non virtuel accessible [-Wnon-virtual-dtor] struct IEnumWbemClassObject_BIPC : public IUnknown_BIPC ^~~~~~~~~~~~~~~~~~~~~~~~~ boost/interprocess/detail/win32_api.hpp:345:8: warning: « struct boost::interprocess::winapi::IEnumWbemClassObject_BIPC » a des fonctions virtuelles et un destructeur non virtuel accessible [-Wnon-virtual-dtor] boost/interprocess/detail/win32_api.hpp:369:8: warning: la classe de base « struct boost::interprocess::winapi::IUnknown_BIPC » a un destructeur non virtuel accessible [-Wnon-virtual-dtor] struct IWbemServices_BIPC : public IUnknown_BIPC ^~~~~~~~~~~~~~~~~~ boost/interprocess/detail/win32_api.hpp:369:8: warning: « struct boost::interprocess::winapi::IWbemServices_BIPC » a des fonctions virtuelles et un destructeur non virtuel accessible [-Wnon-virtual-dtor] boost/interprocess/detail/win32_api.hpp:518:8: warning: la classe de base « struct boost::interprocess::winapi::IUnknown_BIPC » a un destructeur non virtuel accessible [-Wnon-virtual-dtor] struct IWbemLocator_BIPC : public IUnknown_BIPC ^~~~~~~~~~~~~~~~~ boost/interprocess/detail/win32_api.hpp:518:8: warning: « struct boost::interprocess::winapi::IWbemLocator_BIPC » a des fonctions virtuelles et un destructeur non virtuel accessible [-Wnon-virtual-dtor] In file included from boost/interprocess/errors.hpp:41, from boost/interprocess/exceptions.hpp:24, from boost/interprocess/sync/file_lock.hpp:24, from Progs/delypse-transfer.cpp:32: boost/interprocess/detail/win32_api.hpp: Dans la fonction « bool boost::interprocess::winapi::get_system_time_of_day_information(boost::interprocess::winapi::system_timeofday_information&) »: boost/interprocess/detail/win32_api.hpp:1676:58: warning: transtypage entre types de fonctions incompatibles de « boost::interprocess::winapi::farproc_t » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::interprocess:> dll_func::get(dll_func::NtQuerySystemInformation); ^ boost/interprocess/detail/win32_api.hpp: Dans la fonction « bool boost::interprocess::winapi::unlink_file(const char*) »: boost/interprocess/detail/win32_api.hpp:1892:78: warning: transtypage entre types de fonctions incompatibles de « boost::interprocess::winapi::farproc_t » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::interprocess:> (NtSetInformationFile_t)dll_func::get(dll_func::NtSetInformationFile); ^ boost/interprocess/detail/win32_api.hpp:1894:94: warning: transtypage entre types de fonctions incompatibles de « boost::interprocess::winapi::farproc_t » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::interprocess:> NtQueryObject_t pNtQueryObject = (NtQueryObject_t)dll_func::get(dll_func::NtQueryObject); ^ boost/interprocess/detail/win32_api.hpp:1966:85: warning: transtypage entre types de fonctions incompatibles de « boost::interprocess::winapi::farproc_t » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::interprocess:> NtOpenFile_t pNtOpenFile = (NtOpenFile_t)dll_func::get(dll_func::NtOpenFile); ^ boost/interprocess/detail/win32_api.hpp:1967:73: warning: transtypage entre types de fonctions incompatibles de « boost::interprocess::winapi::farproc_t » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::interprocess:> NtClose_t pNtClose = (NtClose_t)dll_func::get(dll_func::NtClose); ^ boost/interprocess/detail/win32_api.hpp: Dans la fonction « bool boost::interprocess::winapi::get_file_mapping_size(void*, long long int&) »: boost/interprocess/detail/win32_api.hpp:2413:63: warning: transtypage entre types de fonctions incompatibles de « boost::interprocess::winapi::farproc_t » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::interprocess:> (NtQuerySection_t)dll_func::get(dll_func::NtQuerySection); ^ boost/interprocess/detail/win32_api.hpp: Dans la fonction « bool boost::interprocess::winapi::get_semaphore_info(void*, long int&, long int&) »: boost/interprocess/detail/win32_api.hpp:2426:86: warning: transtypage entre types de fonctions incompatibles de « boost::interprocess::winapi::farproc_t » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::interprocess:> (winapi::NtQuerySemaphore_t)dll_func::get(winapi::dll_func::NtQuerySemaphore); ^ boost/interprocess/detail/win32_api.hpp: Dans la fonction « bool boost::interprocess::winapi::query_timer_resolution(long unsigned int*, long unsigned int*, long unsigned int*) »: boost/interprocess/detail/win32_api.hpp:2437:98: warning: transtypage entre types de fonctions incompatibles de « boost::interprocess::winapi::farproc_t » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::interprocess:> (winapi::NtQueryTimerResolution_t)dll_func::get(winapi::dll_func::NtQueryTimerResolution); ^ boost/interprocess/detail/win32_api.hpp: Dans la fonction « bool boost::interprocess::winapi::query_performance_counter(long long int*) »: boost/interprocess/detail/win32_api.hpp:2444:57: warning: transtypage entre types de fonctions incompatibles de « boost::interprocess::winapi::farproc_t » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::interprocess:> dll_func::get(dll_func::QueryPerformanceCounter); ^ boost/interprocess/detail/win32_api.hpp: Dans la fonction « bool boost::interprocess::winapi::query_performance_frequency(long long int*) »: boost/interprocess/detail/win32_api.hpp:2451:59: warning: transtypage entre types de fonctions incompatibles de « boost::interprocess::winapi::farproc_t » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::interprocess:> dll_func::get(dll_func::QueryPerformanceFrequency); ^ * atomic (OSX): boost/include/boost/atomic/detail/ops_gcc_x86_dcas.hpp:269:113: warning: unused parameter 'order' [-Wunused-parameter] static BOOST_FORCEINLINE storage_type exchange(storage_type volatile& storage, storage_type v, memory_order order) BOOST_NOEXCEPT

4 6

[release] Boost 1.68.0 Beta 1
by Marshall Clow 02 Aug '18

02 Aug '18

Boost release 1.67.0 beta 1 is now available at: https://dl.bintray.com/boostorg/beta/1.68.0.beta1/source/ The files are identical to the RC2 that was posted on Friday. The SHA256 checksums are as follows: 961d2bdc74c1499c931b32098842abba8883b1a89ef5c8f8f0ab0aff771a3ce5 boost_1_68_0_b1_rc2.7z 0364846258648e39908ca7cebfc2d2216eef6980c32aaf8276d2cfe73ef012e3 boost_1_68_0_b1_rc2.tar.bz2 d99105685a68907a76b0479ecde77915423246236ef0db9cb846c5bfc09b41f3 boost_1_68_0_b1_rc2.tar.gz 6158e0e961bfb0d8adeb2ea70337b08504668258025f0a873fb21eee3436d22e boost_1_68_0_b1_rc2.zip For details of what's in the release, see <http://www.boost.org/users/history/version_1_68_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

3 7

[release] 1.68.0 post-beta merges
by Marshall Clow 01 Aug '18

01 Aug '18

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See <https://github.com/boostorg/boost/wiki/Release-Beta-Merge-Policy> The master branch will close for the 1.68.0 release on August 1st. -- Marshall

11 34

[filesystem] PR backlog needs attention
by James E. King III 01 Aug '18

01 Aug '18

There are 29 open PRs going back 3 years. This backlog needs some attention. Some of the pull requests (like documentation changes to fix typos) are trivial. I ran into a warning while building another library that I found was already submitted as a fix in the PRs, but has missed the 1.68.0 release now. Thanks, Jim

4 5

Re: [boost] [Boost-users] [release] Boost 1.68.0 Beta 1 -> warnings in filesystem, locale, thread, stacktrace, container
by Frédéric 30 Jul '18

30 Jul '18

Hi, I have tested 1.68.0 on linux x86_64 with the following compilers: - g++ 8.2.0, - clang++ 5.0.2, - mingw-w64 + g++ 8.2.0 cross compiling to windows 32 bits, - mingw-w64 + g++ 8.2.0 cross compiling to windows 64 bits, - clang++ 5.0.2 cross compiliing to OSX 10.9 32 bits, - clang++ 5.0.2 cross compiliing to OSX 10.9 64 bits. I did not find any major issue. Just those warnings while building the libraries: * filesystem (g++ 8.2.0 and clang++ 5.0.2 on linux x86_64): libs/filesystem/src/operations.cpp: Dans la fonction « int {anonymous}::readdir_r_simulator(DIR*, dirent*, dirent**) »: libs/filesystem/src/operations.cpp:2126:18: warning: « int readdir_r(DIR*, dirent*, dirent**) » est obsolète [-Wdeprecated-declarations] { return ::readdir_r(dirp, entry, result); } ^~~~~~~~~ In file included from /usr/include/features.h:423, from /softs/gcc-8.2.0/include/c++/8.2.0/x86_64-pc-linux-gnu/bits/os_defines.h:39, from /softs/gcc-8.2.0/include/c++/8.2.0/x86_64-pc-linux-gnu/bits/c++config.h:508, from /softs/gcc-8.2.0/include/c++/8.2.0/cstddef:49, from ./boost/config/compiler/gcc.hpp:165, from ./boost/config.hpp:39, from ./boost/filesystem/operations.hpp:18, from libs/filesystem/src/operations.cpp:68: /usr/include/dirent.h:189:12: note: déclaré ici extern int __REDIRECT (readdir_r, ^~~~~~~~~~ * locale (many more than that one about deprecated std::auto_ptr): I wonder when auto_ptr will be removed but it would be nice to change it to unique_ptr. In file included from libs/locale/src/util/default_locale.cpp:10: ./boost/locale/util.hpp:180:28: warning: « template<class> class std::auto_ptr » est obsolète [-Wdeprecated-declarations] BOOST_LOCALE_DECL std::auto_ptr<base_converter> create_utf8_converter(); ^~~~~~~~ In file included from /softs/gcc-8.2.0/include/c++/8.2.0/bits/locale_conv.h:41, from /softs/gcc-8.2.0/include/c++/8.2.0/locale:43, from ./boost/locale/util.hpp:10, from libs/locale/src/util/default_locale.cpp:10: /softs/gcc-8.2.0/include/c++/8.2.0/bits/unique_ptr.h:53:28: note: déclaré ici template<typename> class auto_ptr; ^~~~~~~~ * thead with mingw w64 cross compiling to windows 32 bits on linux x86_64 with g++ 8.2.0: I guess this warning is due to the fact that time_t is 32 bits on windows 32 bits so this looks dangerous to me. libs/thread/src/win32/thread_primitives.cpp: Dans la fonction « boost::detail::win32::ticks_type boost::detail::win32::{anonymous}::get_tick_count_init() »: libs/thread/src/win32/thread_primitives.cpp:97:120: warning: transtypage entre types de fonctions incompatibles de « boost::winapi::FARPROC_ » {aka « int (__attribute__((stdcall)) *)() »} vers « boost::detail::win32::detail::gettickcount64_t » {aka « long long unsigned int (__attribute__((stdcall)) *)() »} [-Wcast-function-type] (boost::detail::win32::detail::gettickcount64_t)boost::winapi::get_proc_address(hKernel32, "GetTickCount64"); * stacktrace (windows 32 and 64 bits): In file included from ./boost/winapi/file_management.hpp:17, from ./boost/stacktrace/detail/safe_dump_win.ipp:20, from ./boost/stacktrace/safe_dump_to.hpp:210, from ./boost/stacktrace/frame.hpp:20, from ./boost/stacktrace/detail/frame_unwind.ipp:15, from libs/stacktrace/build/../src/basic.cpp:14: ./boost/winapi/overlapped.hpp:38:9: warning: le C++ ISO interdit les structures anonymes [-Wpedantic] }; ^ * iostreams (windows 64 bits): libs/iostreams/src/mapped_file.cpp: Dans la fonction membre « void boost::iostreams::detail::mapped_file_impl::try_map_file(boost::iostreams::detail::mapped_file_impl::param_type) »: libs/iostreams/src/mapped_file.cpp:324:29: warning: comparaison d'expressions entières de types signés différents: « boost::iostreams::stream_offset » {aka « long long int »} et « boost::iostreams::mapped_file_source::size_type » {aka « long long unsigned int »} [-Wsign-compare] (SIZE_T) (size_ != max_length ? size_ : 0), ~~~~~~^~~~~~~~~~~~~ gcc.compile.c++ bin.v2/libs/iostreams/build/gcc-8.2.0/debug/link-static/target-os-windows/threading-multi/gzip.o * container (OSX 32 and 64 bits, clang 5.0.2): many locations with this warning: In file included from libs/container/src/alloc_lib.c:24: In file included from libs/container/src/dlmalloc_ext_2_8_6.c:36: libs/container/src/dlmalloc_2_8_6.c:4085:27: warning: 'sbrk' is deprecated [-Wdeprecated-declarations] char* base = (char*)CALL_MORECORE(0); ^ libs/container/src/dlmalloc_2_8_6.c:1714:37: note: expanded from macro 'CALL_MORECORE' #define CALL_MORECORE(S) MORECORE_DEFAULT(S) ^ libs/container/src/dlmalloc_2_8_6.c:666:26: note: expanded from macro 'MORECORE_DEFAULT' #define MORECORE_DEFAULT sbrk ^ /softs/osxcross-10.9-5.0.2/bin/../SDK/MacOSX10.9.sdk/usr/include/unistd.h:580:1: note: 'sbrk' has been explicitly marked deprecated here __deprecated ^ /softs/osxcross-10.9-5.0.2/bin/../SDK/MacOSX10.9.sdk/usr/include/sys/cdefs.h:156:37: note: expanded from macro '__deprecated' #define __deprecated __attribute__((deprecated)) ^

2 2

Release notes piling up
by James E. King III 30 Jul '18

30 Jul '18

There are 12 PRs for updating the documentation (they are going to have merge conflicts)... who is managing that for this release cycle? https://github.com/boostorg/website/pulls - Jim

5 8

TROJAN INFECTION boost 1.67 binaries for Windows x64 MSVC 14.1
by Zipper Fish 28 Jul '18

28 Jul '18

Dear boost developers and/or release managers: Today I downloaded boost_1_67_0-msvc-14.1-64.exe from the Windows binaries downloads page: https://dl.bintray.com/boostorg/release/1.67.0/binaries/ The file contains a Trojan, according to Windows Defender. Screenshot: https://usercontent.irccloud-cdn.com/file/Uy6o19AC/2018-07-26%2016_29_52-Wi… Someone should verify this & check the other pre-built binaries ASAP to reduce exposure. Thank you & best regards

6 11

Design question SafeFloat
by Damian Vicino 27 Jul '18

27 Jul '18

Hi, I'm working in simplifying safe_float to prepare it for future review. For now I'm focusing in a C++17 compatible version. Currently safefloat receives 2 template parameters: template<typename FP, typename P> class safe_float ... Where FP is the floating point value being made "safe", float, double, long double ... and P is a Policy of what to check and how to react. The how to react is a class that I pass by template parameter to the Policy. So, policy looks like: template<typename R> class policy_x .... I had a very complicated way of producing those policies, I used many TMP tricks so the logic stays in the policy and combines, but now that if-constexpr is available it may not make sense to take that path anymore. And, I see it may be better to simplify as much as possible. So, I'm thiking in make policy like a "config" description and put if constexprs in the safe_float class to decide what to do based in that. I want a bad policy to fail execution. I'm wondering what is the best approach for defining that "config-like" policy. A policy check is a bidimensional matrix of the operation affected and the flags considered (FE_ENV flags). For example, I want a policy to tell something like "check overflow in additions and underflow in division". These are the options I'm considering 1) define typenames for each flag and assign them tuple of affected operations class addition; class division; class multiplication; class subtraction; template<typename R> struct policy_x { using reporter=R; using overflow=tuple<addition>; using underflow=tuple<division>; using invalid=tuple<>; using inexact=tuple<>; }; 2) define typename by operation, passing class with constexprs of flags being evaluated struct empty_check{ static constexpr bool check_overflow=false; static constexpr bool check_underflow=false; static constexpr bool check_invalid=false; static constexpr bool check_inexact=false; }; struct check_overflow : public empty_check { static constexpr bool check_overflow=true; }; struct check_underflow : public empty_check { static constexpr bool check_underflow=true; }; template<typename R> struct policy_x { using reporter=R; using addition=check_overflow; using subtraction=empty_check; using multiplication=empty_check; using division=check_underflow; }; 3) similar to 2, but using true_type, and false_type in place of constexpr variables. struct empty_check{ using check_overflow=false_type; using check_underflow=false_type; using check_invalid=false_type; using check_inexact=false_type; }; struct check_overflow : public empty_check { using check_overflow=true_type; }; struct check_underflow : public empty_check { using check_underflow=true_type; }; template<typename R> struct policy_x { using reporter=R; using addition=check_overflow; using subtraction=empty_check; using multiplication=empty_check; using division=check_underflow; 4) other options? Thanks for any comments in advance. Damian

3 4

Promise/A+ like javascript in cpp
by hawk x 27 Jul '18

27 Jul '18

Hi, Javascript Promise creates a task chain to help develop asynchronized application with single thread. I did not find a good implement of this kind of "Promise" in c++, so i create one named "promise-cpp" here -- https://github.com/xhawk18/promise-cpp with which, we can write asynchronized tasks like sequential flows. Here's an example of promisifed http client in boost::asio -- https://github.com/xhawk18/promise-cpp/blob/master/test/asio_http_client.cpp "promise-cpp" would be the best friend to boost::asio's asynchronized task for single thread, and it is not std::promise. Thanks for you reviewing this library and any suggestion will be appreciated!

3 4

Docker environment(s) for Boost Development
by James E. King, III 26 Jul '18

26 Jul '18

I submitted a pull request into the superproject containing some docker scripts. The intention of this is to simplify managing a docker build environment for boost: https://github.com/boostorg/boost/pull/184 I'm wondering if folks will find this useful, and whether folks think this should be in its own submodule instead of being in boostorg/boost. I only have an Ubuntu Bionic environment in this pull request but it wouldn't be that difficult to add debian, centos, and others, as well as various versions of each. I have tested it on Unix and on Windows. On Unix the performance is quite good overall - but on Windows since they use SMB to do the sharing it is really slow (I would say a good 20 times slower between typing "b2" and getting the first output as it scans through all the files. I would recommend continuing to use a virtual machine on Windows Hosts for unix boost development, but this option is there and hopefully they will improve things. This partially came out of the discussion we had a number of months back about how we handle third party dependencies. For the most part one has to look at README files in various locations to learn about them. This is an attempt to pull all the dependencies together for a complete build into one place (the Dockerfile). One day when Microsoft supports Visual Studio compilation inside a reasonably sized windows container (i.e. based on nanoserver and not Windows Server Core), I'd like to add that as well since managing the dependencies on Windows is a bit harder (you usually have to build them). Thanks, Jim

5 8

boost include directory question
by Robert Ramey 21 Jul '18

21 Jul '18

The current instructions for doing boost development are approximately: a) clone the boost super project from github. b) invoke b2 headers which does one of: 1) creates links in the boost root directory to individual projects 2) or copies boost directories from individual libraries into the boost root directory. depending on whether it is a windows system or other system. Since I test for both windows and other systems, this is somewhat of a pain. In considering my options, I'm wondering if specifying all the boost library include directories in the CPLUS_INCLUDE_PATH environmental variable (gcc compilers) or INCLUDE (msvc). a) Has this been considered before? b) Was it considered when the current system was setup? c) Is there an reason why it wouldn't be a good idea? Anyone with information on this is free to chime in. Actually anyone is free to chime in. Robert Ramey

3 4

[concept_check] stl_concept_covering - compiler, stdlib, boost, or test issue?
by James E. King III 20 Jul '18

20 Jul '18

Hi folks, The test stl_concept_covering is annotated with "gcc bug" on a number of tests, and yet gcc 7.3.0 (with libstdc++) and clang-6.0 (with libc++ or libstdc++) fail to compile this test, mostly on the sections marked as a bug. For example: "/usr/bin/clang++-6.0" -c -x c++ -stdlib=libc++ -fPIC -m64 -O0 -fno-inline -Wall -g -DBOOST_ALL_NO_LIB=1 -I"../.." -o "../../bin.v2/libs/concept_check/test/ stl_concept_covering.test/clang-linux-6.0/debug/stl_concept_covering.o" "test/stl_concept_covering.cpp" In file included from test/stl_concept_covering.cpp:9: /usr/local/include/c++/v1/algorithm:999:24: error: invalid operands to binary expression ('boost::input_iterator_archetype<boost::equality_comparable2_first_ar chetype<boost::null_archetype<int> >, 0>::reference' and 'const boost::equality_comparable2_second_archetype<boost::null_archetype<int> >') if (*__first == __value_) ~~~~~~~~~~ ^ ~~~~~~~~ test/stl_concept_covering.cpp:152:15: note: in instantiation of function template specialization 'std::__1::find<boost::input_iterator_archetype<boost::equalit y_comparable2_first_archetype<boost::null_archetype<int> >, 0>, boost::equality_comparable2_second_archetype<boost::null_archetype<int> > >' requested here in = std::find(in, in, value); Full log with gcc-7.3.0 here: https://travis-ci.org/boostorg/concept_check/jobs/404203085#L1517 What's interesting is that if I change the type of in to an input_iterator_archetype_no_proxy the test passes. When I look at the concept_archetypes I see that input_iterator_archetype is a template with a default parameter, but also defines "reference" as a structure with an operator(), instead of using a typedef which is what I usually see done. So this makes me wonder if it's really a compiler issue (both compilers and std C++ libs complain the same way though) or if the archetype is invalid. I'm not sure the best course of action. It does cause most CI build jobs to fail, except MSVC jobs interestingly enough. Any thoughts you could share on this would be appreciated. The PR with all the build jobs showing errors can be found here: https://github.com/boostorg/concept_check/pull/13 Thanks, Jim

3 4

[range] [concepts] Boost 1.68 beta build error in RandomAccessIteratorConcept using latest MSVC
by Viktor Sehr 20 Jul '18

20 Jul '18

The following error is emitted in latest MSVC building Boost 1.68 beta: 1>\boost\range\concepts.hpp(257): error C3646: 'n': unknown override specifier 1>\boost\range\concepts.hpp(264): note: see reference to class template instantiation 'boost::range_detail::RandomAccessIteratorConcept<Iterator>' being compiled 1>\range\concepts.hpp(257): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int Unfortunately I'm not competent enough to determine what is causing the error: Full struct: template<class Iterator> struct RandomAccessIteratorConcept : BidirectionalIteratorConcept<Iterator> { #if BOOST_RANGE_ENABLE_CONCEPT_ASSERT BOOST_RANGE_CONCEPT_ASSERT(( Convertible< BOOST_DEDUCED_TYPENAME RandomAccessIteratorConcept::traversal_category, random_access_traversal_tag >)); BOOST_CONCEPT_USAGE(RandomAccessIteratorConcept) { i += n; i = i + n; i = n + i; i -= n; i = i - n; n = i - j; } private: // MSVC 14.1 - avoid C4596: 'difference_type': illegal qualified name in member declaration #if defined(_MSC_VER) && _MSC_VER >= 1912 BOOST_DEDUCED_TYPENAME difference_type n; #else BOOST_DEDUCED_TYPENAME RandomAccessIteratorConcept::difference_type n; #endif Iterator i; Iterator j; #endif }; br/Viktor Sehr

3 3

[system] Clang CI builds broken because of constexpr
by Andrey Semashev 20 Jul '18

20 Jul '18

Hi, I'm seeing these errors in Travis CI builds with Clang 3.8, 3.9, 4.0 and 5.0: ./boost/system/error_code.hpp:232:41: error: constexpr constructor never produces a constant expression [-Winvalid-constexpr] BOOST_SYSTEM_CONSTEXPR explicit std_category( boost::system::error_category const * pc ): pc_( pc ) ^ ./boost/system/error_code.hpp:232:41: note: non-constexpr constructor 'error_category' cannot be used in a constant expression /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/system_error:69:5: note: declared here error_category() noexcept; ^ I'm assuming this is because the compiler uses libstdc++ from gcc 4.8, in which error_category() is not marked constexpr. Can this be fixed somehow?

2 2

Looking for help on preparing for review
by Damian Vicino 20 Jul '18

20 Jul '18

Hi, I'm preparing my library safe_float to be proposed for review. The library was born in the GSOC2015, but it never reached a review ready state. My plan is to change that in the next few months. At this point, I'm looking for some volunteers to proof-read the documentation. Code is going through major rewrite, and I will send another mail looking for help with reviewing the code when that is done. The most current documentation can be read directly from the web here: https://sdavtaker.github.io/safefloat/ Any comment is appreciated. Best regards, Damian

5 9

[Compute] Conflict between boost::compute::zip_iterator and boost::iterators::zip_iterator
by fortenberry.rm＠protonmail.com 18 Jul '18

18 Jul '18

I'd like to use boost::compute and boost::range together, like below, but if I uncomment the '#include <boost/range/combine.hpp>' line I get an error saying that boost::compute::zip_iterator and boost::iterators::zip_iterator are ambiguous. Is there a way around this, so that I can use boost::compute and boost::range together in the same cpp file? I am using on Windows vs2015 64bit. Boost 1.67.0. Code: #include <vector> #include <iostream> #include <algorithm> //#include <boost/range/combine.hpp> #include <boost/compute/lambda.hpp> #include <boost/compute/functional/math.hpp> #include <boost/compute/container/vector.hpp> #include <boost/compute/algorithm/transform.hpp> namespace compute = boost::compute; using compute::float4_; using compute::lambda::_1; using compute::lambda::_2; using compute::lambda::distance; int main() { // get default device and setup context compute::device device = compute::system::default_device(); compute::context context(device); compute::command_queue queue(context, device); // generate random data on the host std::vector<float4_> a(10000); std::vector<float4_> b(10000); std::vector<float> r(10000); std::generate((float*)a.data(), (float*)(a.data() + a.size()), rand); std::generate((float*)b.data(), (float*)(b.data() + b.size()), rand); // create a vector on the device compute::vector<float4_> _a(a.size(), context); compute::vector<float4_> _b(b.size(), context); compute::vector<float> _r(r.size(), context); // transfer data from the host to the device compute::copy(a.begin(), a.end(), _a.begin(), queue); compute::copy(b.begin(), b.end(), _b.begin(), queue); boost::compute::transform( _a.begin(), _a.end(), _b.begin(), _r.begin(), distance(_1, _2), queue ); // copy values back to the host compute::copy(_r.begin(), _r.end(), r.begin(), queue); for (int i = 0; i < a.size(); ++i) { float4_ va = a[i]; float4_ vb = b[i]; float vr = r[i]; float e = std::sqrt(std::pow(va[0] - vb[0], 2) + std::pow(va[1] - vb[1], 2) + std::pow(va[2] - vb[2], 2) + std::pow(va[3] - vb[3], 2)); std::cout << std::setprecision(12); if (std::abs(e - vr) > 1e-2) std::cout << e << " != " << vr << "\n"; } return 0; } Error, truncated for brevity. I can post the full error log if it is helpful: 1>------ Build started: Project: demo, Configuration: Debug x64 ------ 1> demo.cpp 1> This header is implementation detail and provided for backwards compatibility. 1>C:\local\boost_1_67_0\boost/compute/algorithm/transform.hpp(67): error C2668: 'boost::compute::make_zip_iterator': ambiguous call to overloaded function 1> C:\local\boost_1_67_0\boost/compute/iterator/zip_iterator.hpp(276): note: could be 'boost::compute::zip_iterator,boost::compute::buffer_iterator,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>> boost::compute::make_zip_iterator,boost::compute::buffer_iterator,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>>(IteratorTuple)' 1> with 1> [ Thanks, Madison

2 2

[boostbook] cleanup / modernization
by James E. King III 18 Jul '18

18 Jul '18

I would have opened an "issue" on the boostorg/boostbook project, however, that is not enabled. (Perhaps someone should enable it?) I have duplicated the boostbook setup scripts into the docker setup environment for Ubuntu Bionic and I have found that all of the packages that boostbook depends on are ancient. PackageVersionLast ModifiedHost docbook-xsl 1.75.2 2009 SourceForge <http://sourceforge.net/projects/docbook/files/docbook-xsl/1.75.2/docbook-xs…> docbook-xml 4.2 2002 oasis-open.org <http://www.oasis-open.org/docbook/xml/4.2/docbook-xml-4.2.zip> fop 0.94 2007 Apache <http://archive.apache.org/dist/xmlgraphics/fop/binaries/fop-0.94-bin-jdk1.4…> These tools are quite old and it is only a matter of time before the older versions could be removed. These external sites are under no particular requirement to keep these older versions of software available. At some point some of these tools may no longer work with current operating system tools, for example "fop" says that it is for "JDK 1.4". Each of these tools has a newer version. A project should be initiated now to modernize the documentation build to use more recent versions of these tools before it becomes a critical release blocker at a bad time. - Jim

3 2

[iostreams] libstdc++ vs MSVC exception handling behavior in seekg, seekp
by James E. King III 17 Jul '18

17 Jul '18

I found a disabled test in Boost.Iostreams called stream_state_test. It was disabled because it was thought it only tests the standard library implementation. Partially true, but it also tests some parts of iostreams so I have been working to re-enable it along with the generic CI upgrades. It looks like libstdc++ and the standard library that comes with MSVC (is it still Dinkumware? It used to be...) handle exceptions on stream seekg and seekp differently. I haven't consulted the standards documents yet, but I found this reference for exception handling: http://www.cplusplus.com/reference/istream/istream/seekg/ which states, " Any exception thrown by an internal operation is caught and handled by the function, setting badbit <http://www.cplusplus.com/ios_base::badbit>. " Sitting in the debugger where the test throws an exception in error_device::seek, there is no exception handling within iostreams or in msvcp140d code paths for a call to seekg, while the libstdc++ implementation is able to pass all of the tests. This leads to a couple questions: 1. Are the standards clear in this area? 2. Is someone violating them? A cursory review (such as this) leads me to believe that the MSVC C++ runtime implementation is not properly handling exceptions here. The sources for seekg in libstdc++ wrap the internals in a try catch in order to restore state. The sources for seekg in the MSVCPRT do not. - Jim

2 1

Safe Float design question
by Damian Vicino 17 Jul '18

17 Jul '18

Hi, I looking for some design advice. The context: - I'm revisiting SafeFloat after some time and, while doing so, I'm rethinking all the decisions from the past. Idea is to sent for review in the following months. - The goal of the library is being a drop-in replacement for float, that adds checks to floating point operations and reports when a check failed. Without SafeFloat, someone could write something like this: #include <iostream> #include <limits> #include <cfenv> using namespace std; int main(){ float a = 1.0f; float b = numeric_limits<float>::max(); feclearexcept(FE_ALL_EXCEPT); float c = a/b; if(fetestexcept(FE_UNDERFLOW)) { cout << "underflow result\n"; } } What I expect when using safe_float is to declare upfront "what checks" I care about, "what operations" to check, and "what to do when a check fails". Some intention examples: - I would like to check there was no "overflow_to_infinite" in "addition operations", otherwise I "throw exception".. - I would like to check there was no "division by zero" in "division", otherwise I will "log to cerr and ignore it". - I would like to check there was no "inexact" "addition", otherwise I return an boost::unexpected. I have at least 5 things to check (there is 5 flags in c++11::fenv). I have at least 4 places to check (+/-/*//) and I want to keep what to do about it customizable. In addition, sometimes I want to check multiple things "overflow and underflow", etc... So, the question is how the user can pass all that information to the type and it doesn't look as horrible nonsense. My original option was: int main(){ using CHECK = compose_policy<check_addition_overflow, check_division_by_zero, check_division_underflow>::type; using REPORT = report_throw_on_failure; using sf = safe_float<float, CHECK, REPORT>; try{ sf a = 1.0_sf; sf b = numeric_limits<sf>::max(); auto c = a/b; } catch (safe_float_exception e){ cout << e.message(); //this outputs there was a underflow } } Please comment in what you think about this way to use. Is there a better way to specify the policies to apply that I should try? Best regards, Damian I expect when using safe float to write some code like this: int main(){ safe_float<float> }

2 3

[system] Clang CI builds broken because of constexpr
by Andrey Semashev 17 Jul '18

17 Jul '18

Hi, I'm seeing these errors in Travis CI builds with Clang 3.8, 3.9, 4.0 and 5.0: ./boost/system/error_code.hpp:232:41: error: constexpr constructor never produces a constant expression [-Winvalid-constexpr] BOOST_SYSTEM_CONSTEXPR explicit std_category( boost::system::error_category const * pc ): pc_( pc ) ^ ./boost/system/error_code.hpp:232:41: note: non-constexpr constructor 'error_category' cannot be used in a constant expression /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/system_error:69:5: note: declared here error_category() noexcept; ^ I'm assuming this is because the compiler uses libstdc++ from gcc 4.8, in which error_category() is not marked constexpr. Can this be fixed somehow?

1 0

[graph] disjoint_sets
by James E. King III 17 Jul '18

17 Jul '18

Hello folks in the Boost.Graph team, The CMT currently maintains Boost.DisjointSets which contains a class that is only used by Boost.Graph and Boost.GraphParallel. The headers are published in "boost/pending" right now. Given the CMT has a considerable workload already I would like to discuss moving disjoint_sets into Boost.Graph, as long as it satisfies the requirements for the two repositories currently consuming it. This would be for 1.69.0. Any thoughts, objections, considerations on this (open to anyone)? Thanks, Jim

2 3

Heads up about future standards annexing new identifiers
by Marshall Clow 16 Jul '18

16 Jul '18

As facilities get added to the standard library, they need names. When this happens, it restricts what other developers can and cannot do in their programs. For example, one cannot do this and expect most anything in the standard library to work: #define allocate(T) . new T [ But you knew about that ]. What you may not have known about was that the standards committee has voted contract enforcement/checking facilities into the draft standard (which will probably be C++20). This includes attributes named: 'expects' and 'ensures'. (all lower case) I have checked all of boost, and with the possible exception of Boost.Contract, we do not have any macros with those names. But you might want to keep your eyes open. -- Marshall P.S. These are not keywords - so it's perfectly fine to have member functions with these names. Variables, too. Probably even free functions - though I haven't tried that. But macros are right out ;-) P.P.S. For people who are interested, the paper is http://wg21.link/P0542

2 1

Searching for a intrusive::avltree_algorithms/bstree_algorithms dev
by Thimothée Virgoulay 16 Jul '18

16 Jul '18

Hello I'm working with the boost library (intrusive: : avltree_algorithms/bstree_algorithms ) and I found some bugs (not sure, maybe it's me who haven't understood the algorithm logic ). I have made hotfixes , add functions and it's working. But I don't know if this change were fine or needed. So I 'm searching for someone who can exchange with me about this library. Thimothée Virgoulay, second's year master degree in Bioinformatics at Montpellier University, France.

4 3

[rational] 1.68.0 merge permission
by James E. King III 16 Jul '18

16 Jul '18

The addition of pow() for rational was identified as a problem in beta testing. It has been reverted for now, and an issue added to the github repository to revisit it after 1.68.0. There are two commits I would like to merge to master: 1. The revert of pow which caused problems 2. A CI-only change to .travis.yml that fixes codecov.io and coverity scan build jobs in light of recent security upgrades in travis CI. No production code changes, zero affect on the release build workflow. This will allow the build status to remain green for the repository as it is merged to master. Thanks, Jim

2 1

[CMT] 1.68.0 merge permission
by James E. King III 16 Jul '18

16 Jul '18

The CI builds in CMT repositories are failing since Travis CI updated their backend last week. The fix is simple and isolated in the .travis.yml file in each repository which is not part of the boost release build cycle. All repositories develop branch have been updated with the fix. I'd like to merge the fix in the CMT repositories into master to eliminate the remaining failed build indicators. Given the change is only in .travis.yml I hope that will be acceptable. Without the fix any cron job on master in these repositories will fail in codecov.io and covscan. Thanks, Jim

2 1

Invalid arguments
by randy 15 Jul '18

15 Jul '18

I’ve the following function but i get invalid arguments error , can please someone tell me where’s this invalid param or argument : int Asio_Send_Pck(int iSendt,int Lsocket,char * Lbuff,int Len) { session* iTempSession = reinterpret_cast<session*>(Lsocket); boost::asio::async_write(iTempSession->socket() , boost::asio::buffer(Lbuff, Len), boost::bind(&session::handle_write, iTempSession, boost::asio::placeholders::error, iTempSession->data, iSendt )); return 0; };

2 1

Boost.Signals deprecation and removal
by James E. King, III 15 Jul '18

15 Jul '18

This first implementation of signals has been deprecated since the 1.54 release. (When) are we going to remove it? It is under management of the CMT, and it has been deprecated for over 10 major releases. I would like to suggest we remove it in the Boost 1.68.0 release. - Jim

9 9

Reporting accurate code coverage
by James E. King III 13 Jul '18

13 Jul '18

General Code Coverage Tip (for everyone): Measure your coverage using branches, not lines. Branch coverage tells you how well error cases are tested and therefore a far better measure of quality than line-based. I have seen over 90% line coverage but the branch coverage is more like 60% to 70% on average over the boost CMT-managed repositories. Here's the shell script I use on travis to generate the data and feed it to codecov.io: https://github.com/jeking3/boost-ci/blob/master/ci/travis/codecov.sh The trick is to feed --rc lcov_branch_coverage=1 to the correct commands to generate and preserve the branch information. Thanks, - Jim

3 3

[boost-ci] code coverage build fix
by James E. King III 13 Jul '18

13 Jul '18

For folks using boost-ci integration, here is a fix to your .travis.yml file to enable code coverage builds to work again. I received confirmation from Travis CI that a back-end update on their end corrected some security issues which necessitates this change. https://github.com/boostorg/rational/pull/22/files In the script section of the coverage job, replace the commands: cd lcov && sudo make install with: export PATH=/tmp/lcov/bin:$PATH Thanks, Jim

1 0

[boost-ci] codecov.io integration
by James E. King III 13 Jul '18

13 Jul '18

Folks using boost-ci integration may see the code coverage builds failing. Part of the .travis.yml script includes logic to update lcov to a newer version for branch coverage to work. These build jobs are breaking due to enforcement of the sudo restriction. I am working on a way to fix this and will send out an update when I have a solution. - Jim

1 0

[Range] 1.68 master/beta MSVC compilation error with /fpermissive-
by Vinnie Falco 13 Jul '18

13 Jul '18

When compiling using /fpermissive- (enable strict conformance) I get the following compilation error: boost\boost\range\concepts.hpp(257): error C3646: 'n': unknown override specifier boost\boost\range\concepts.hpp(264): note: see reference to class template instantiation 'boost::range_detail::RandomAccessIteratorConcept<Iterator>' being compiled boost\libs\beast\include\boost\beast\core\string.hpp(87): note: see reference to class template instantiation 'boost::basic_string_view<char,std::char_traits<char>>' being compiled boost\boost\range\concepts.hpp(257): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int boost\boost\range\concepts.hpp(257): error C3646: 'n': unknown override specifier boost\boost\range\concepts.hpp(264): note: see reference to class template instantiation 'boost::range_detail::RandomAccessIteratorConcept<Iterator>' being compiled I'm using the tip of master, digest 000bd8507f8a17ada2c1fef19158e16cdeabd631 Thanks

6 14

[Boost.Serialization] Help with PR fixing a memory leak in the current version
by Alexander Grund 12 Jul '18

12 Jul '18

Hi, TLDR: I would like https://github.com/boostorg/serialization/pull/105 to be merged for the next Boost release to fix a memory leak and need someone to review this or help getting it merge-ready. Details: Some time ago I made an analysis of a crash introduced in Boost 1.65.0 in the serialization part. The details are quite complicated as the cause is static initialization/destruction order in shared libraries which may even depend on compilers (could not confirm) or standard libraries (dito, observed in all tested versions). It boils down to a violation of the expected destruction order in the case of shared libraries. I observed how 2 global instances of the same type but from different shared libs are destroyed together although the 2nd should not yet be which causes a use-after-free from another global instance. The Singletons involved did have methods to detect, whether they are active or destroyed but they were kinda optimized away in Boost 1.65 leading to a crash which makes the whole library unusable. Not understanding the root cause of the crash lead to changing the singleton to use dynamic allocation, but not freeing it which leads to the memory leak that is currently in Boost. The current state of the develop-branch changed this back to the crash situation we had before making it unsuitable for the next release. Another pair of eyes would be great to check the PR and get this finally fixed. Thanks, Alex

6 33

[rational, spirit] 1.68.0 beta 2 bug report
by James E. King III 11 Jul '18

11 Jul '18

A bug reported by someone using a version of 1.68.0 (not specified): https://github.com/qtumproject/cpp-eth-qtum/issues/31#issuecomment-404257256 Seems to have something to do with the new pow template that was added to rational. This came from an old pull request that was simplified, however it seems pow is now a template defined in the namespace boost, and seems to have caused some issues. I'd guess this is only an issue inside boost namespace (so all boost headers) and not external namespaces. Not sure at the moment if the fix should be in rational or spirit. We could instead back out the change to rational for 1.68.0 where pow() was added into namespace boost. https://github.com/boostorg/rational/pull/21 - Jim

2 1

boost/context/all.hpp missing in 1.68.0beta1
by Roger Leigh 11 Jul '18

11 Jul '18

Is this intentional, or an unintentional regression? I was using this header in the CMake component checks to verify the presence of Boost.Context, and this is now breaking. I can update it to use a different header which has been present since 1.61, but this seems like a compatibility break, hence the question. Thanks, Roger

2 1

Fwd: [Range] 1.68 master/beta MSVC compilation error with /fpermissive-
by degski 11 Jul '18

11 Jul '18

It did go off-list. ---------- Forwarded message ---------- From: degski <degski(a)gmail.com> Date: 11 July 2018 at 19:16 Subject: Re: [boost] [Range] 1.68 master/beta MSVC compilation error with /fpermissive- To: Mateusz Loskot <mateusz(a)loskot.net> On 11 July 2018 at 18:56, Mateusz Loskot <mateusz(a)loskot.net> wrote: > (was your response intentionally direct and off-list?) > No, not intentionally, but it depends on how you send the email (because I pushed reply), like on this one (it would have gone off-list again). I had to add the mailing list back in. This doesn't happen with most posts. I'm not sure what you mean, but I meant the driver that Vinnie mentioned > I'm not totally sure what Vinnie mentions. But I'm talking about this one for stable <https://releases.llvm.org/6.0.1/LLVM-6.0.1-win64.exe> and this one for (almost) trunk <http://prereleases.llvm.org/win-snapshots/LLVM-7.0.0-r336178-win64.exe>. I have the impression Vinnie is talking about Clang/C2 <https://blogs.msdn.microsoft.com/vcblog/2016/04/06/clangc2-we-need-your-adv…>, but like I said it's not clear to me, that compiler, however, is discontinued. degski --- *"If something cannot go on forever, it will stop" - Herbert Stein*

1 0

[Histogram] Status of the review schedule
by Mateusz Loskot 11 Jul '18

11 Jul '18

Hi, Following some discussion in January this year, Hans Dembinski's Histogram library was scheduled for review in March. AFAICT, no review happened. What is the current status of the proposal? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 4

[geometry][units]
by Pranam Lashkari 11 Jul '18

11 Jul '18

I am trying to use boost.geometry with the integration of boost.units. What I want to do is store a coordinate point (e.g: Cartesian or spherical) which should be unit safe.(e.g a cartesian point with length unit meter should give error with cross product is done with cartesian point with length unit millimeter). For this I am using boost::geometry::model::point. Problems I am facing: 1. If I use something like boost::geometry::model::point<UnitClass, 3 ,boost::geometry::cs::cartesian> then all the operations like cross product and dot product will fail as units can not be multiplied and if we multiply then dimensions and units will change. 2. suppose I want to use spherical 3d coordinate then boost::geometry::model::point is cable accommodate only one type of class for all the underlying dimension(eg: distance, longitude and latitude). But in real case distance should be in length and longitude and latitude should be in angle unit. Is there any way to integrate boost.units with boost.geometry for the purpose I mentioned above. Thank you, Pranam Lashkari

1 0

Boost.Graph depth_first_visit algorithm
by Brook Milligan 09 Jul '18

09 Jul '18

The documentation on the Boost.Graph depth_first_visit algorithm indicates that the first argument is a non-const reference to an Incidence Graph. See https://www.boost.org/doc/libs/1_67_0/libs/graph/doc/depth_first_visit.html. However, in contrast the code in boost/graph/depth_first_search.hpp only implements the function for a _const_ reference to an Incidence Graph. I can see that changing the graph structure mid-traversal is a problem, but I have use cases in which graph properties (not graph structure) must be changed along the traversal. Thus, it seems that a valid use case is for this algorithm to work as documented, i.e., on a non-const graph. The attached patch implements overloads for the non-const versions of depth_first_{visit|search}, including overloads for the dfs_visitor member functions. Is there some reason not to extend the implemented interface in this way to better agree with the documentation? Cheers, Brook

1 0

Clang 600 and BOOST_SYSTEM_CONSTEXPR causes error_code.hpp compile failure.
by Paul A. Bristow 09 Jul '18

09 Jul '18

Having failed to build Boost libraries using Clang 6.0.0 using b2/bjam on Windows, I am now trying instead to use Codeblocks on Windows 10 to build static libraries. It comes to grief with these messages (the berbose gory details can be posted if anyone can help). In file included from I:\modular-boost\boost/system/system_error.hpp:14: I:\modular-boost\boost/system/error_code.hpp:409:88: error: variable does not have a constant initializer template<class T> BOOST_SYSTEM_REQUIRE_CONST_INIT system_error_category cat_holder<T>::system_category_instance; ^~~~~~~~~~~~~~~~~~~~~~~~ I:\modular-boost\boost/system/error_code.hpp:409:19: note: required by 'require_constant_initialization' attribute here template<class T> BOOST_SYSTEM_REQUIRE_CONST_INIT system_error_category cat_holder<T>::system_category_instance; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I:\modular-boost\boost/system/error_code.hpp:392:44: note: expanded from macro 'BOOST_SYSTEM_REQUIRE_CONST_INIT' # define BOOST_SYSTEM_REQUIRE_CONST_INIT [[clang::require_constant_initialization]] ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This seems to be the ultimate cause I:\modular-boost\boost/system/error_code.hpp:226:41: note: non-constexpr constructor 'error_category' cannot be used in a constant expression BOOST_SYSTEM_CONSTEXPR explicit std_category( boost::system::error_category const * pc ): pc_( pc ) Is this because BOOST_SYSTEM_CONSTEXPR should not be defined? I note this in error_code.hpp #if defined(__GNUC__) && (__GNUC__ == 7 || __GNUC__ == 8) && __cplusplus >= 201700L // https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83835 # undef BOOST_SYSTEM_HAS_CONSTEXPR #endif should this undef list also include clang, and if so which versions 600? Or is there something about Boost.config and Codeblocks on Windows? Adding unconditional # undef BOOST_SYSTEM_HAS_CONSTEXPR seems to work. Suggestions welcome. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

7 13

toolset=clang-win uses clang-linux-win?
by Peter Dimov 09 Jul '18

09 Jul '18

When I try `b2 toolset=clang-win` on Appveyor, I get `clang-linux-win` instead, that is, `-win` is interpreted as version for some reason, not as platform: https://ci.appveyor.com/project/pdimov/system/build/job/sjpdq5yrir2ewuhh Is this normal, or is it a bug in the clang toolset? Is there a magic command line incantation that would let me select clang-win?

3 7

[Boost Build] clang-win, <compatibility> property?
by degski 08 Jul '18

08 Jul '18

error: Please set <compatibility> property for visual studio version! How and to what value (VS2017 - 15.7.4, Compiler Version 19.14.26431 ) do I set the <compatibility> property using a project-config.jam file? The documentation <https://boostorg.github.io/build/manual/develop/index.html#bbv2.reference.t…> does not list clang at all, which probably means it works like gcc, there is obviously no <compatibility> property there. Help would be appreciated, then I can post some build results of 1.68-rc2. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*

1 0

python::numpy not built on windows binary installers
by Nicholas Devenish 07 Jul '18

07 Jul '18

Hi All, I just downloaded the windows boost binaries from https://dl.bintray.com/boostorg/release/1.67.0/binaries/, linked from the boost downloads page. They are missing the boost_numpy library. This (silently) doesn't build if the python installation that boost finds is missing numpy. This is listed as "Third Party" so apologies if this is the wrong place to report it - but it's not clear from the page who makes them. I also couldn't find any mention of this, so don't know if it's a deliberate exclusion. Nick

2 3