- Boost - lists.preview.boost.org

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

[release][fusion] Permission to merge
by Kohei Takahashi 29 Nov '17

29 Nov '17

Hi release manager, I'd like to merge a PR, which fixes a regression on buggy compiler. https://github.com/boostorg/fusion/pull/162 Boost.regression shows the test was passed on develop. Regards, Kohei Takahashi

1 0

[Build] x32
by Olaf van der Spek 28 Nov '17

28 Nov '17

Hi, > libboost_system-vc141-mt-gd-x32-1_66.lib Why is this named x32? AFAIK the normal name is x86. -- Olaf

5 4

Re: [boost] Adding polymorphic_value to boost
by Phil Endecott 28 Nov '17

28 Nov '17

Peter Dimov wrote: > You can have > > vector<polymorphic_value<Shape>> v; > > and then > > v.push_back( Circle(10) ); > v.push_back( Ellipse(10, 15) ); > v.push_back( Square(11) ); Good example. Yes please. There's another way of implementing this, though; rather than pointing to the object in the heap you can store it in-place by allocating enough space for the largest possible derived subclass: class Base { ... }; class Derived: public Base { ... }; template <typename B> class polymorhpic_value_2 { B base; char enough_space_for_dervided_classes_members[1024]; public: template <typename D> // requires D is same as or derived from B void operator=(const D& d) { B::~B(this); new (this) D(d); } }; polymorphic_value_2<Base> p; Derived d; p = d; That's just a sketch; many details omitted! There are some obvious advantages and disadvantages of each approach and I'm definitely not saying this is better than the pointer-to-heap design. But I mention it for this reason: * If your proposed interface for polymorphic_value could also work for this method of implementation, then it is probably a better interface. > It's unfortunate we have to use -> instead of . but that's what's available. There have been proposals for operator. ; has this been evaluated to see how it would work with them? Similarly the unified a.b() vs. b(a) syntax proposal. Regards, Phil.

4 6

Outcome v2 peer review dates set
by Niall Douglas 28 Nov '17

28 Nov '17

Outcome v2 will be up for its post-peer-review second review between Friday 19th January and Sunday 28th January with Charley Bay once again serving as review manager. In case you'd like to give it a whirl before then: Docs: https://ned14.github.io/outcome/ Single file edition: https://github.com/ned14/outcome/raw/develop/single-header/outcome.hpp Boost edition repo: https://github.com/ned14/boost-outcome Standalone edition repo: https://github.com/ned14/outcome List of changes since v1: https://github.com/ned14/outcome#changes-since-v1 Compilers needed: GCC 6, clang 4, VS2017 (C++ 14 minimum, C++ 20 preferred) Acknowledgements ---------------- This post-peer-review complete rebuild of Outcome was actually a collaborative effort by a number of the Boost community, and it has been significantly influenced for it. I'd firstly like to thank Charley for taking on the role of review manager for a second time, especially given that he knows from the first time what an awful lot of work it's going to be for him. I am *hoping* that seeing as v2 Outcome is literally a tick box set of the changes you guys recommended last time, that this review will be a quick and simple review. We shall see. I'd like to thank Andrzej for writing the beginning of the tutorial. It set the tone and pacing which I then extended to the rest of the tutorial, and I think the benefit of that shows through as this should be a vast improvement on the (many) v1 tutorials. Andrzej also found many bugs, asked many clever "stupid questions", and acted as a constant peer reviewer throughout the development of v2, including suggesting the present design for payload transport. Andrzej has had a huge influence in the shape, and direction, of this library. I cannot thank him enough, and although he declined being listed as coauthor, I'm thinking of "special thanks to" or something like that in the authorship list as he went above and beyond in his contribution. I'd like to thank Jonathan Müller for doing so much work on his Standardese tool to support Outcome. The current reference API docs on the Outcome website are but a wisp of what will hopefully be in place by the time of the review. Jonathan has had to wrestle with many libclang demons smoked out by Outcome pushing the state of the art, and will have to wrestle with many more yet, but already the huge improvements over the doxygen reference API docs are evident. If anybody has any questions or feedback between now and the review, please let rip. Otherwise thanks for reading! Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Fwd: Using 'detail' folder from a another Boost library
by Jean Guegant 27 Nov '17

27 Nov '17

