October 2015 - Boost - lists.boost.org

[Range] sorted and randomized adaptors
by Mohammed El-Afifi 10 Nov '15

10 Nov '15

Hello everybody, I know this might have been raised a few times before in this mailing list, but I'd like to know if it's possible(or otherwise what would prevent) to have sorted and randomized adaptors so that I may have a sorted and randomized view of a range respectively. Something like vector<int> x; // operations to fill x x | boost::adaptors::sorted; x | boost::adaptors::randomized;// That one might also take an optional random generator as a parameter. I understand that in this case the adaptor isn't entirely lazy as the adapted(x here) must be completely consumed before producing a single element in the resulting range. I want to know however if having such adaptors may contradict any basic principles of the existing adaptors. P.S. Two other threads I found that discussed the same idea(for sorted only): - http://lists.boost.org/Archives/boost/2009/03/149247.php - http://lists.boost.org/Archives/boost/2006/05/105122.php

3 2

[thread] boost::future::then
by Vladimir Prus 06 Nov '15

06 Nov '15

Hi, looking through docs for some other futures implementation [1], I see this: Why not use boost::future? # At the time of writing, 1.53 (the first version with the requisite features) was brand new, not well-tested, and not available to [...] developers. It is still a bit buggy/bleeding-edge They haven't fleshed out the threading model very well yet, e.g. every single then currently spawns a new thread unless you explicitly ask it to work on this thread only, and executor support was nonexistent (and now, is still experimental). Now, 1.53 is ancient. Can anybody comment on these statements regarding boost::future::thread state in 1.59? In particular, suppose I have this: // Thread 1 boost::promise<int> pi; boost::future<int> fi = pi.get_future(); // pass pi to thread 2 somehow fi.then(....); // Thread 2 pi.set_value(100); And I want continuation to be executed in thread 1, assuming that thread 1 runs Qt event loop, allowing me to use QTimer::singleShot, or queued signal, or similar mechanism. How would I go about making boost::future do it? Has anybody done so? Thanks, Volodya

4 41

Interest in a Boost.Chrono/Date library
by Vicente J. Botet Escriba 03 Nov '15

03 Nov '15

Hi, maybe some of you have already see the Howard Hinnant presentation at CppCOn2015 [1] about his new data-v2 library [2]. My prototype of Boost.Chrono/Date library ([3] ] was based on the Howard original library, but when we want to reach the maximum of performances we need to use a specific date class for each usage. This is what Howard explains in his marvelous presentation ans his tiny date library My post here wants to know if there is interest in a library providing what H.H. date library provides in Boost. Note that his data-v2 library yet doesn't provides as much as Boost.Date provides but IMHO it is much elegant and efficient. If there is enough interest, I will request you to do a first review of the H.H. Date-V2 library. Then once we have a consensus I will make my POC Chrono/Date library ready for review. H.H. Date-V2 is under MIT license, which IIRC is compatible with the Boost license. I don't know yet if would need to add this license, as my POC [3] is already a good starting point, nevertheless, I would like to know if there could be any issues about having the source under both licenses. Best, Vicente [1] https://www.youtube.com/watch?v=tzyGjOm8AKo [2] https://github.com/HowardHinnant/date [3] https://github.com/viboes/chrono_date/commits/master First commit Nov/2011 Last-Mars2014

8 17

Math tools polynomial enhancements
by Jeremy Murphy 02 Nov '15

02 Nov '15

I was just looking at the polynomial class and thinking that it could be enhanced substantially with more operators. Presumably with division and remainder it would be a Euclidean ring and then you could even call gcd on it. I have a draft implementation ready but I wanted to check that there is interest from the maintainers. Cheers. Jeremy

9 27

[GitHub] [PR] setting default branch to 'develop'
by Michel Morin 01 Nov '15

01 Nov '15

Hi, We sometimes forget to change the base branch of PR from 'master' to 'develop', even if we know PR should be made against 'develop' branch! To prevent from accidentally making PR against master branch, it'd be nice to **set the default branch to 'develop' branch** for Boost repositories on GitHub. (Then, the default base branch of PR would be set to 'develop' branch.) To change the default branch, it takes just a few clicks on web browser: https://help.github.com/articles/setting-the-default-branch/ Thoughts? Regards, Michel P.S. Some libraries have already done this, but most of Boost libraries don't do this yet.

10 22

[Config] BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE not defined in MACOS for GCC-5
by Vicente J. Botet Escriba 29 Oct '15

29 Oct '15

Hi John, I'm having an issue with gcc-5.1 on MacOs. BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE is not defined. I see that there are things like #if __MACH__ && !defined(_MSL_USING_MSL_C) ... # if (__GNUC__ == 4) // Both gcc and intel require these. # define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE # define BOOST_HAS_NANOSLEEP # endif #else ... // BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE not defined here #endif Wondering why the GCC version must be 4 and why when _MSL_USING_MSL_C is defined these PTHREAD attributes are not defined neither. BTW, when I compile with version 4 everything works correctly. Vicente

