- Boost - lists.preview.boost.org

Increasing BOOST_PP_VARIADICS_SIZE
by Damien Buhl 20 Aug '18

20 Aug '18

Dear Edward, In comparison to BOOST_PP_SEQ, BOOST_PP_VARIADICS is limited to 64 elements while BOOST_PP_SEQ is limited 255. Is there a reason for the choice of 64 or could I patch BOOST_PP_VARIADICS to go as BOOST_PP_SEQ to a limit of 255 ? Or asked differently do you think there are in newer compilers/standards a way to have an unbounded BOOST_PP_VARIADICS implementation nowadays ? Warm Regards, -- Damien Buhl Software Developer +33 6 77 43 10 05

2 2

ABI issues with -std
by Peter Dimov 20 Aug '18

20 Aug '18

At some point, we'll need to acknowledge the problem which results from building Boost with one -std and user code with another, and deal with it somehow, if just by documenting. Most of our libraries don't suffer from it at the moment but Boost.System does, because of my changes; its ABI changes between 03/11/14. So I'm going to take the initial hit. :-) POSIX platforms have long been able to ignore ABI issues so we don't mangle the library names there at all, but now whether one builds Boost for C++03, C++11 or C++14 matters, and there's nothing to prevent linking C++xx to C++yy. Even with --layout=versioned, the cxxstd level is not encoded. The fact that the default C++ standard differs between g++ and clang++ doesn't help; when following the instructions of doing "b2 install", with g++6 and above you get C++14, but with g++5 or clang++ you get C++03. The latter is very rarely what one wants today.

7 26

Formal review request: Synapse
by Emil Dotchevski 16 Aug '18

16 Aug '18

Hello, I'm requesting a formal review for Synapse, a non-intrusive signal programming library. Synapse is a non-intrusive C++ signal programming library. It is able to register connections and emit signals from any C or C++ object of any type whatsoever. If two contexts share access to a C or C++ object, they can use that object as a randezvouz point of sorts, and communicate with each other through Synapse signals. A system of meta signals provides interoperability with other signal programming libraries and callback APIs. In particular Synapse can be used to safely register C++ function objects, including lambda functions, with any C-style callback API that is designed to work only with C function pointers. In a multi-thread environment signals can be emitted asynchronously and scheduled for synchronous execution when requested in other threads. There have been numerous improvements since the first review, including the the ability to create persistent connections which don't require the user to explicitly keep them alive. See https://zajo.github.io/boost-synapse/. Thanks, Emil

2 1

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

numeric directory/namespace
by Robert Ramey 14 Aug '18

14 Aug '18

I'm preparing to make adjustments to safe_numerics directory and namespace in preparation to incorporating safe_numerics into the official boost distributions. I have a couple of decisions to make that someone/everyone will want to weigh in on. There is already a directory boost_root/libs/numeric which seems to be an "umbrella" for libraries dealing with numerics. It includes conversion, interval, odeint and ublas. There is an index.html in there also. But instead of referring to the above libraries, it points to the ublas documentation. So it's sort of tempting the place safe numerics in libs as a sub directory. But I really have strong reservations about the whole concept of have this "umbrella" directory in the first place. Personally I'd just prefer to use boost_root/libs/safe_numerics. I don't think the extra structure adds anything and makes it harder to implement tools which scan the directories. It would also mean that I should ? use #include <boost/numeric/safe_numeric/ ....> and I'm not sure want to do that. Also I expect I'll want to sync the namespace boost::numeric::safe_numeric:: ... with the file system. It just seems more complex and flexible than it has to be. I see the future of boost as diminishing coupling between libraries and I see the current setup as not helping with this. Please don't wait to answer until I've made the changes. Robert Ramey

3 2

[container] [flat_map] Error with heterogeneous comparator and std::string_view
by Viktor Sehr 13 Aug '18

13 Aug '18

On MSVC (latest) the following code yields a compile error with flat_map, but not with std::map. I do not have the knowledge of std::less<> to resolve what causes the error. auto fm = boost::container::flat_map<std::string, int, std::less<> >{}; auto m = std::map<std::string, int, std::less<> >{}; auto k = std::string_view{ "my_key" }; auto x = m.find(k); // Compiles auto y = fm.find(k); // Does NOT compile Error message: 1>boost\container\flat_map.hpp(1314): error C2664: 'boost::container::vec_iterator<boost::container::dtl::pair<Key,T> *,true> boost::container::dtl::flat_tree<boost::container::dtl::pair<Key,T>,boost::container::dtl::select1st<Key>,Compare,boost::container::new_allocator<T2>>::find(const std::basic_string<char,std::char_traits<char>,std::allocator<char>> &) const': cannot convert argument 1 from 'const std::string_view' to 'const std::basic_string<char,std::char_traits<char>,std::allocator<char>> &' 1> with 1> [ 1> Key=std::string, 1> T=int, 1> Compare=std::less<void>, 1> T2=boost::container::dtl::pair<std::string,int> 1> ] 1> boost\container\flat_map.hpp(1314): note: Reason: cannot convert from 'const std::string_view' to 'const std::basic_string<char,std::char_traits<char>,std::allocator<char>>' 1> boost\container\flat_map.hpp(1314): note: No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called Best regards /Viktor

4 7

Library Federation
by Robert Ramey 12 Aug '18

12 Aug '18