Hi everyone, I am trying to unify the way Boost.Beast and Boost.Asio pick an implementation of string_view (std::experimental::string_view, std::string_view). In order to do so, I am including the header file <boost/asio/detail/string_view.hpp> within <boost/beast/core/string.hpp> (see PR: https://github.com/boostorg/ beast/pull/910/files). Is that a bad practice to include the a "detail" folder from another library? If so, what would you recommend to solve my unification problem? Sincerely, Jean

2 1

Getting started with open source
by Faisal Riyaz 26 Nov '17

26 Nov '17

Hi, I am Faisal.I am new to open source community.I am familiar with C and C++ language.I am pursuing computer engineering and presently i am in first year.I am interested in contributing to your organisation and learn some stuff. It will be very helpful for me if someone can help me get started. Faisal Riyaz

1 0

[release][build] Permission to merge
by Jürgen Hunold 22 Nov '17

22 Nov '17

Hi! I'd like to merge commit e07c805e to master. This fixes https://github.com/boostorg/build/issues/236 with my PR from https://github.com/boostorg/build/pull/263 Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 1

[optional] regression failures on Linux teeks
by Lorenzo Caminiti 22 Nov '17

22 Nov '17

Hello all, I see the following Boost.Option regression test failures on develop branch: http://www.boost.org/development/tests/develop/developer/optional.html === error 1 === Test output: teeks99-02-dc3.7-14-Docker-64on64 - optional - optional_test_conversions_from_U / clang-gnu-linux-3.7~c++14 Rev 05c2033df7b99d19f4939bf81ca2aeeec592993d / Fri, 03 Nov 2017 00:24:42 +0000 Compile [2017-11-03 01:39:15 UTC]: fail "clang++-3.7" -c -x c++ -Wno-c99-extensions -std=c++14 -O0 -g -fno-inline -Wall -g -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -I".." -o "/var/boost/run/results/boost/bin.v2/libs/optional/test/optional_test_conversions_from_U.test/clang-gnu-linux-3.7~c++14/debug/threadapi-pthread/optional_test_conversions_from_U.o" "../libs/optional/test/optional_test_conversions_from_U.cpp" In file included from ../libs/optional/test/optional_test_conversions_from_U.cpp:12: In file included from ../boost/optional/optional.hpp:64: ../boost/optional/detail/optional_config.hpp:152:48: error: expected value in expression # if BOOST_WORKAROUND(BOOST_GCC, >= 50000) && ^ 1 error generated. === error 2 === Test output: teeks99-02-dc5-1z-lc-Docker-64on64 - optional - optional_test_conversions_from_U / clang-gnu-linux-5.0~c++1z~lc Rev 420dd51fb237f5e75cae0aeb01ec427717e4a748 / Sat, 04 Nov 2017 15:00:43 +0000 Compile [2017-11-04 15:49:56 UTC]: fail "clang++-5.0" -c -x c++ -Wno-c99-extensions -std=c++1z -stdlib=libc++ -isystem/usr/include/libcxxabi -O0 -g -fno-inline -Wall -g -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -I".." -o "/var/boost/run/results/boost/bin.v2/libs/optional/test/optional_test_conversions_from_U.test/clang-gnu-linux-5.0~c++1z~lc/debug/threadapi-pthread/optional_test_conversions_from_U.o" "../libs/optional/test/optional_test_conversions_from_U.cpp" In file included from ../libs/optional/test/optional_test_conversions_from_U.cpp:18: In file included from ../boost/core/lightweight_test.hpp:25: In file included from /usr/include/c++/v1/iostream:38: In file included from /usr/include/c++/v1/ios:216: In file included from /usr/include/c++/v1/__locale:15: /usr/include/c++/v1/string:1942:14: error: expected ';' at end of declaration _NOEXCEPT ^ /usr/include/c++/v1/string:1947:9: error: expected unqualified-id _NOEXCEPT ^ /usr/include/c++/v1/__config:368:21: note: expanded from macro '_NOEXCEPT' # define _NOEXCEPT noexcept ^ 2 errors generated. === The first error only shows on develop, the second error shows up on both develop and master regression tests. Do you know what the issue is on this toolset/platform? I am asking because Boost.Contract uses Boost.Option so it is showing the same failures. Thank you. --Lorenzo

5 7

Re: [boost] [contract] _NOEXCEPT errors in <ostream> for Clang 5.0 C++1z on Teeks Linux
by Lorenzo Caminiti 22 Nov '17

22 Nov '17

Hello Tom, On Tue, Nov 21, 2017 at 7:16 PM, Tom Kent <lists(a)teeks99.com> wrote: > On Mon, Nov 20, 2017 at 9:06 PM, Tom Kent <lists(a)teeks99.com> wrote: >> >> I was able to get to the bottom of this, I hope the libc++ builds start >> cycling normally now. >> >> > This was marked (by me!) as a clang bug - that was fixed in clang trunk >> > in January 2013. >> > I find it hard to believe that you're running a clang built from those >> > sources. >> > >> > -- Marshall >> >> It turns out I had put in a script patch the broken ubuntu header: >> >> https://github.com/teeks99/boost-cpp-docker/blob/11e6d31ca8d28dee8bbb5536f2… >> >> This was a very brittle patch, and when ubuntu fixed it upstream (just two >> months ago!) it caused some kind of conflict. I've removed the patch from my >> teeks99/boost-cpp-docker images, so the clang-3.9, -4, -5, and -6 images >> should be able to use libc++ correctly now. >> >> Thanks for all who helped me straighten this out! >> > > There was a further issue with the need for a `-lc++abi` linker option, it > has been added and the results look better now. Yes, Boost.Contract regression tests now pass on this compiler/platform. The issue was fixed. Thanks a lot. --Lorenzo

1 0

Re: [boost] Interest for Algorithmic Adjoint Differentiation (AAD) in Boost?
by Antoine Savine 22 Nov '17

22 Nov '17

I just realized that the attachment exceeds (by far) the maximum size. With apologies (this is my first post), re-posting now without the attachment. The introduction can be found at the top level of the repository, under the name AADIntro.pdf Thank you. Antoine Savine From: Antoine Savine Sent: 22 November 2017 12:38 To: 'boost(a)lists.boost.org' <boost(a)lists.boost.org> Subject: Interest for Algorithmic Adjoint Differentiation (AAD) in Boost? AAD is a hot topic in machine learning, computational finance, and, I think, other disciplines such as meteorology. Adjoint differentiation computes a large number of derivatives sensitivities for some calculation code in constant time, and operator overloading in C++ permits its semi-automatic implementation over templated code. Please see the intro attached for details. I have been working with AAD (in finance) for 5 years. I have been developing and using professional AAD libraries, I have given dedicated talks and workshops at professional conferences such as Global Derivatives and WBS, and I have been teaching AAD at the MsC in Mathematical Finance at the Copenhagen University in Denmark (Mathematics Department). Our implementation in Danske Bank obtained in 2015 the In-House System of the Year 2015 Risk award. I am planning a book on AAD. And, although that publication is biased towards finance, I have developed an independent, simple and efficient AAD engine that can be found here: tinyUrl.com/aadCentral The implementation uses the latest developments in AAD technology for maximum performance, in particular expression templates. I thought that given the wide interest for AAD, a Boost.Aad module could make sense and I was hoping that it could be based on my developments. Please could somebody let me know if there is interest, and, if so, how I should proceed? Million thanks. Kind regards, Antoine Savine

1 0

[release][poly_collection] Permission to merge to release
by Joaquin M López Muñoz 22 Nov '17

22 Nov '17

Hello, I'm asking for permission to merge the following commit chain into release: https://github.com/boostorg/poly_collection/commit/3609895bd01e5add5971345a… https://github.com/boostorg/poly_collection/commit/18b7d88df360001c2c006f02… https://github.com/boostorg/poly_collection/commit/ce7e7aac60747c6fad5e97d2… https://github.com/boostorg/poly_collection/commit/ab32df47f8811dc7f136a166… https://github.com/boostorg/poly_collection/commit/df754527917b7be013ce558f… Fixes bring compatibility with Clang 3.3 and solve a potential UB problem related to CWG 232 and detected at http://www.boost.org/development/tests/develop/developer/Marshall-UBSAN-pol… I'm waiting for Marshall-UBSAN to cycle through these but all recently updated test runners are working fine. Clang 3.3 is already verified to work by teeks99-02-dc3.3-11-Docker-64on64. Thank you, Joaquín M López Muñoz

2 2

Adding polymorphic_value to boost
by Jonathan Coe 22 Nov '17

22 Nov '17

I'd like to propose adding the class-template `polymorphic_value` to boost. `polymorphic_value` is designed to allow the compiler to correctly generate special member functions for classes with polymorphic components (It's `any` with an interface). `polymorphic_value` has been proposed for standardisation in P0201 and has advanced through the Library Evolution group in Albuquerque (Nov 5-10). https://wg21.link/p0201 A working draft of the proposal and implementation can be found at https://github.com/jbcoe/polymorphic_value I gave a presentation about polymorphic_value at C++::London here: https://skillsmatter.com/skillscasts/9539-a-polymorphic-value-type-for-c-pl… Matt Calabrese has kindly offered to be review manager. Kind regards, Jon

