October 2014 - Boost - lists.preview.boost.org

The master branch is now open for merging
by Marshall Clow 20 Oct '14

20 Oct '14

Please limit to changes that have been implemented in develop and whose tests have cycled. We will be closing the master branch again sometime next week (for the final release two weeks from today). The following problems were noted with the RC (and, I believe, have fixes ready): * Interprocess is broken for MinGW * Visual C++ 14 CTP 4 without BOOST_MSVC_ENABLE_2014_JUN_CTP * For MSVC14, TypeTraits 9de6a49 is missing in master * Thread fixes from Vicente Still needed to do: * Can someone take a look at http://lists.boost.org/Archives/boost/2014/10/217257.php, please? * MSVC 8.0 compilation failures * range/detail/any_iterator.hpp is broken because it expects postfix_increment_proxy and writable_postfix_increment_proxy to be in namespace boost::detail, but they are in boost::iterators::detail now. * There’s a few old Random fixes that need to be looked at. (and anything else we find) Thanks to everyone who tried out the RC, and please encourage people to try the beta! — Marshall

1 0

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 7:06 AM, Marcel Raad <raad(a)teamviewer.com> wrote: > Marshall Clow <mclow.lists <at> gmail.com> writes: > >> Release candidate files for 1.57.0 beta 1 are available [...] >> 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. > > range/detail/any_iterator.hpp is broken because it expects > postfix_increment_proxy and writable_postfix_increment_proxy to be in > namespace boost::detail, but they are in boost::iterators::detail now. > > Those errors are also visible in all of the type_erased_* regression tests > of range. I made an executive decision to push the beta out with this problem (and the MSVC 8.0 bugs, too), because I wanted to get a wider audience looking at the beta. Thanks for reporting this, and now let’s fix them. — Marshall

1 0

[intrusive] More features for treap?
by Phil Endecott 20 Oct '14

20 Oct '14

Dear All, I've been looking at Boost.Intrusive's treap, and finding that it doesn't quite do what I need. Here's an example: say I have data about earthquakes in the form (date, magnitude, description). I can store that in a treap with date as the key and magnitude as the priority. Now I'd like to be able to do operations like: - Find the strongest earthquake between dates A and B. - Iterate over all the earthquakes with magnitude > X in date order. - For each year (or month, or decade etc) find the strongest quake. The first two are straightforward in a treap, but the current Boost.Intrusive API doesn't (AFAICT) let me do it. (The third one is less obvious.) I have been wondering how the API could most easily be extended to support this sort of thing, and I'm coming to the conclusion that it is probably best to expose the actual tree structure so that the algorithms for these operations can be implemented explicitly by the user code. I have had similar thoughts in the past about other trees i.e. augmented trees to implement interval trees; the choice is either (a) implement these things inside Boost.Intrusive; (b) don't use Boost.Intrusive at all; (c) extend the intrusive API to expose the actual tree structure. In cases like these extensions to treap, the new operations are simple compared to the complexities of inserting and erasing elements; being able to use the existing implementations of those operations while adding other (non-mutating?) features would save a lot of work. Any thoughts anyone? (Is anyone else using treap?) Regards, Phil.

2 3

[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