I'm now taking steps to get safe numerics integrated into the boost distribution. It's reminded me of a running complaint I have about using boost. a) When I use anything boost, I'm required to do two things: i) run b2 headers to create a forwarding header in the boost directory ii) include via command line or INCLUDE variable to boost root. b) If I want to use safe_numerics before it is included in the boost distribution, I have to place safe_numerics into it's expected destination in the boost hierarchy and run b2 headers AGAIN to make things match up. This is even more problematic in that b2 headers is not invoked "automagically" in such a way that people don't know it's there. To me, this just makes it harder to use / test any new library with boost without dragging in access to a bunch of stuff I may not want. It inhibits those without beam foo from running the tests etc. This is why I did things the way I did. Now I'm getting ready to add it to the boost distribution, I'll change this to do it the "boost way". Not so much because I think it's better but in this case, consistency is better than variety. But I'm still unsatisfied with the situation. It's part of the reason that boost is avoided when possible by many people. Isn't there a better way? I think there might be. Rather than sprinkling a bunch of forwarding headers around my file system - which are "sticky" and need to be updated from time to time, how about depending on the "INCLUDE" environmental variables available in gcc and msvc and clang. Using "some method", I would be able generate this variable via some sort of batch script - not too tough. And work as I do now. But a) the script would be re-run when ever I changed projects so that it "stuck" in my file system. b) It could be smarter - include only the boost include directories I'm actually using - thus avoiding accidently including surprising stuff. c) We have tools which figure out boost dependencies automatically so I don't think it would be a big stretch to do this automagically. d) If my project is "larger" and includes a bunch of stuff from other libraries, I could add these in as well. This would give my the concept of "library federation" where my app is linked to some list defined as part of the project. I'm sure this concept also sort of exists. e) my pet request would be that I could say: tool application.cpp ... >include environment output to generate the env output for all the target apps. Of course one could you * wild cards as well. This would let me create one set on includes for building/running my test suite and a different one for examples and a different one for my "real" application. I'll stop there so as to leave opportunity for discussion. Robert Ramey

3 7

Please merge into boostorg superproject
by James E. King III 11 Aug '18

11 Aug '18

Please merge into boost superproject - these have passed CI and have been reviewed: https://github.com/boostorg/boost/pull/186 https://github.com/boostorg/boost/pull/181 Please decide what to do with: https://github.com/boostorg/boost/pull/39 (I can't tell if this is defunct?) https://github.com/boostorg/boost/pull/184 (do we want this in the superproject, or a submodule called boostorg/docker, or not at all?) Thanks, Jim

1 0

iostreams in 1.68.0
by James E. King III 11 Aug '18

11 Aug '18

Hi folks, just a note that none of the changes since 1.67.0 got into 1.68.0 master. They were on develop and never merged. I just merged them for 1.69.0. - Jim

1 0

[release] 1.69.0 open for merging
by Marshall Clow 10 Aug '18

10 Aug '18

The master branch is open for merging all stable changes from develop, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging does not require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: https://github.com/boostorg/boost/wiki/Release-Schedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Boost Release Team

2 1

[release] Boost 1.68.0
by Marshall Clow 09 Aug '18

09 Aug '18

Release 1.68.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 1 new libraryand numerous enhancements and bug fixes for existing libraries. For details, including download links, see <https://www.boost.org/users/news/version_1.68.0> You can also download directly from: <https://dl.bintray.com/boostorg/release/1.68.0/> To install this release on your system, see <https://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team

5 5

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

Note: the Master branch is not yet open for merging
by Marshall Clow 09 Aug '18

09 Aug '18

Even though we have a release, I've got some tagging to do, etc. The master branch will be open tomorrow. -- Marshall

1 0

[release] Boost 1.68.0 Release Candidate 1
by Marshall Clow 05 Aug '18

05 Aug '18

The release candidates for the 1.68.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.68.0/source/> The SHA256 checksums are as follows: 59804d8fad02cf3b09485f3dbc0f9097c05fc1e0123f0c133b35a6c6f601109a boost_1_68_0_rc1.7z 7f6130bc3cf65f56a618888ce9d5ea704fa10b462be126ad053e80e553d6d8b7 boost_1_68_0_rc1.tar.bz2 da3411ea45622579d419bfda66f45cd0f8c32a181d84adfa936f5688388995cf boost_1_68_0_rc1.tar.gz 3b1db0b67079266c40b98329d85916e910bbadfc3db3e860c049056788d4d5cd boost_1_68_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. The web site will be updated today as well.

6 8

[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

Moving wiki/Guidelines/WarningsGuidelines
by Mateusz Loskot 02 Aug '18

02 Aug '18

Hi, Paul Bristow suggested [1] "We might also re-host this document somewhere on github/boostorg?" [1] https://lists.boost.org/Archives/boost/2018/07/242617.php I'd like to edit and move the wiki page away from Trac. IMHO, it is reasonable to host it not on GitHub wiki but on boost.org along other guidelines, for example, at https://www.boost.org/development/warnings.html - It is easy to update website via pull requests. - Any updates would be a subject of some review at least Thoughts? Objections? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

3 7

[release] 1.68.0 closed for release
by Marshall Clow 02 Aug '18

02 Aug '18

The master branch is now closed for all changes except by permission. The commit-bot isn't running on master, so the super project will need to be manually updated for any changes. If all goes well, the release candidate should be out tomorrow. Thanks, -- The Boost Release Team

1 0

[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 28 Jul '18

28 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