- Boost - lists.preview.boost.org

[Library idea] Type-safe Flagsets
by Julien Vernay 27 Jun '18

27 Jun '18

Hello everybody, I want to know if some people are interested in a type-safe flagsets. I define flagsets as a container similar to a bitset, but where each bit has a meaning. For example, we could have in some game : enum Direction : unsigned { UP = 0b0001, DOWN = 0b0010, LEFT = 0b0100, RIGHT = 0b1000 }; ... unsigned player_dir = UP | RIGHT; if ((player_dir & (UP|LEFT)) == (UP|LEFT)) player.setAnim("up_left"); player_dir &= ~UP; //removing UP from player_dir I think there are some issues with this kind of flagset : - you need to think about power-of-twos when attributing values to your flags. - you need to use bitwise operations which can be non-trivial, even for removing only one flag. - it is not safe: for example with another flagset using the flag INIT_VIDEO (in a window library like SDL), you can do " UP | INIT_VIDEO " even if the two flagsets have nothing in common With a type-safe flagset library, this code would become : namespace Direction { struct UP; struct DOWN; struct LEFT; struct RIGHT; using Type = flagset<unsigned, UP, DOWN, LEFT, RIGHT>; //unsigned is the underlying type }; ... auto player_dir = Direction::Type::Value<Direction::UP, Direction::RIGHT>(); if (player_dir.allOf<Direction::UP,Direction::LEFT>()) player.setAnim("up_left"); player_dir.reset<Direction::UP>(); It is more verbose but also more safe and easy to use. I actually have a partial implementation on GitHub, supporting read, write and conversions to strings : https://github.com/J-Vernay/flagset I would like to know if some people are interested in this kind of library, and if yes, what they think about the current syntax/implementation. Thanks for reading !

3 8

Re: [boost] On Boost's logo copyright
by Mateusz Loskot 25 Jun '18

25 Jun '18

(CC to boost(a)lists.boost.org) On 25 June 2018 at 22:03, Giovanni Mascellani <gio(a)debian.org> wrote: > Il 25/06/2018 14:33, Mateusz Loskot via Boost ha scritto: >> AFAICT, the logo design was established around Boost 1.33. >> Here is related note from the release notes [1] >> >> ``` >> Rene Rivera for the new Boost web page design; and Zoltan >> "cad" Juhasz for the new Boost logo. >> ``` > > This is very useful, thank you! You're welcome. I hope I've pulled the actual facts. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

On Boost's logo copyright
by Giovanni Mascellani 25 Jun '18

25 Jun '18

Dear Boost developers, I am preparing the next upload of Boost package in Debian. I would appreciate your help on a little detail, which is however very important for Debian (if this is not the right place to ask, please accept my apologies and direct me to a more appropriate one): who is the copyright holder of Boost's logo? I understand that it is licensed under the BSL license, but it seems to me that the name of the rights holder is not listed anywhere. Thanks for your help and for the great library, Giovanni. -- Giovanni Mascellani <g.mascellani(a)gmail.com> Postdoc researcher - Université Libre de Bruxelles

2 1

[release][yap] Master archive builds broken.. for a long time.
by Rene Rivera 24 Jun '18

24 Jun '18

While checking to see that the master PRs I did yesterday to master where not causing problems I noticed something unrelated. Looks like the master archive build has been failing for a long time now. Seems the addition of YAP is broken. It appears there's some documentation files missing: /home/ubuntu/build/boost/bin.v2/doc/gcc-4.8/debug/auto-index-on/threadapi-pthread/src/boost.auto_index.docbook:65535: element include: XInclude error : could not load /home/ubuntu/build/boost/bin.v2/doc/gcc-4.8/debug/auto-index-on/threadapi-pthread/home/ubuntu/boost/libs/yap/doc/yap_reference.xml, and no fallback was found >From any of the builds in < https://circleci.com/gh/boostorg/boost/tree/master>. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

2 4

[math] policy<discrete_quantile<real> > test's fail because multiple matches for 'real'
by Brian Kuhl 24 Jun '18

24 Jun '18

