- Boost - lists.preview.boost.org

[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

[multiprecision]: 15% slowdown using -std=c++11 compiler flag
by Kim Walisch 20 Nov '17

20 Nov '17

I have been investigating a 15% performance regression in my C++ primesum program (https://github.com/kimwalisch/primesum/tree/256-bit) over the last 2 days. By lots of benchmarking I was able to identify the boost multiprecision library together with -std=c++11 (or -std=gnu++11) as the culprit for the performance regression because I have also a version of the primesum program which does not use the boost multiprecision library and in this version there is no performance regression when compiling using -std=c++11. I have tested using multiple versions of the boost multiprecision library including the latest 1.65.1. The slowdown happens on both GCC (versions: 5.4, 6.4, 7.2) and Clang (version 3.8) on x86_64 Linux. I am only using the int256_t and uint256_t types (hence cpp_int backend) and I am doing only simple integer arithmetic: +, - and *. Is this a known issue and is there a known workaround e.g. special compiler flag? I could revert to C++98 but I really don't want to do that... Thanks, Kim Walisch

2 2

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

20 Nov '17

Hello all, Most of Boost.Contract regression test fail for toolset clang-gnu-linux-5.0~c++1z~lc on platform teeks99-02-dc5-1z-lc-Docker-64on64 because of the following error on #include <ostream> done by Boost.Range (and sometimes by Boost.IOStreams): "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 -DBOOST_CONTRACT_DISABLE_THREADS -DBOOST_CONTRACT_DYN_LINK -DBOOST_SYSTEM_DYN_LINK=1 -I".." -I"../libs/contract/test/function" -o "/var/boost/run/results/boost/bin.v2/libs/contract/test/function-smoke.test/clang-gnu-linux-5.0~c++1z~lc/debug/threadapi-pthread/function/smoke.o" "../libs/contract/test/function/smoke.cpp" In file included from ../libs/contract/test/function/smoke.cpp:9: In file included from ../libs/contract/test/function/../detail/oteststream.hpp:10: In file included from ../boost/iostreams/tee.hpp:18: In file included from ../boost/iostreams/detail/adapter/device_adapter.hpp:22: In file included from ../boost/iostreams/detail/call_traits.hpp:15: In file included from ../boost/iostreams/traits.hpp:38: In file included from ../boost/range/iterator_range.hpp:14: In file included from ../boost/range/iterator_range_io.hpp:32: In file included from /usr/include/c++/v1/ostream:138: 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. Of course, Boost.Range and Boost.IOStreams show the same error on this toolset/platform independently of Boost.Contract. Any idea what the issue might be? Thanks, --Lorenzo

5 9

[operators] A modern SFINAE-based version of boost::operators?
by Beman Dawes 19 Nov '17

19 Nov '17

Peter Sommerlad, committee member and C++Now presenter who often proposes additions to fill in holes in the standard library, asked me: Are you aware of anybody who tried to provide a boost::operators style of automatically providing additional operators with a single base class that through SFINAE injects all possible operators based on the ones defined in the template parameter? This won't give you the control of the current boost::operators, but would be much easier to teach. For example struct Me : make_operators_for<Me>{ Me& operator+=(Me const&); // You get + bool operator<(Me const&) const; // You get all relops (<=> will make that obsolete) Me& operator++(); // you get postfix //etc. }; Today we have the facilities and compilers to make that happen. What do you think? Who should I ask? Anyone doing any work on operators or have any thoughts about updating boost::operators? --Beman

14 31

[python] Incorrect link
by Christian Henning 19 Nov '17

19 Nov '17

Hi all, on page http://boostorg.github.io/python/doc/html/tutorial/tutorial/embedding.html the link to http://www.python.org/doc/api/exceptionHandling.html is dead. Perhaps, it should be this link: https://docs.python.org/3/tutorial/errors.html Regards, Christian

1 0

[release] Boost 1.66.0 Beta 1 Release Candidate 2
by Daniel James 19 Nov '17

19 Nov '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/> You need to scroll past the first release candidates to find the downloads. The SHA256 checksums are as follows: e7b23e638e8c3a9da1512439385b04850829cea7bd56d8398677c096857d830b boost_1_66_0_b1_rc2.7z 5d0405eb73bd609ebcd54bbc96d4f1e2d97c51b96c4703706695ddd94f942d6b boost_1_66_0_b1_rc2.tar.bz2 f0f455e39bc47b2b670a17cb221687506e9a22dc478956d3d8aabb9cb835a7dc boost_1_66_0_b1_rc2.tar.gz 694c8b9e902b7981670bce166f675f3875c19326936db51aabd98d2ddfea9b45 boost_1_66_0_b1_rc2.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.

3 2

Re: [boost] Adding polymorphic_value to boost
by Tom 19 Nov '17

19 Nov '17

> Message: 10 > Date: Thu, 16 Nov 2017 02:14:30 -0700 > From: Jonathan Coe <jonathanbcoe(a)gmail.com> > To: boost(a)lists.boost.org > Cc: Matt Calabrese <calabrese(a)google.com> > Subject: [boost] Adding polymorphic_value to boost > Message-ID: > <CAAbBDD9Ck+LhQ4iUraBtBkxexVKDt167qxyfTpDQqYM9bcMqLQ(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > 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 Hi, I'd be interested in such a utility. Mathias Gaunard proposed something similar on the mailing list a long while ago, I implemented a simple version myself based on that. I have a small number of questions. Given that this is a value type, does the current approach over-expose pointer (ownership) in the interface (in essence it still appears to be a glorified smart pointer) and understate its more fundamental purpose as a regular value with dynamic type? There might be other things which can usefully be added for such a value type, for example permitting direct construction of an object of specific (derived) type, by passing the type as well as the arguments for the constructor of that type (or wrapping the arguments in some kind of in-place factory with explicit type). Something like: // Simple wrapper to enable a static type to be passed through a forwarding constructor. template <typename T> struct Type {}; // Forwarding constructor - actual type is deduced from type wrapped in (unnamed) first argument's type template <typename D, typename... Args> explicit poly_obj(Type<D>, Args&&... args); // Also could have an emplace member function template <typename D, typename... Args> void emplace(Type<D>, Args&&... args); In theory you wouldn't need to expose pointers in the interface at all? In fact, should a type-erasure library be preferred (e.g., Boost.TypeErasure or Adobe.Poly) as it provides a more general solution for manipulating polymorphic value types (though typically harder to use)? Would you be considering supporting C++98 via using the boost::move library? Regards, Tom

1 0