- Boost - lists.boost.org

[random] Any news?
by Marco Guazzone 20 Oct '14

20 Oct '14

Hello, Do you have any news on lib mainteners? I and other have pull requests But all seems muted.

4 4

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 20, 2014, at 3:52 AM, John Maddock <boost.regex(a)virgin.net> wrote: >>> For Boost.Config: >>> >>> a mostly minor update. >> >> Great, thanks! According to the feature table, auto return types >> (BOOST_NO_CXX14_RETURN_TYPE_DEDUCTION) are also supported. > > Confirmed - it passes our test case anyway, feature enabled. > >>> For TypeTraits: >>> >>> I suspect you're not going to like the latter as it basically disables >>> working versions of is_nothrow* for msvc-14. The reason is that is >>> appears that Boost.Log ends up using noexcept(non_compiling_expression) >>> which requires SFINAE expression support. >> >> I also think it's the best solution. You can also delete >> the "!::boost::is_const<T>::value" with it now. > > Done. > > Marshall - is it OK to merge these fixes after the beta is out? Absolutely. — Marshall

1 0

1.57.0 beta 1 release candidates available for testing
by Marshall Clow 20 Oct '14

20 Oct '14

Release candidate files for 1.57.0 beta 1 are available at http://boost.cowic.de/rc/ 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. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: MD5 (boost_1_57_0_b1_rc1.7z) = 8633fbf5ebb7eaabcb0f309c14646ae3 MD5 (boost_1_57_0_b1_rc1.tar.bz2) = 8e76f98146793f0fbd2492a9151c405b MD5 (boost_1_57_0_b1_rc1.tar.gz) = d41ff3ffb36ac84ff5bf34f799308907 MD5 (boost_1_57_0_b1_rc1.zip) = 8a844dc36284247b2e936f2120e118b2 Thanks! -- The release managers

4 4

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 17 Oct '14

17 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