When I compile with VxWorks 7/Clang v5/ Dinkum 700 there is an inline real() function in global scope. Leading to a few errors like this: ----------------------------------------------------------------------- clang-vxworks.compile.c++ ../bin.v2/libs/math/test/test_poisson_float.test/clang-vxworks-4.2.1/debug/cross-compile-vxworks/static-only-on/test_poisson.o "/yow-build40-lx1/bkuhl/vx7/compilers/llvm-5.0.0.3/LINUX386/bin/clang" -x c++ --target=x86_64 -m64 -mcmodel=large -fno-omit-frame-pointer -fno-strict-aliasing -mno-implicit-float -fno-builtin -nostdlibinc -nostdinc++ -fno-use-init-array -ftls-model=local-exec -ansi -std=c++14 -O2 -Wall -Wno-missing-braces -Wreturn-type -Wconversion -Wformat -Wno-sign-conversion -Wno-c++11-narrowing -isystem/yow-build40-lx1/bkuhl/workspace/VSB/usr/h -isystem/yow-build40-lx1/bkuhl/workspace/VSB/usr/h/system -isystem/yow-build40-lx1/bkuhl/workspace/VSB/usr/h/public -O0 -fno-inline -Wall -g -include/yow-build40-lx1/bkuhl/workspace/VSB/3pp/BOOST/boost_1_67_0/autoconf_vsbConfig_quote.h -D_C99 -D_HAS_C9X -D__vxworks -D__VXWORKS__ -D__RTP__ -D__ELF__ -D__WRS_NO_DIRECT_TLS_ACCESS_FROM_RTP_TO_SHARED_LIB -I/yow-build40-lx1/bkuhl/workspace/VSB/3pp/BOOST/boost_1_67_0 @/yow-build40-lx1/bkuhl/workspace/VSB/mk/_vsbuinc_cmdllvmBOOST -D_VX_CPU=_VX_SIMLINUX -D_VX_TOOL_FAMILY=llvm -D_VX_TOOL=llvm -D_nq_VSB_CONFIG_FILE=/yow-build40-lx1/bkuhl/workspace/VSB/h/config/vsbConfig.h -I/yow-build40-lx1/bkuhl/workspace/VSB/share/h -isystem/yow-build40-lx1/bkuhl/workspace/VSB/usr/h -isystem/yow-build40-lx1/bkuhl/workspace/VSB/usr/h/system -isystem/yow-build40-lx1/bkuhl/workspace/VSB/usr/h/public -D_VSB_PUBLIC_HDR_DIR=/yow-build40-lx1/bkuhl/workspace/VSB/usr/h/public -I. -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_STATIC_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_TEST_NO_AUTO_LINK=1 -DBOOST_TIMER_STATIC_LINK=1 -DBOOST_UBLAS_UNSUPPORTED_COMPILER=0 -DTEST_FLOAT -I".." -I"../libs/math/include_private" -I"../libs/math/test" -c -o "../bin.v2/libs/math/test/test_poisson_float.test/clang-vxworks-4.2.1/debug/cross-compile-vxworks/static-only-on/test_poisson.o" "../libs/math/test/test_poisson.cpp" ../libs/math/test/test_poisson.cpp:454:39: error: reference to 'real' is ambiguous typedef policy<discrete_quantile<real> > P1; ^ /yow-build40-lx1/bkuhl/workspace/VSB/usr/h/public/complex.h:689:21: note: candidate found by name lookup is 'real' inline long double real(_Lcomplex _Left) ^ /yow-build40-lx1/bkuhl/workspace/VSB/usr/h/public/complex.h:543:14: note: candidate found by name lookup is 'real' inline float real(_Fcomplex _Left) ^ /yow-build40-lx1/bkuhl/workspace/VSB/usr/h/public/complex.h:397:15: note: candidate found by name lookup is 'real' inline double real(_Dcomplex _Left) ^ /yow-build40-lx1/bkuhl/workspace/VSB/3pp/BOOST/boost_1_67_0/boost/math/policies/policy.hpp:225:4: note: candidate found by name lookup is 'boost::math::policies::discrete_quantile_policy_type::real' real, ^ ../libs/math/test/test_poisson.cpp:454:39: error: unknown type name 'real' typedef policy<discrete_quantile<real> > P1; ^ ../libs/math/test/test_poisson.cpp:454:45: error: expected a type typedef policy<discrete_quantile<real> > P1; ^ 3 errors generated. ...failed clang-vxworks.compile.c++ ../bin.v2/libs/math/test/test_poisson_float.test/clang-vxworks-4.2.1/debug/cross-compile-vxworks/static-only-on/test_poisson.o... -------------------------------------------------------- I'd like to contribute a pull request to resolve this. But I'd like some guidance; is a simple change that qualifies real acceptable. using namespace boost::math::policies; - typedef policy<discrete_quantile<real> > P1; + typedef policy<discrete_quantile<boost::math::policies::real> > P1; typedef policy<discrete_quantile<integer_round_down> > P2; Or is this something that should be added with #ifdef __VXWORKS__

