August 2017 - Boost - lists.preview.boost.org

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

14 Aug '17

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

6 7

[quickbook] Requiring C++11 features in quickbook
by Daniel James 14 Aug '17

14 Aug '17

Hi, I'm thinking of using some C++11 features in quickbook, will this cause anyone any issues? Based on the support tables, I'm thinking of supporting gcc 4.4, clang 3.4, Visual Studio 2013 and later compilers. I won't use anything that doesn't have wide support (such as expression SFINAE). Please let me know if this will be a problem for you. Daniel

5 8

Boost MSM Parent does not handle event
by Denis Kotov 14 Aug '17

14 Aug '17

Hello Henry, I have faced with interested behavior. When in child *FSM* I emit event it handles only by this *FSM (not proper behaviour)* But if I emit this event from the Parent *FSM* it tries to be handled by all sub-states and then by Parent *FSM (proper behavior from my point of view)* Is it possible to send event from Child State Machine to be handled first of all in all Child states and *FSM*-s and then in Parent *FSM* ? *Thanks,* *Best RegardsDenis Kotov*

1 0

[math] Enable move semantics for polynomials
by Lakshay Garg 14 Aug '17

14 Aug '17

Hello all The polynomial class in boost.math does not support move sematics. I tried to implement them and found that they immediately lead to significant improvements in performance (benchmarking using google-benchmark). I would like to get the changes merged into the main repository. I understand that boost accepts very high quality C++ code and since this will be my first time contributing to boost I am looking forward to assistance from other experienced contributors. Could someone please advise me on how to move forward and get the changes merged. Regards Lakshay

4 8

Posts not appearing on Boost Mailman
by Raffi Enficiaud 14 Aug '17

14 Aug '17

Hi Boost, I have an issue with MailMan: I never use "emails" for posting on the Boost ML, I use news.gmane.org through thunderbird. I can see my posts on news.gmane.org, but I cannot see any of my posts here for instance: https://lists.boost.org/Archives/boost/2017/07/index.php Is this normal? Thanks, Raffi

5 8

Hello World
by Naivedya Bansal 14 Aug '17

14 Aug '17

I am a new comer and would like to become a contributor at Boost. Could you please provide me with relevant links from where to start ad I am feeling entirely lost right now. Thank you, Naivedya Bansal

2 1

CUDA V9 (release candidate) breaks compilation
by Hartmut Kaiser 12 Aug '17

12 Aug '17

All, Apparently CUDA V9 has deprecated/removed the __CUDACC_VER__ macro which is used by Boost, see https://github.com/STEllAR-GROUP/hpx/issues/2815 for details. Should this be fixed before the release? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

1 0

Switch to CMake -- Analysis
by Thomas Heller 12 Aug '17

12 Aug '17

Hi list, After there has been a heated debated over the last three days over the switch to CMake, I'd like to share my observations... First of all, a general observation: In this discussion, there generally seems to two camps: Those who know Boost.Build and those who know CMake. Unfortunately, there doesn't seem to be any overlap between those groups, which generally made the discussions about a potential switch to CMake unfruitful, often leading to misunderstandings due to a lack of knowledge about the other tool. There is no doubt, that the group of people knowing CMake is larger and that projects using CMake far outnumber the ones using Boost.Build. A thousand flies can't be wrong, right? Is the popularity of CMake really the only benefit? Here is the thing, from my point of view: Apart from the different philosophy (Build System vs. Build System generator), in the end, you get a executable/library out of the system. From a pragmatic point of view, the only thing that changes to develop/build/test/use a library is the work flow. Leaving aside the disruptive and its effects of such. Now, on to the motivation for switching, as presented in the announcement: On 7/18/2017 9:12 AM, Jon Kalb via Boost wrote: > [...] our build system has become an impediment for many developers > and users, existing and prospective. Let's look at users first. Yes, FindBoost.cmake has its problems, but it works in 90% of the cases (from my own experience). This can, and should certainly be improved. Providing the necessary XXX-config.cmake files is what fixes this. There has been movement in that direction, with code, which could be just improved upon. This will fix those cases. The other group of library consumers, expressed the urge to build boost directly as part of their build process. That hasn't been done yet, but I am pretty certain, there are no road blocks to actually write such a CMake Module, which invokes b2 instead of the compiler directly inside of the superproject. Together with the generated XXX-config.cmake files, this use case is covered. From my recollection of the various discussions, this approach was not contentious at all, it wouldn't even require interaction with all library maintainers, and all CMake users (existing or prospective) would immediately benefit. Now on to developers. There is obviously a lot of resistance from existing developers (for various reasons, which are not really relevant for the discussion at hand). In my opinion, maintaining two build systems is a no-go. Either make a clear cut, or don't. Please don't waste resources on maintaining and supporting both. With this line of thought as the background, this will create massive disruption. Switching the whole of boost (including infrastructure, documentation etc.) to be built and tested with CMake is not easy and take a lot of time, leaving a void for both maintainers and prospective boost library authors. Now, the argument that has been brought up very often in favor for the switch is that it will attract more contributors, but will it really? I am reluctant to the idea that people don't contribute new libraries to boost just because of the build system. Despite a switch to cmake, you'd still have to conform to Boost.CMake guidelines and somehow make your library buildable and testable within and outside of the Boost Tree (there might be a straight forward solution to this). Furthermore, I often hear something like "in the presence of GitHub and CMake people don't think about submitting to boost anymore". This is exactly the point. But it has nothing to do with the "and CMake" suffix. It's is just far more easier and convenient to drop you library to GitHub, advertise it on various channels and call it a day. I hear you say: "Sure, but libraries will only be adopted if they come with CMake." That might very well be true, but what has this to do with Boost? Compare the lengthy and exhausting review process you have to go through with the click of a few buttons and hammering something onto a keyboard. And no, Robert, while the incubator was a nice idea, it doesn't compensate that either ;) All in all, I am pretty confident that a disruptive switch will hurt Boost more than it brings benefit. This already happened. To come to an end and summarize: Provide proper CMake integration, such that Boost is consumable by those (while you are at it, don't forget meson, bazel and pkg-config). While your add it, improve Boost.Build, maybe it can rise again from its ashes (why did it "fail" in the first place?). Regards, Thomas

27 78

Best Practices for Surviving the Boost Test Gauntlet?
by Vinnie Falco 11 Aug '17

11 Aug '17

Beast won the first battle, but it looks like it is losing the war: <http://www.boost.org/development/tests/develop/developer/beast.html> I've never heard of many of these platforms let alone know how to go about fixing the compile, link, and runtime errors. It seems like deallocate() is not part of some standard library's allocator_traits? Link error on operator delete from Boost.System? A lot of little thing. Is there a document or resource which explains the various peculiarities and idiosyncrasies of these platforms and toolchains that I might have a means of fixing them without actually installing them locally (which is unlikely)? Thanks

6 14

boost_check_library.py: correct handling of header-only libs?
by Vinnie Falco 10 Aug '17

10 Aug '17

This script fails for me: <https://github.com/boostorg/boost/blob/master/status/boost_check_library.py…> Because there is no libs/beast/build. But Beast is header-only and has no src/ directory, is this correct? Apologies for posting to the list, but there is no Issues tab on the boostorg/boost repo. Thanks

3 2