17 56

[release] Boost 1.66.0 Beta 1
by Daniel James 21 Nov '17

21 Nov '17

Boost release 1.66.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.66.0.beta.1/source/> The SHA256 checksums are as follows: e7b23e638e8c3a9da1512439385b04850829cea7bd56d8398677c096857d830b boost_1_66_0_b1.7z 5d0405eb73bd609ebcd54bbc96d4f1e2d97c51b96c4703706695ddd94f942d6b boost_1_66_0_b1.tar.bz2 f0f455e39bc47b2b670a17cb221687506e9a22dc478956d3d8aabb9cb835a7dc boost_1_66_0_b1.tar.gz 694c8b9e902b7981670bce166f675f3875c19326936db51aabd98d2ddfea9b45 boost_1_66_0_b1.zip For details of what's in the release, see <http://www.boost.org/users/history/version_1_66_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

2 1

icl mainainership?
by Avi Kivity 21 Nov '17

21 Nov '17

Hello, I see there are 7 pull requests outstanding against icl (including one of mine), but not activity. Joachim, are you still maintaining the library? If not, perhaps someone can step up.

3 4

Fwd: Adding polymorphic_value to boost
by THOMAS JORDAN 20 Nov '17

20 Nov '17

On 19 November 2017 at 23:41, <boost-request(a)lists.boost.org> wrote: > > Message: 12 > Date: Mon, 20 Nov 2017 01:41:10 +0200 > From: "Peter Dimov" <lists(a)pdimov.com> > To: <boost(a)lists.boost.org> > Subject: Re: [boost] Adding polymorphic_value to boost > Message-ID: <E0D82A60493A491CBFFD0E264E3917D1@pdimov5> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=original > > Peter Bartlett wrote: > > > The only nit I had in the paper was that after all the banging on about > it > > being a value type, we are given operator bool, operator* and operator->, > > making it pointer-like again. Could operator T& and operator T const& > > work? > > Polymorphic means virtual functions, and when you have a > polymorphic_value<T> pv, where T has a virtual function `f`, you can call > `pv->f()`. With a conversion to T&, you can't call `pv.f()`. > I believe I've seen other libraries (maybe Optional) provide the helpful comment above accessors used like this to the effect that 'this accessor syntax does not imply pointer semantics.' I guess -> and * accessors would not be required if there was such as thing as overloaded dot operator.

1 0

MSVC toolset versions on VS2017
by Tom Kent 20 Nov '17

20 Nov '17

I just came across this article on feature updates for their compiler during the VS2017 lifetime, I thought the section talking about version numbers might be of interest to the boost build maintainers and boost config maintainers. The blog post can be found here: https://blogs.msdn.microsoft.com/vcblog/2017/11/15/msvc-conformance-improve… The interesting part about version numbers is three-quarters of the way down the post, under the "MSVC toolset version number increases to 14.12". The table that they have there is also illuminating: Visual Studio Version | MSVC Toolset Version | _MSC_VER --------------------------------------------------------------- VS2015 and updates 1, 2, & 3 | v140 in VS; version 14.00 | 1900 VS2017, Version 15.1 & 15.2 | v141 in VS; version 14.10 | 1910 VS2017, Version 15.3 & 15.4 | v141 in VS; version 14.11 | 1911 VS2017, Version 15.5 | v141 in VS; version 14.12 | 1912 --------------------------------------------------------------- Just wanted to give people a heads-up that this is something that may be encountered in the wild soon. Tom

2 1