October 2014 - Boost - lists.boost.org

Re: [boost] [Boost-users] 1.57.0 beta 1 release candidates available for testing
by Marshall Clow 20 Oct '14

20 Oct '14

On Oct 19, 2014, at 2:22 PM, Vicente J. Botet Escriba <vicente.botet(a)wanadoo.fr> wrote: > Le 18/10/14 00:40, Marshall Clow a écrit : >> Release candidate files for 1.57.0 beta 1 are available at >> http://boost.cowic.de/rc/ >> >> > Hi, could I merge the following to the master branch? > > https://github.com/boostorg/thread/commit/3e28ea806c412c697f134fdaacbccc9b6… > https://github.com/boostorg/thread/commit/1029fa9c5937269c9a65848972da7d8bb… > https://github.com/boostorg/thread/commit/63dd439992cbc6d62f0af442f4669121e… > > > This fixes "deferred/ready futures on variadic when_all/when_any.” Vicente — I’d appreciate if you would merge those *after* we release the beta. There will be about a week where the master branch will be open again. — Marshall (who would like to get the beta out to a wide audience sooner, rather than later)

1 0

Performance characteristics of Boost mutex
by Philip Bennefall 18 Oct '14

18 Oct '14

Hi all, I am detecting some lock contention in my application, and while reading up on this I came across the concept of lightweight mutexes versus supposedly non-lightweight mutexes. I am wondering, can Boosts non-recursive mutex implementation be considered lightweight? In boost/detail I see lightweight_mutex. Should I be using that? I need no interprocess support here, and I want the lock to be as fast as possible. If I do decide to use lightweight_mutex, is it compatible with the regular non-recursive Boost mutex so that I can use it with higher level classes like lock guard, condition variables, barriers etc? Thanks in advance for any insight. Kind regards, Philip Bennefall

3 4

Re: [boost] [asio] RFC on new reliable UDP library
by Niall Douglas 18 Oct '14

18 Oct '14

On 17 Oct 2014 at 10:54, Juan Carlos Franzoy wrote: > > A long term dream of mine is for ASIO to become the standard event > > dispatch loop for all C++ programs, so other libraries simply hook > > into ASIO's dispatch and everything interoperates cleanly without > > lots of hassle and brittle boilerplate. I also feel a grievance > > against every single library firing up their own thread pools or > > worker threads when ASIO gives you that for free. > > We tried to use ASIO as an event dispatch, but it failed to scale in > multicore machines. Currently we are experimenting using one io_service > per core and manually managing the load balance migrating sockets between > io_services. If this is on Linux, then yes I have found this too. ASIO uses std::mutex as its lock, and the spin count on pthread_mutex in glibc is too short for modern CPUs. My proposed concurrent_unordered_map, which can do safe concurrent erase, would solve the need for ASIO needing a central mutex on Linux. > Maybe ASIO has to manage only io (only io threads) and has to delegate > to an external thread pool the execution of user handlers. Although I > don't know if it is technically possible. ASIO's present design is suboptimal in many regards. It's one of my biggest qualms in the present design being standardised as-is. I may, six months from now, be able to say in considerable detail what exactly to change if things pan out. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Ticketspam
by Daniel Frey 17 Oct '14

17 Oct '14

One more to remove: <https://svn.boost.org/trac/boost/ticket/10560> Thanks, Daniel

10 18

NT² eand Boost.SIMD release 3.1
by Joel FALCOU 17 Oct '14

17 Oct '14

NT2 is a Matlab inspired, high-level API for scientific computation in C++. Boost.SIMD is a candidate library for inclusion in Boost dealing with the portable encpsulation of SIMD instructions sets. This following releases updates NT2 and Boost.SIMD libraries to version 3.1 This new release of NT2 and Boost.SIMD focused on fixing performance issues and add some new support for architecture and parallel algorithms. The main new features include: - Linear Algebra functions can now use GPGPU through the MAGMA library whenever possible. - Reduction and Scan operations now works with more shared memory back-end - Altivec support is now complete for the VMX ISA We wish to thanks Ian Masliah for his work on MAGMA, Antoine Tran Tan for the shared memory support and Pierre Esterie participation to the Altivec ISA completion. Special thanks to Tim Blenchmann and khegeman for their help and patch submisisons throughout this development. The release Changelog is here : https://github.com/MetaScale/nt2/releases/tag/3.1.0 The files can be download from : http://nt2.metascale.org/downloads/ The Documentation (in progress) is here : http://nt2.metascale.org/doc/html/index.html **Next release announcment** This release is the last C++03 compliant version of both NT2 and Boost.SIMD. The next release - 4.0 - will be C++11 only. The new minimal version of supported compilers will be : - g++ 4.6 - Microsoft Visual Studio 12 (2013) - clang 3.4 - icc 12.1 The main reason for this change is to be able to properly fix the compile-time issue that one may experience. It'll also allow us to use some C++11 feature to simplify or streamline some of the user interface. * The NT2 Team

5 7

Is there something like shared_array<T> but with iterators?
by david.hagood＠gmail.com 15 Oct '14

15 Oct '14