3 3

[website] update version for Oracle Solaris Studio on the Boost website
by Aparna Kumta 29 Oct '15

29 Oct '15

The Boost1.59 page at http://www.boost.org/users/history/version_1_59_0.html under 'Compilers Tested' section, contains an entry for Sun( Oracle Solaris Studio). This needs modification for the upcoming Boost 1.60 release for which I would like to submit a PR. I looked at https://github.com/boostorg/website but not sure if this is the correct repository. Could someone please point me as to where I need to submit the PR? Thanks, Aparna

2 1

[graph] dijkstra pull request ping
by Piotr Wygocki 28 Oct '15

28 Oct '15

Dear all, this mail concerns this pull request: https://github.com/boostorg/graph/pull/13 which is currently over one year long. Maybe, the idea of the patch is unclear or needs some additional discussion. The patch solves the problem which arises when using no_init version on dijkstra algorithm and passing a custom distance_map. This algorithm is implemented as call to BFS, which is very unfortunate since it is not BFS. Maybe BFS could be seen as special case of dijkstra with custom priority queue but not the other way around. The current implementation introduces some inefficiencies, which are described in the pull request's comment. I've created very short and direct patch which makes the implementation straight forward. Additionally, the unit test is added to check mentioned efficiency gain. Are there any additional questions concerning this pull request? Could it be possibly be merged to master? Maybe, we can use a favour of the community maintenance team. Regards, Piotr Wygocki

5 20

Boost.Log 1.59.0 incompatible with MSVC option /Zc:wchar_t-
by Giel van Schijndel 28 Oct '15

28 Oct '15

Hi, I'm trying to build Boost.Log on MSVC9 (aka Visual Studio 2008) with the [/Zc:wchar_t-][1] option (necessary due to a vendor's SDK we're using). Unfortunately this fails to build. The mentioned option turns wchar_t into a typedef to unsigned short (i.e. it's not longer a distinct type). TLDR: My question _why_ is boost::log::aux::is_character_type<wchar_t> excluded when BOOST_NO_INTRINSIC_WCHAR_T is #defined? I see no harm in including it unconditionally. For some reason however, the template meta-function boost::log::aux::is_character_type<T>'s specialisation for wchar_t is guarded by !defined(BOOST_NO_INTRINSIC_WCHAR_T) [2]. This means wchar_t is _not_ regarded as a character type and prevents instantiation of the boost::log::aux::code_convert functions [3] which are _still_ used. The only reason I can see for excluding this is to prevent a _potential_ conflict with multiple specialisations for the same type (because of the typedef nature of wchar_t). But the only other specialisation that could potentially give a conflict is the one for char16_t, and that's mandated by C++11 to be a distinct type (AFAIK the only reason why wchar_t isn't always distinct type on Windows/MSVC is because they introduced the type pre-standardisation, so I see no reason why that mistake should be repeated for char16_t). For reference, the mentioned option's usage is detected in boost by this option preventing #definition of _NATIVE_WCHAR_T_DEFINED to indicate it did this. In boost/config/compiler/visualc.hpp there's the following code: > #ifndef _NATIVE_WCHAR_T_DEFINED > # define BOOST_NO_INTRINSIC_WCHAR_T > #endif [1]: https://msdn.microsoft.com/en-us/library/ms933181.aspx [2]: https://github.com/boostorg/log/blob/boost-1.59.0/include/boost/log/detail/… [3]: https://github.com/boostorg/log/blob/boost-1.59.0/include/boost/log/detail/… -- Met vriendelijke groet, With kind regards, Giel van Schijndel

2 3

boost lockfree queue.hpp - alternate implementation w/o compare_exchange
by boost＠mccart.us 28 Oct '15

28 Oct '15

Is there any interest in an alternate implementation of a lockfree queue that doesn't use compare_exchange (assuming it is correct, or can be made to be correct)? I have a multi-producer / multi-consumer implementation that generally doesn't suffer nearly as much from contention. On my hardware (an older high-end 64 bit x86 workstation) I get roughly comparable throughput with existing boost lockfree queue with 1 producer and 1 consumer. With 4 producers and 4 consumers I get about 3x throughput gain on existing boost lockfree queue. However, this implementation has a weakness, it suffers in over subscription scenarios (threads in middle of push/pop that lose their time-slice); with twice as many threads as cores its performances is comparable to boost lockfree queue (using try_push/try_pop, otherwise throughput is down the toilet), and with 4x thread/core ratio the throughput is somewhat less than boost lockfree queue. This was tested on Windows 7 x64 with Inel Xeon X5355 x 2 (2 sockets w/ 4 cores a piece) @ 2.66 Ghz and 32 GB RAM @ 667 MHz. The implementation can be found here: https://github.com/benmccart/GuarunteedMpmcQueue/blob/master/queue/queue.hpp Is the implementation correct? Can anyone spot any race conditions, or conditions under which the implementation would fail to work as expected (other than queue is full/empty or over-subscription)? ~Ben

5 14