- Boost - lists.boost.org

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