2 1

Re: [boost] Boost.Signals deprecation and removal
by Mike 22 Jun '18

22 Jun '18

> Isn't deprecation the warning? That depends on what deprecation means. Currently the warning message just says: > [1]Boost.Signals is no longer being maintained and is now deprecated. [...] No mention of removal. The documentation even says > If you have existing [2]Boost.Signals-based code, it **will continue to work**, but consider moving to Boost.Signals2.Â Best Mike References 1. http://Boost.Signals/ 2. http://Boost.Signals/

6 6

[release] 1.68.0 closing for major changes next week
by Marshall Clow 21 Jun '18

21 Jun '18

One week from tomorrow master will closed for major changes. Upcoming dates: * 27-Jun: Boost 1.68.0 closed for major code changes * 4-Jul: Boost 1.68.0 closed for beta * 11-Jul: Boost 1.68.0 beta 1 * 1-Aug: Boost 1.68.0 closed for release * 4-Aug: Boost 1.68.0 release -- The Boost Release Team

2 1

[Build] Create test with shared library linked against current Boost link-variant
by Alexander Grund 18 Jun '18

18 Jun '18

Hi, I discovered a severe bug in Boost.Serialization and am trying to contribute a test to the test suite to reproduce that behavior. I have a minimum example which runs into this (see also https://stackoverflow.com/questions/50064617/order-of-destruction-for-stati…) but I'm having trouble getting that into the Jamfile. What I need: 2 shared libraries linked against the currently tested Boost link-variant and link those into an executable not linked against Boost. So testcase a) would be against Boost-Shared and b) against Boost-Static. But in all cases the libraries itself must be shared. What I have: lib multi_shared_1 : multi_shared1.cpp ../build//boost_serialization : <link>shared ; lib multi_shared_2 : multi_shared2.cpp ../build//boost_serialization : <link>shared ; ... [ test-bsl-run test_multi_shared_lib : : multi_shared_1 multi_shared_2 ] Problem: This links against Boost-Shared even with "./b2 link=static" My best approach so far is to change "../build//boost_serialization" to "../build//boost_serialization/<link>static" but then I cannot test testcase a) (Boost-Shared) anymore. Also it does link other Boost-Libraries (filesystem, system) shared, not static. Furthermore I'd need to add `-fPIC` to the cxxflags of the boost libraries. This is minor as it can be done in the `.travis` file but I'd rather have it in the Jamfile so it is not missed in other test-environments. How can I achieve this? I'm not to familiar with the Jamfiles so this is basically all I could find so far. Thanks, Alexander Grund

1 1

[container] [flat_map] Sub-optimal behavior when utilized with std::less<>
by Viktor Sehr 16 Jun '18

16 Jun '18

It seems to me that neither boost::flat_map nor boost:flat_set with a custom comparator such as std::less<> behaves like std::set/std::map. This results in unnecessary allocation, in difference from std::map/set when used with a std::string as key for example Example: // Please note that I pretend that "dummy" is large enough to make the std::string utilize the heap. auto set = std::set<std::string, std::less<> >{}; auto n = set.count("dummy"); // No conversion from const char* to std::string auto flatset = boost::container::flat_set<std::string, std::less<> >{}; auto n = flatset.count("dummy"); // const char* is converted to a std::string before comparison, thus resulting in an unnecessary allocation. Is this a known issue intended to be resolved? Looking at the code of STL (which ever version ships with Visual Studio), find, count etc has been extended with template key types in addition to the regular key_type using an "is_transparent" trait: template<class _Other, class _Mycomp = key_compare, class = typename _Mycomp::is_transparent> size_type count(const _Other& _Keyval) const { _Keyval _Paircc _Ans = equal_range(_Keyval); return (_STD distance(_Ans.first, _Ans.second)); } Best regards /Viktor Sehr

4 4

Interest in (parts of) type_safe, e.g. Boost.StrongTypedef?
by Jonathan Müller 15 Jun '18

15 Jun '18

I've been working on https://github.com/foonathan/type_safe for the past 20 months or so. What started as an experimenting ground for type safe programming facilities quickly turned into a general mix bag of utilities. However, it became my most popular project, so there is something in there people find really useful. And with that multiple approached me wanting to have it added to Boost, so here I am. I do realize that not all of it is suited for Boost: some of it has overlap with existing libraries (e.g. optional/variant), some of it has better implementations elsewhere (e.g. improved integer types) and some of it is to novel/experimental (e.g. stuff like constrained_type). But there are some things that could be useful for Boost. I'm mainly thinking of the strong typedef facility. I plan on splitting the library up into multiple parts anyway (see also https://github.com/foonathan/type_safe/issues/82) so please let me know whether there is anything you'd like to see being prepared for Boost. Thanks, Jonathan

3 2

[rational] release (optimized) builds are failing unit tests
by James E. King, III 12 Jun '18

12 Jun '18

I am adding CI to Boost.Rational and the unit tests are failing for different levels of optimization on different compilers. Before I dig into it further, does anybody have any idea what this might be? https://github.com/boostorg/rational/issues/18 See issue for error output. Ubuntu Bionic gcc unit test succeeds: -O0, -O1 unit test fails: -O2, -O3 boost@17b66a9efac4:/boost/libs/rational/test$ g++ --version g++ (Ubuntu 7.3.0-16ubuntu3) 7.3.0clang unit test succeeds: -O0 unit test fails: -O1, -O2, -O3 boost@17b66a9efac4:/boost/libs/rational/test$ clang++-6.0 --version clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin To reproduce, try: boost@17b66a9efac4:/boost/libs/rational/test$ ../../../b2 toolset=clang variant=release rational_test I am using the ubuntu bionic docker container to do the build in. See boostorg/boost#184 <https://github.com/boostorg/boost/pull/184>

1 0

[release] 1.68.0 deadline for new libraries approaching
by Marshall Clow 12 Jun '18

12 Jun '18

One week from tomorrow master will closed for new libraries. Upcoming dates: * 20-Jun: Boost 1.68.0 closed for new libraries and breaking changes * 27-Jun: Boost 1.68.0 closed for major code changes * 4-Jul: Boost 1.68.0 closed for beta * 11-Jul: Boost 1.68.0 beta 1 * 1-Aug: Boost 1.68.0 closed for release * 4-Aug: Boost 1.68.0 release -- The Boost Release Team

1 0

meta/libraries.json question
by Antony Polukhin 11 Jun '18

11 Jun '18

Hello, I see that I can specify "std": [ "proposal" ], in meta/libraries.json. What are the other options? Can I write "с++17" instead of "proposal" (for Any and Variant)? -- Best regards, Antony Polukhin

1 0

boost::winapi and Windows CE 7 and Windows Mobile 6
by Vyacheslav Lanovets 07 Jun '18

07 Jun '18

Hello, I am having big trouble migrating from 1.65.1 to 1.67 in VS2008 for CE platform. We already have quite a few patches for boost we reapply on every update. Boost 1.67 added more issues here and there, and among them the winapi library. On our old CE 7.00 I have winnt.h file where the second branch get selected. #if (defined(_M_MRX000) || defined(_M_IX86) || defined(_M_ALPHA) || defined(_M_PPC) || defined(_M_IA64)) && !defined(MIDL_PASS) #define DECLSPEC_IMPORT __declspec(dllimport) #else #define DECLSPEC_IMPORT #endif Therefore, WINAPI functions are not imported but is linked via corelib.lib library. So when I compile my code I see 3>D:\Dev\boost167\boost/winapi/semaphore.hpp(48) : error C2375: 'CreateSemaphoreW' : redefinition; different linkage 3> C:\Program Files (x86)\Windows CE Tools\SDKs\DS-200i\include\ARMv4I\winbase.h(3189) : see declaration of 'CreateSemaphoreW' To make things worse in Windows Mobile 6 SDK half of API is imported and half is not (goes through corelib.lib). Visual Studio 2008 installer includes WM6 SDK. And in the file C:\Program Files (x86)\Windows Mobile 6 SDK\PocketPC\include\ARMV4I\winbase.h there are functions not prefixed with WINBASEAPI. The solution would be to have 2 new defines instead of BOOST_SYMBOL_IMPORT in boost::winapi. On CE 7 both would be empty, on WM 6 one would be __declspec(dllimport) Regards, Vyacheslav

4 3

Yap formally accepted into Boost
by Louis Dionne 04 Jun '18

04 Jun '18

Dear Boost, This message is to announce that Yap (which had been conditionally accepted [1]) is now accepted into Boost, since the conditions for acceptance have been met. The conditions for acceptance were: - Improve the documentation to satisfy Brook Milligan and myself (done) - A single macro for symmetric binary operators (done in https://github.com/tzlaine/yap/issues/22) - Get rid of external dependencies checked into repository (done) - Boost.Build (done in https://github.com/tzlaine/yap/issues/52) Congratulations Zach! Louis Dionne Review manager for Boost.Yap [1]: https://lists.boost.org/boost-announce/2018/03/0540.php

2 1

Re: [boost] [Algorithm] contains(v, 1)
by Jean-Philippe DUFRAIGNE 04 Jun '18

04 Jun '18

On 5/31/18 3:14 AM, Olaf van der Spek via Boost wrote: > Hi, > > vector<int> v; > contains(v, 1); > > This doesn't work as contains expects two ranges (AFAIK). > Is there some other function that's usable for this purpose? > Should contains support a value for argument 2? > > Gr, > Hi, This algorithm exists: boost::any_of_equal https://www.boost.org/doc/libs/1_67_0/libs/algorithm/doc/html/the_boost_alg… Thanks; Jean-Philippe

2 1

[outcome] v2.1 progress report
by Niall Douglas 04 Jun '18

04 Jun '18

Dear Boost, Two months after you accepted Outcome into Boost, I am pleased to say that I believe that all the known bugs and very substantial source refactoring recommended by the peer review have been implemented (detailed changelog is appended below). What remains is a few months of maturing in real world use as all this severe refactoring needs to be tested outside a test suite, and of course the documentation which I don't intend to start work on until the autumn. The Boost edition has, obviously, received a major upgrade and it is now 100% "Boost native" in that it uses Boost.System and Boost.Exception now. The test suite for the Boost edition exclusively tests the Boost native edition, and it all passes. Outcome (both standalone and Boost editions) now can handle both Boost and std types freely intermixed as you see fit. A new "lite" single header edition exists which drags in virtually no system headers, and is hideously low impact on compile times as a result. ABI and API stability have been dumped to git repo with scripting to check the current library against the frozen dumps. This edition should make the corporate crowd very pleased. Very little should appear to have changed from the outside. Code written for v2.0 ought to, more or less, compile and work as before with v2.1. I would appreciate whatever help the Boost community can give in helping to test this edition. I expect new bugs to have been introduced given the severe source code refactoring, and new dual support for Boost and std as equals. My gratitude in advance. Niall --- ## v2.1 in progress [[project]](https://github.com/ned14/outcome/projects/1) - Boost edition is now 100% Boost, so defaults for `result` and `outcome` are `boost::system::error_code::errc_t` and `boost::exception_ptr`. Moreover, the test suite in the Boost edition now exclusively tests the Boost edition. One can, of course, freely use the standalone edition with Boost, and the Boost edition with `std` types. - Renamed ADL discovered customisation point `throw_as_system_error_with_payload()` to `outcome_throw_as_system_error_with_payload()`. - [#135](https://github.com/ned14/outcome/issues/135) - Added much clearer compile failure when user tries `result<T, T>` or `outcome` where two or more types are identical. Thanks to Andrzej Krzemieński for suggesting a technique which combines SFINAE correctness with the remaining ability for `result<T, T>` etc to be a valid type, but not constructible. - [#67](https://github.com/ned14/outcome/issues/67) - Fixed one of the oldest long open bugs in Outcome, that the noexcept unit tests failed on OS X for an unknown reason. - [#115](https://github.com/ned14/outcome/issues/115) - Outcome did not construct correctly from `failure_type`. - Inexplicably outcome's error + exception constructor had been removed. Nobody noticed during the Boost peer review, which is worrying seeing as that constructor is needed for one of the main advertised features to Boost! - [#107](https://github.com/ned14/outcome/issues/107) and [#116](https://github.com/ned14/outcome/issues/116) - `operator==` and `operator!=` now become disabled if the value, error and exception types do not implement the same operator. - Relatedly, both comparison operators simply didn't work right. Fixed. - [#109](https://github.com/ned14/outcome/issues/109) - `swap()` now has correct `noexcept` calculation and now correctly orders the swaps to be whichever is the throwing swap first. - Added reference dump of v2.1 ABI so we can check if ABI breakage detection works in the next set of changes, plus Travis job to check ABI and API compatibility per commit. - [#124](https://github.com/ned14/outcome/issues/124) - `OUTCOME_TRY` is now overloaded and selects `void` or `auto` edition according to input parameter count. - [#120](https://github.com/ned14/outcome/issues/120) - Fix generation of double underscored temporary variables in `OUTCOME_UNIQUE_NAME`, which is UB. - [#110](https://github.com/ned14/outcome/issues/110) - Separated `result` from its hard coded dependency on the `<system_error>` header. - Renamed `result` and `outcome` to `basic_result` and `basic_outcome`. - Renamed `result.hpp` into `basic_result.hpp`. - Moved `<system_error>` and `<exception>` dependent code into new `std_result.hpp` and `std_outcome.hpp` header files. - Added `boost_result.hpp` and `boost_outcome.hpp` which use Boost.System and Boost.Exception (these are `result.hpp` and `outcome.hpp` in the Boost edition). -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 1

[beast] How do I select un-DEPRECATED interfaces?
by Brian Kuhl 04 Jun '18

04 Jun '18

Hi Experts, I’m working with an EAR release of VxWorks 7 with llvm v5.0 and VxWorks’ first C++14 STL ( Dinkum v700) and Boost v 1.67 ( Yes, the RTOS world moves slowly) I’ve gotten a clean compile of Beast with #define BOOST_BEAST_ALLOW_DEPRECATED #define BOOST_COROUTINES_NO_DEPRECATION_WARNING But I’m having trouble locating the logic that’s choosing these deprecated interfaces for me? Could someone point out the relevant logic? Many Thanks, Brian Kuhl Senior Manager – Information Development Wind River

2 1

[Algorithm] contains(v, 1)
by Olaf van der Spek 03 Jun '18

03 Jun '18

Hi, vector<int> v; contains(v, 1); This doesn't work as contains expects two ranges (AFAIK). Is there some other function that's usable for this purpose? Should contains support a value for argument 2? Gr, -- Olaf

5 13

[compressed_pair] [hof] [hana] What's the story with compressed_pair?
by Tom Westerhout 30 May '18

30 May '18

Hello! It looks like there are at least three different implementations of a "std::pair with EBO" in Boost: boost/utility/compressed_pair.hpp boost/hof/detail/compressed_pair.hpp boost/hana/pair.hpp Finally, there is also std::tuple which seems to also make use of EBO. I need similar functionality for a GSoC project I'm working on this year. So I'm wondering, is compressed pair considered a simple technicality that should be implemented from scratch every time I need it or shall I stick to one of the four mentioned implementations? I would much prefer to use Boost.Utility's one, but unfortunately it's neither constexpr-friendly nor noexcept-friendly... Is there some reason why it cannot be annotated with macros which expand to constexpr and noexcept when compiled with C++11 support? Or has no one just gotten around to do it? Thanks in advance, Tom

3 3

[Hana] "basic_tuple.hpp" bug when building with VS2017
by Louis Dionne 30 May '18

30 May '18

> Hello, > > Just installed Boost and Visual Studio 2017 a few days ago. Visual Studio 2017 is known to be unable to compile Hana (and other libraries such as Range-v3). I will be working with the Microsoft folks to make it work as they explicitly reached out to me with that intent. Cheers, Louis

4 9

[testing][regressions] All my regressions testers failing due to connection errors to GitHub
by Ion Gaztañaga 28 May '18

28 May '18

Hi, All my 4 testers (I have 4 machines running several Mingw targets) are always failing pulling new versions from GitHub. This problem started some days ago. I've tried to reset all machines, network equipment, disabling antivirus, firewall, modified http attributes, modified the regression script to use git protocol instead of https, etc. with no luck. I'm using Windows machines with official Git. Any clue on what's going on? Maybe Github recently does not like so many submodules? Example of failure (several libraries can fail during "git pull "--recurse-submodules""): ------------------- ------------------- ------------------- Fetching submodule libs/io fatal: unable to access 'https://github.com/boostorg/io.git/': OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 10054 Then: # git_source_checkout failed with message "GIT command "git pull "--recurse-submodules"" failed with code 1" # Retrying (5 more attempts). # Executing GIT command: c:\boost\develop\boost_root> git submodule foreach "git submodule deinit ." ------------------- ------------------- All retries fail and the script fails with error: ------------------- ------------------- ------------------- # git_source_checkout failed with message "GIT command "git pull "--recurse-submodules"" failed with code 1" # Giving up. Traceback (most recent call last): File "run.py", line 71, in <module> runner(root) File "c:\boost\develop\boost_regression_src\regression.py", line 286, in __init__ self.main() File "c:\boost\develop\boost_regression_src\regression.py", line 623, in main getattr(self,action_m)() File "c:\boost\develop\boost_regression_src\regression.py", line 578, in command_regression self.command_get_source() File "c:\boost\develop\boost_regression_src\regression.py", line 330, in command_get_source self.retry(self.git_source_checkout) File "c:\boost\develop\boost_regression_src\regression.py", line 662, in retry return f() File "c:\boost\develop\boost_regression_src\regression.py", line 875, in git_source_checkout self.git_checkout(git_info['boost'], self.git_branch(), clean) File "c:\boost\develop\boost_regression_src\regression.py", line 849, in git_checkout self.git_command( 'pull', '--recurse-submodules' ) File "c:\boost\develop\boost_regression_src\regression.py", line 834, in git_command raise Exception( 'GIT command "%s" failed with code %d' % (git_cli, rc) ) Exception: GIT command "git pull "--recurse-submodules"" failed with code 1 END 24/05/2018 15:28:37,46 ------------------- ------------------- ------------------- Errors are never in the same libraries, very few times the checkout succeeds and a regression is run. Anyone else having these problems? I've attached the log of one failure in case someone can see any clue. I really don't see how to solve this, so I won't be able to run regressions. Best, Ion

3 4

GCC versions
by Ian Emmons 28 May '18

28 May '18

Apologies if this is off topic, but the audience here is perfect for this question: I need to support CentOS version 7 with my C++ software. The version of GCC that is supported out-of-the-box on that version of Linux is rather old -- it supports C++11, but not C++14, and of course I would like to use a newer standard. Is it common practice on Linux to install a later version of GCC than the out-of-the-box on version? If so, how do you handle the run-time shared library dependencies? Any pointers would be helpful. Thanks, Ian

3 2

Boost multiprecision differential fuzzer running on Google's oss-fuzz
by Guido Vranken 28 May '18

28 May '18

Dear list, I built a bignum differential fuzzer [1] that has been running on Google's oss-fuzz service [2] for a while. It performs the same mathematical operations (addition, subtraction, multiplication, modular exponentation, etc) across multiple bignum libraries (eg. OpenSSL + Boost multiprecision), compares their results and crashes if they don't match. This effort has so far found a couple of (minor) bugs in OpenSSL and Go. As soon as a mismatch is found, oss-fuzz will send a notification e-mail to the developers of the various bignum libraries so the bug can be examined and resolved. At which e-mail address(es) do the developers of Boost wish to receive these notifications? Please bear in mind that the notifications will contain potentially security-sensitive information so the recipient may not be a public mailing list. Currently, a potential bug is found only every couple of weeks, so recipients do not have to worry about a lot of incoming traffic. If you wish to write comments to the fuzzer's private bug tracker, the e-mail you specify must be linked to a Google account. To all others who are reading this, please feel welcome to submit pull requests to the Boost multiprecision module of my fuzzer [3] if these modifications increase the scope (code coverage) and probability of finding bugs. Thanks, Guido [1] https://github.com/guidovranken/bignum-fuzzer [2] https://github.com/google/oss-fuzz [3] https://github.com/guidovranken/bignum-fuzzer/tree/master/modules/cpp_boost

2 1

[windows] Wni32/Vigorf.A trojan in boost_1_67_0-msvc-14.1-64.exe?
by Mateusz Loskot 28 May '18

28 May '18

Hi, One user reported via #boost at cpplang.slack.com that Windows Defender reported trojan in the latest Windows binaries. I checked myself and I can confirm the latest up-to-date Windows Defender is detecting Vigorf.A in the installer archive. Is this false report? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

5 7