- Boost - lists.boost.org

[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

[gil][test] HOWTO set up the Boost testing process for projects with extra prerequisites ?
by Stefan Seefeld 17 Nov '17

17 Nov '17

Hi, I just merged some work to GIL's `develop` branch. This notably involves improvements to the testing infrastructure. Testing GIL is a bit involved, as it requires various backend libraries (PNG, JPEG, TIFF, etc.) to be installed. While the stand-alone testing works fine (https://github.com/boostorg/gil/blob/develop/.travis.yml#L304-L306) the integrated testing will thus fail, until the testing logic is augmented by the necessary instructions to a) install the prerequisites and b) invoke the build system with the appropriate flags (https://github.com/boostorg/gil/blob/develop/io/test/Jamfile#L13-L22) Thus my question: do we have any documentation that explains how to do this ? What do I (as GIL maintainer) or any testers need to do for the integrated testing to work ? (I can't resist: all these libraries that have special requirements really shouldn't be built and tested in such a monolithic process. It's a burden to all tester, maintainers, and packagers. It would be far better to handle them more independently.) Stefan -- ...ich hab' noch einen Koffer in Berlin...

3 8

[density] paged memory and concurrency
by Giuseppe Campana 17 Nov '17

17 Nov '17

Hi, in the last year I’ve been experimenting concurrent data structures on density, a C++11 library focused on: - Page-based memory management. - Heterogeneous and function queues. Single-threaded, mutex-ed, lock-free and spin-locking versions are available. Lock-free and spin-locking queues support any combination of single/multiple producers/consumers. - Lifo memory management, mainly to provide a safe alternative to alloca with almost the same performances. - Parametric control of the progress guarantee in concurrent algorithms. I have to do a major update to fix the known issues, so I’d like to receive any feedback before it, especially about the design. The document http://giucamp.github.io/density/doc/html/implementation.pdf explains the implementation of almost everything, though it’s quite long. Documentation: http://giucamp.github.io/density/doc/html/index.html Repository: https://github.com/giucamp/density Is there any interest on it? Giuseppe Campana.

1 0

Re: [boost] [Boost-users] Could guys help me on a boost MPI link error
by degski 16 Nov '17

16 Nov '17

On 16 November 2017 at 07:33, Renfan Luo <Renfan.Luo(a)perpetuum.com> wrote: > Thanks a lot! After changing X64 to X86 on the top of drop-down window > of IDE, the problem has been fixed. > You're welcome, degski

1 0

bjam boost build on windows - changing the path strategy (stage)
by James E. King, III 16 Nov '17

16 Nov '17

I would like to build boost into a prefix directory (.\b2.exe --prefix=C:\prefix) containing "C:\prefix\include\boost\..." and "C:\prefix\lib", just like the linux build does. On Windows it builds into ""C:\prefix\include\boost-1_66\boost\..." instead - is there a bjam control to get rid of the version in the prefix include path for header copies? - Jim

5 5