- Boost - lists.boost.org

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

[release] 1.66.0 closing for release on Wednesday
by Daniel James 02 Dec '17

02 Dec '17

There's still a little time for any remaining bug fixes, documentation updates and release notes. Schedule: 6 Dec - Closed for all changes, except by permission of a release manager 9 Dec - Closed for all changes 13 Dec - Boost 1.66.0 release You can edit the release notes here: https://github.com/boostorg/website/blob/master/feed/history/boost_1_66_0.q…

5 13

[contract] move operations and class invariants
by Lorenzo Caminiti 01 Dec '17

01 Dec '17

Hello all, This is not really a question about Boost.Contract, but more a question on how contract programming interacts with C++ move operations. C++ requires that moved-from objects can still be destructed. Because contract programming requires class invariants to hold at destructor entry, it follows that moved-from objects must still satisfy class invariants. That sounds restrictive... and it might force the class invariants to be empty. For example, for vector a class invariant is size() <= capacity(). Should that sill hold after the vector has been moved? That means I can still call size() and capacity() on a moved-from object, which might not be the case. If some sort of moved() function could be called on a moved-from object, the invariants could be programmed as follow to work around this issue: class vector { void invariant() cont { if(!moved()) BOOST_CONTRACT_ASSERT(size() <= capacity()); ... // Only invariants that are truly needed to execute the destructor. } bool moved() const; public: vector(vector&& other) { boost::contract::check c = boost::contract::constructor(this) .postcondition([&] { BOOST_CONTRACT_ASSERT(!moved()); BOOST_CONTRACT_ASSERT(other.moved()); }) ; ... } ... }; I'm not really sure... What do you think? Do you know if this topic "C++ move & class invariants" has already been discussed somewhere? Thanks. --Lorenzo

6 11

Re: [boost] [contract] move operations and class invariants
by Peter Dimov 01 Dec '17

01 Dec '17

Lorenzo Caminiti wrote: > > read() can fail, so you can drop its "valid" precondition and just fail > > when the handle is invalid. > > Calling read() on a moved-from object so violating its is_valid() > precondition is a bug, not a run-time error while reading the file. The > precondition legitimately remains in place to catch bugs, even after it is > noted that read() can fail because of file-system or other run-time > errors. On one hand, you want to have a precondition. On the other, you say that if you have the precondition, the class would be crippled and not very useful: >> 2. How useful is a class like the one above with "crippled" invariants >> and is_valid() preconditions on all its useful public methods like >> read()? The answer seems to be: not very useful. These are contradictory. Either the class that has preconditions is crippled and not very useful, in which case we drop the preconditions as I suggest; or it's useful, in which case we keep them.

1 0

[spirit] x3 status and docs?
by Andrey Semashev 29 Nov '17

29 Nov '17

Hi, I'm wondering what is the status of Boost.Spirit x3? Is it considered stable and ready for production use? If yes, how can I find its docs? There seem to be no mention of x3 in the docs on the Boost website.

3 2

[histogram] Working with standard algorithms
by Bjorn Reese 29 Nov '17

29 Nov '17

I would like to see a better integration between boost.histogram and standard algorithms, especially those from <numeric>. Today they do not work together because the dereference operator of the axis iterator returns a pair (index and content) rather than the content. An example of where standard algorithms could be useful is calculating the cumulative distribution of a one-dimensional histogram, which ought to be a simple as: auto& axis = h.axis(); std:partial_sum(axis.begin(), axis.end(), axis.begin()); Another example is ranking a set of histograms based on the cosine similarity [1] using std::inner_product(). [1] https://en.wikipedia.org/wiki/Cosine_similarity

2 4