- Boost - lists.preview.boost.org

[release] Boost 1.66.0 Beta 1 Release Candidate 1
by Daniel James 09 Dec '17

09 Dec '17

The release candidates for the 1.66.0 beta release are now available at: <https://dl.bintray.com/boostorg/beta/1.66.0.beta.1/source/> The SHA256 checksums are as follows: 0e137e61069e95f61fe0e46aa4a5432e65e209e87d470ea3c15b0ea1327583ac boost_1_66_0_b1_rc1.7z eff4854c1a672830c55fd2323ebe42d5d83e0f7a3d0a9d354d8bf55289831fa0 boost_1_66_0_b1_rc1.tar.bz2 f4fb07aa1ec639707570e42a848796d9a8155f23d1ece0f0a6a0cbee99807038 boost_1_66_0_b1_rc1.tar.gz d5f480441223f45427199697edbdd78145499084f835597247a452d2a7e1e798 boost_1_66_0_b1_rc1.zip The in progress release notes are at: <http://www.boost.org/users/history/in_progress.html> And the documentation is at: <http://www.boost.org/doc/libs/1_66_0_beta1/> 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.

11 42

[beast] Security Review: Hybrid Application Assessment
by Vinnie Falco 09 Dec '17

09 Dec '17

Since 2005, Bishop Fox has provided security consulting services to the Fortune 1000, high-tech startups, and financial institutions worldwide. The author of Beast, Vinnie Falco, engaged Bishop Fox to assess the security of the Boost C++ Beast HTTP/S networking library. The following report details the findings identified during the course of the engagement, which started on September 11, 2017. The assessment team conducted a hybrid application assessment of the Beast library. Bishop Fox’s hybrid application assessment methodology leverages the real-world attack techniques of application penetration testing in combination with targeted source code review to thoroughly identify application security vulnerabilities. These full-knowledge assessments begin with automated scans of the deployed application and source code. Next, analyses of the scan results are combined with manual review to thoroughly identify potential application security vulnerabilities. In addition, the team performs a review of the application architecture and business logic to locate any design-level issues. Finally, the team performs manual exploitation and review of these issues to validate the findings. <https://vinniefalco.github.io/BeastAssets/Beast%20-%20Hybrid%20Application%…> Note: The permessage-deflate vulnerability described in the report is confirmed to be fixed in the version of Beast which is included in Boost 1.66.0 Thanks

1 0

Requesting endorsements for YAP review
by Zach Laine 07 Dec '17

07 Dec '17

I mailed the list several months ago about YAP, an expression template library written against C++14 and later standards. The sources can be found here: https://github.com/tzlaine/yap and online docs here: https://tzlaine.github.io/yap I'd like to put this in the review queue, and so I'm looking for endorsements for this. At the time of my initial emails, there was some interest, but not much. Expression templates are a niche technology, so this makes sense. I'm trying to make ETs less expert friendly, so that they leave their experts-only niche. I feel this library does a fairly good job of that. If you do too, please endorse! Thanks, Zach

4 4

Discovering and handling missing override keyword in project conversion
by James E. King, III 06 Dec '17

06 Dec '17

I'm in the middle of converting a large project from C++03 to C++14, and of course crossing the C++11 gap, I want identify all of the places where the override keyword should be used but is not, and add it. When I turned on -Wsuggest-override in gcc-7.2 I got a fair number of warnings from boost code, for example: ...boost/program_options/value_semantic.hpp:304:14: error: â€˜bool boost::program_options::typed_value<T, charT>::is_composing() const [with T = std::basic_string<char>; charT = char]â€™ can be marked override [-Werror=suggest-override] bool is_composing() const { return m_composing; } ^~~~~~~~~~~~ ...boost/program_options/value_semantic.hpp:306:18: error: â€˜unsigned int boost::program_options::typed_value<T, charT>::min_tokens() const [with T = std::basic_string<char>; charT = char]â€™ can be marked override [-Werror=suggest-override] unsigned min_tokens() const ^~~~~~~~~~ ...boost/program_options/value_semantic.hpp:315:18: error: â€˜unsigned int boost::program_options::typed_value<T, charT>::max_tokens() const [with T = std::basic_string<char>; charT = char]â€™ can be marked override [-Werror=suggest-override] unsigned max_tokens() const { ^~~~~~~~~~ ...boost/program_options/value_semantic.hpp:325:14: error: â€˜bool boost::program_options::typed_value<T, charT>::is_required() const [with T = std::basic_string<char>; charT = char]â€™ can be marked override [-Werror=suggest-override] bool is_required() const { return m_required; } ^~~~~~~~~~~ (There were others - this is just a small sample) This is probably not the first time this has been brought up, but there is no BOOST_OVERRIDE (or BOOST_FINAL, for that matter) definition in Boost.Config that would allow Boost itself to be compatible with C++03 or C++11 cleanly relative to this language feature. I found a number of posts about this issue elsewhere. Has this issue been discussed here before? I could spend some time adding this to Boost.Config and then making boost compile cleanly with cxxstd=03,11 toolset=gcc-7 cxxflags="-Wsuggest-override", as it would help support a more complete conversion to the new language level for projects, and it would enable existing projects to turn on the warning to improve their code, as well as improve Boost. Thoughts? - Jim

