December 2017 - Boost - lists.boost.org

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

[accumulators] No maintainer?
by Sergiu Deitsch 04 Dec '17

04 Dec '17

Boost.Accumulators does not seem to have an active maintainer anymore. My PR hast been waiting for any reaction from a maintainer for over a year now. Can someone of the Boost devs take a look at my (pretty trivial) PR at https://github.com/boostorg/accumulators/pull/5 and possibly merge it?

3 2

[hash][array][stacktrace][type_index] Adding noexcept to hash
by Daniel James 04 Dec '17

04 Dec '17

Hi, I want to add noexcept support to the hash library, but a few libraries (array, stacktrace, type_index, maybe more) forward declare hash_range for themselves, causing errors if I add a noexpect specifier to hash_range. If I move hash_fwd.hpp into the core module, so that it doesn't add a dependency on the functional module, would they be okay with including it from there? thanks, Daniel

2 4

Re: [boost] PSA: Travis OS X bottleneck, <cxxstd> new Boost.Build feature
by Robert Ramey 02 Dec '17

02 Dec '17

On 11/29/17 1:10 AM, Boris Kolpackov wrote: > In this light, I think it makes more sense to ask Boost users > who are using Boost on Mac OS to contribute hardware resources > for CI testing. This is the right idea. Let's go the full monte and take it to it's logical conclusion. a) Encourage users to run tests on the libraries they use by making testing more user friendly. b) Create a CMake or CMake-like dashboard where users can more or less automagically post their results to a common database. Presumable boost regression.py does something similar already. c) Create a program to permit display of this giant "data cube" according to the needs of the user/developer. My personal contribution to moving in this direction can be found at https://github.com/robertramey/library_status This permits me to: a) run the serialization test suite with boost build. This is a single button which builds all the libraries that the serialization depends upon, and runs all the tests. b) The results are displayed on a giant cumulative matrix which permits me to see which tests are failing on which platforms. Here is a recent copy of that matrix http://htmlpreview.github.com/?https://github.com/robertramey/library_statu… more information is available here: http://htmlpreview.github.com/?https://github.com/robertramey/library_statu… If this idea were implemented we would have: a) recent tests on all platforms actually being used regardless of how obscure. b) an easily browsable data base of test results. c) less dependency on centralized CI testing resources d) less pressure on boost testers e) more people participating and being a member of the boost community - helping to promote the "Boost Brand (c)" f) Since Appveyor, Travis, regression.py, and individual users would be posting all results to a common database, we'd be decoupling test results presentation from any particular testing platform. g) Should CMake solution every get accepted, it could easily be adjusted to post the the database as well. Boost needs this going back at least a decade. Robert Ramey

1 0