I am doing signal processing, and in order to avoid data copies I need something that: 1) can adopt a buffer of data (e.g. take ownership of a T*) 2) Release that buffer via an appropriate method (e.g. take a deallocator object). 3) Provide operator[] over that buffer 4) provide shared ownership semantics So far, that's shared_array<> to a T [sic] However, I need one more thing: 5) provide iterator support (begin(), end(), cbegin(), cend()) The current shared_array<> doesn't provide that - is there anything else that does?

3 2

[interprocess] BOOST_INTERPROCESS_SHARED_DIR_PATH from env variable
by Jakub Szymanski 11 Oct '14

11 Oct '14

Hi, Will it be possible to have shared_dir not hardcoded? Currently it is determine by some tricks (some involve event log parsing on windows, which fails a lot). The only practical solution for us was to use BOOST_INTERPROCESS_SHARED_DIR_PATH define. boost/interprocess/detail/shared_dir_helpers.hpp inline void get_shared_dir(std::string &shared_dir) { #if defined(BOOST_INTERPROCESS_SHARED_DIR_PATH) shared_dir = BOOST_INTERPROCESS_SHARED_DIR_PATH; #else get_shared_dir_root(shared_dir); #if defined(BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME) shared_dir += "/"; get_bootstamp(shared_dir, true); #endif #endif } That has limitations tough as it makes it very difficult to test software in isolation (it requires access to the same folder). Similarly it makes is difficult to run program of machines with different file structure. Can it be configurable by some environment variable ? cheers --jakub

2 3

[Modularization] master and develop on super project.
by Kohei Takahashi 10 Oct '14

10 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Is there any policies for merging develop into master and sending pull-request on super project (boost.git)? Before 1.56.0 release, each libraries merged develop into master, though boost.git didn't. It caused to remain some defects in master (also release archive), which are already fixed in develop branch. e.g. - - https://svn.boost.org/trac/boost/ticket/5677 - -- https://svn.boost.org/trac/boost/ticket/6946 (dup of #5677) - - https://svn.boost.org/trac/boost/ticket/10507 and more tickets might exist... The wiki[1] describes about each libraries, but about super project is still absent. [1] https://svn.boost.org/trac/boost/wiki/StartModWorkflow Thanks, Kohei Takahashi -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUN8IGAAoJEGGyPxPRp/zoW3QP/RBWJ7dcmS8TEr7SpQW97QW4 17chTXKLkqHboHxCJuswXb1rlnmBxxooFItA5kFudEu7U1x5OekPfw+oroQP7v+C CgS5eHanitjprkijvJO2SS61a/YdF/1hMJuHUWzd62hI5ZXWQvNryeJtNl0K0hFb H9EhniJltvBxjOOdvjUsd9XCPby1afi5jOCUjC3J08X6WruRuI5BhCNElVQOSxMG yzaxuLeFDy8L9CICAU8RNEkBEjY1n5rYAVnbETX1WSSoDGEHblRUTOT7JQwSuWWx 0ymdz5cHisM+QoGuLUI0BQS9mayik3vAsre68Ve/xxTHU3LaRRVvaLJIH0YrRRwX fQmyJVGtIbUIhgfmdK8mq050wNOwdzefVfGDkq/XNo+wwlwA6vS4D5gqzfthNL6S HdXI8TIJtdRUYk66vFVcL5uf3PjoW4cZpWYceq1h1EOsIfXuzpr6uO0NDhqEFD+D I3vSmGPV1eAPYpQHP7jeOePMn1EPItU0sVqLk0f6ymafyqnaPU52zhcS45VMS85Q krk+ixO5bND6IU0EgYDn7QZHrTdACDcH5UGscBmxrSUwJ4DrgB6q8mAG/Ek0lZBK /UyXOu3k+ZtrYQIu5aayIyANp6p/EKGNgT7F7/4t0WZzxleskEPzKX9XKoPJnjQ9 aZrV3aXQSRrlEeBhU4fk =KrkS -----END PGP SIGNATURE-----

1 0

[config] Need some clang testing help...
by John Maddock 09 Oct '14

09 Oct '14

Folks there are persistent bug reports relating to clang with libstdc++ not correctly detecting the std lib feature set, see https://svn.boost.org/trac/boost/ticket/7473 for a lengthy discussion on the issue, and why it's been unsolvable. Anyhow, I've just committed a tentative patch in https://github.com/boostorg/config/commit/b36566fe04a89103b7ef5569c03e3a26e… and I'd be grateful if as many folks as possible can test this with their clang/linux/libstdc++/C++11 setups as they can. It works well for me locally, but that's only one possible clang configuration. BTW the easiest way to patch your Boost version is probably to download a replacement libstdcpp2.hpp from here: https://raw.githubusercontent.com/boostorg/config/b36566fe04a89103b7ef5569c… Many thanks in advance, John.

3 8

[range] How does remove_erase() work?
by Stephan T. Lavavej 09 Oct '14

09 Oct '14

Hi, I'm updating my Uniform Container Erasure proposal [1], and I was informed that Boost.Range has a similar-ish remove_erase(). I have a very simple question about its implementation, so I can describe it accurately in my revised proposal, but I don't really want to look at erase.hpp's guts. Does remove_erase() just use the erase-remove idiom, or does it contain special cases for the vector-like family, list-like family, and map-like family? (As N4009 explained, the erase-remove idiom is suboptimal for list, and won't compile for forward_list and the map-like family.) Thanks, STL [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4009.htm

3 4