1 0

[release] 1.66.0 closed for release
by Daniel James 06 Dec '17

06 Dec '17

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 this weekend. You can still modify the release notes at: <https://github.com/boostorg/website/blob/master/feed/history/boost_1_66_0.q…> Thanks, -- The Boost Release Team

1 0

Policy for breaking changes
by Louis Dionne 05 Dec '17

05 Dec '17

Hi all, So far, I've been careful about not doing any breaking changes to Hana. Hana obeys semantic versioning, and I'm accumulating desirable breaking changes until I'm ready to publish a new major version. I'm wondering what's the policy for major breaking changes with Boost libraries. For example, let's say I wanted to do an update of Hana with C++17 features; this would be a large breaking change, with all kinds of API changes, etc.. - Are such drastic changes prohibited altogether? Or perhaps they’re not prohibited but there’s historical evidence showing it’s always a bad idea? - Do such changes require going through a mini review? - Is it customary to leave the old version of the library there in a separate directory (or put the new one in a separate directory)? I think Spirit does that, e.g. Spirit Classic is still available IIRC. I think I know the answer to these questions from observing other author's behavior, but I'd like to see what the community thinks about this. It has an impact on the Boost libraries as a whole, since a major breaking change in one library could prevent users from updating Boost as a whole, which has an impact on all of us. I'm looking forward to hearing other people's thoughts on the matter. Thanks, Louis

18 30

[type_index] type names string cross-platformness
by Damien Buhl 05 Dec '17

05 Dec '17

Dear Boost, MSVC differs from GCC & Clang in the way it present the pretty_name of a type_info within Type Index. Indeed for the following type : struct why {}; Is presented as `struct why` while on GCC it is `why`. Is there any reason why pretty_name wouldn't strip / add the information from one of the compiler in order to reach a cross-plaftorm string name of types ? MSVC:http://rextester.com/QNMB58390 <http://rextester.com/QNMB58390> GCC: http://coliru.stacked-crooked.com/a/1aa52003605d4936 Would such a patch to the library be possible & welcome ? Best regards, -- Damien Buhl Software Developer +33 6 77 43 10 05

2 1

MSVC 15.5 support
by Olaf van der Spek 05 Dec '17

05 Dec '17

Hi, 15.5 Preview has been released: https://blogs.msdn.microsoft.com/vcblog/2017/10/11/productivity-structure-v… > Unknown compiler version - please run the configure tests and report the results How do I do this? Could this message be updated to indicate it comes from Boost? Gr, -- Olaf

4 7

Announcement: Faber, a new build system based on bjam
by Stefan Seefeld 05 Dec '17

05 Dec '17

Hello, about a year ago I started to experiment with a new Python frontend for Boost.Build. After many iterations of prototyping things are starting to fall into place, and the project stabilizes. I'm thus happy to announce the release of Faber version 0.2: code: https://github.com/stefanseefeld/faber docs: https://stefanseefeld.github.io/faber While Faber retains most of the features from Boost.Build, it is redesigned from the ground up. bjam is still used as scheduling engine, but everything else is written in Python. In particular, Jamfiles are replaced by fabscripts, which are essentially Python scripts. The project contains a range of examples to demonstrate various simple use-cases, from a simple "hello world" example to demos involving autoconf-style config checks, and unit testing. I have added build logic to Boost.Python to use Faber on Travis-CI as well as AppVeyor, which also is a good litmus test for Faber's capabilities. I'd be very interested in feedback as well as contributions. Perhaps it might become possible one day to integrate Faber with other efforts to add a Python frontend to Boost.Build. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...

13 48

BOOST_PRAGMA_MESSAGE?
by Peter Dimov 04 Dec '17

04 Dec '17

In what module does the following utility macro: #if defined( __GNUC__ ) #define BOOST_PRAGMA_MESSAGE_IMPL_1( x ) _Pragma( #x ) #define BOOST_PRAGMA_MESSAGE( x ) BOOST_PRAGMA_MESSAGE_IMPL_1( message( x ) ) #elif defined( _MSC_VER ) #define BOOST_PRAGMA_MESSAGE_IMPL_2( x, f, ln ) __pragma( message( f "(" #ln "): note: " x ) ) #define BOOST_PRAGMA_MESSAGE_IMPL_1( x, f, ln ) BOOST_PRAGMA_MESSAGE_IMPL_2( x, f, ln ) #define BOOST_PRAGMA_MESSAGE( x ) BOOST_PRAGMA_MESSAGE_IMPL_1( x, __FILE__, __LINE__ ) #else #define BOOST_PRAGMA_MESSAGE( x ) #endif belong? Use: BOOST_PRAGMA_MESSAGE( "something" ) MS output: .\testbed.cpp(10): note: something g++ output: testbed.cpp:10:35: note: #pragma message: something BOOST_PRAGMA_MESSAGE( "something" ) ^

3 10