- Boost - lists.preview.boost.org

Boost 1.60.0 beta 1 Release Candidate 3 available for testing
by Marshall Clow 14 Nov '15

14 Nov '15

Release candidate files for 1.60.0 beta 3 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. Changes since rc1: * Boost.Sprit has been updated and Boost.Log now builds. * Boost.Math has been updated and now builds. [ Note: The RC2 files that I posted yesterday were incorrectly produced. RC3 is identical to what RC2 should have been -- end note ] Known issues: * Errors when building libraries for visual studio: test and type_erasure. * Boost.Test fails when building on Darwin with gcc 4.9.2 The files (and associated md5s) are: MD5 (boost_1_60_0_b1_rc3.7z) = cfac18348700d0e6c1a0e4418a57e9aa MD5 (boost_1_60_0_b1_rc3.tar.bz2) = d3cb5a59e5b38555096814a6bfbcb441 MD5 (boost_1_60_0_b1_rc3.tar.gz) = db9b011547b8933454d0dfe31f7b8551 MD5 (boost_1_60_0_b1_rc3.zip) = 216c7cd0c15c096ece24d2649a272b51 Thanks! -- The release managers

3 4

Seeking advice regarding inline namespaces
by Louis Dionne 13 Nov '15

13 Nov '15

Dear community, I am seeking advice regarding the usage of inline namespaces for header-only metaprogramming libraries. I was at Eric Niebler's talk on C++11 library design back in 2014, and I understand the problem that inline namespaces solve. I also read all of this past thread [1] on the mailing list, but did not find what I was looking for. I also understand how they can be useful for a normal header-only library __that would provide guarantees about ABI compatibility__. Indeed, if the ABI of the library changes from v1 to v2, then any client C1 exposing types from v1 in its interface and trying to link with a client C2 built against v2 will get a clean link-time error instead of a runtime error. Now, my question has several aspects: (1) How can you guarantee ABI compatibility from one version of a library to the next? IIUC, ABI can be broken by merely changing the size or the layout of a type, so guaranteeing backwards ABI compatibility means freezing those things in time, right? (2) Assuming that it is unreasonable for a library L to guarantee ABI compatibility from one version to the next, would there still be a reason to use inline namespaces to version that library? (3) When using inline namespaces to version a library (at all, not necessarily for header only libraries), are there other guidelines to follow? For example, I see that Eric Niebler's range-v3 library is all stuffed in the range/v3 subdirectory. IIUC, this would allow an eventual range-v4 library to cohabit with the range-v3 library, because people explicitly state which version of the library they're including. Is this the reason behind the v3 subdirectory? Any answer or pointer to answers is appreciated. Regards, Louis [1]: http://boost.2283326.n4.nabble.com/type-traits-general-Best-practice-for-in… -- View this message in context: http://boost.2283326.n4.nabble.com/Seeking-advice-regarding-inline-namespac… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 6

Boost 1.60.0 beta 1 Release Candidates available for testing
by Marshall Clow 12 Nov '15

12 Nov '15

Release candidate files for 1.60.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. IMPORTANT NOTE: The files (and associated md5s) are: MD5 (boost_1_60_0_b1_rc1.7z) = ac6b2128d951ad688421fde2d878c2a7 MD5 (boost_1_60_0_b1_rc1.tar.bz2) = 2fc232f255f1ce8868315da207c05b6b MD5 (boost_1_60_0_b1_rc1.tar.gz) = d594e10f2761abaf957a67c6a223d2a4 MD5 (boost_1_60_0_b1_rc1.zip) = 16a2d512fca7995d5fa421d13f841b0f Thanks! -- The release managers

23 49

[property_tree iostreams smart_ptr] Warning fixes
by Joachim Faulhaber 11 Nov '15

11 Nov '15

Dear all, I have submitted pull requests for mostly warning fixes. 3 of them are still open. https://github.com/boostorg/property_tree/pull/15/files https://github.com/boostorg/iostreams/pull/19 https://github.com/boostorg/smart_ptr/pull/18 Could someone merge them in, so we have this fixed for 1.60. That would be nice. Thanx in advance Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 0

Re: [boost] [Boost-users] Boost 1.60.0 beta 1 Release Candidates available for testing
by Tom Kent 10 Nov '15

10 Nov '15

On Tue, Nov 10, 2015 at 12:05 AM, Raffi Enficiaud < raffi.enficiaud(a)mines-paris.org> wrote: > Le 10/11/15 00:05, Tom Kent a écrit : > >> On Mon, Nov 9, 2015 at 9:52 AM, Marshall Clow <mclow.lists(a)gmail.com >> <mailto:mclow.lists@gmail.com>> wrote: >> >> Release candidate files for 1.60.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. >> >> >> Errors when building libraries for visual studio: test and type_erasure. >> I've grabbed the repeated outputs and posted below. Full logs are at: >> >> 32-Bit: https://gist.github.com/teeks99/bed0ef4204d24677fa4e >> 64-Bit: https://gist.github.com/teeks99/6d0358817ddfe43724f7 >> >> Tom >> > > I have a fix for MSVC but some problems have also been reported for gcc4.4 > c++0x mode. I can merge the fix for MSVC to develop and/or master once > reopened. > > Raffi > Since it is preventing building of the release binaries, I think this should be merged before the beta is released. Tom

3 4

[1.60][spirit] Unmerged changes prevent compilation
by Andrey Semashev 10 Nov '15

10 Nov '15

Hi, The latest 1.60 beta RC fails to build Boost.Log because some changes in Boost.Spirit has not been merged to master. At least these patches need to be merged to master: 1. Fix the duplicate definition of strip_single_element_vector specialization: https://github.com/boostorg/spirit/commit/4d8899fdfe26237d6d983a7ac5528d00f… 2. Fix an attempt to construct an instance of none_t: https://github.com/boostorg/spirit/commit/534cf39f15ced047359ee8b6dfe434635… 3. Although it's not strictly a build breaker, this change fixes a bunch of warnings about signed/unsigned mismatch: https://github.com/boostorg/spirit/pull/140 After applying those patches to the RC Boost.Log builds successfully. These commits and the PR has been in develop for quite some time, could someone merge them to master, please?

4 7

[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

Seeking feedback on SegmentedTreeSeq (sequence data structure with efficient random access insert and erase)
by Chris Clearwater 09 Nov '15

09 Nov '15

Greetings, At this time I would like to solicit feedback for my library SegmentedTreeSeq. It is an implementation of a counted B+Tree that allows efficient random access insert and erase. It's an ideal data structure for an application such as a text editor. I am also seeking interested reviewers as I feel it has reached a state that is ready for formal review. Features: - Implements the union of std::vector, std::deque, and std::list interfaces. - Implements the C++11 allocator model. - Implements the full C++14 interfaces including emplacement and move semantics. - O(log n) to obtain an iterator at any position. - O(log n) insert and erase. - Amortized O(log n) iterator movement. - Strong exception guarantee for insert. - Support for incomplete types. - SCARY iterators. - Best in class performance for many operations. - Low memory overhead for data of any type. Links: - Incubator: http://rrsd.com/blincubator.com/bi_library/segmentedtreeseq-2/?gform_post_i… - Repository: https://github.com/det/segmented_tree_seq - Documentation: https://det.github.io/segmented_tree_seq Thanks, Chris

2 2

[1.60.0] Release Notes
by Daniel James 08 Nov '15

08 Nov '15

Hello everyone, If you haven't done so already, please can you add your entries to the release notes. Easiest way to do so is to create a pull request by clicking on the pencil icon at the top right of the source code at: https://github.com/boostorg/website/blob/master/feed/history/boost_1_60_0.q… Or if you prefer you can email me. thanks, Daniel

2 1

[regression] Test results unavailable
by Andrey Semashev 07 Nov '15

07 Nov '15

Hi, Is anyone able to see develop test results? I'm seeing a blank page.

3 4

[build] How do I build for windows phone?
by John Maddock 06 Nov '15

06 Nov '15

Boost.Build evidently has options for building for windows store and windows phone. The store builds work fine for me, but the phone builds fail as there is no compiler on the command line generated: ../../../bjam config_info msvc-14.0 windows-api=phone -d2 ...found 179 targets... ...updating 5 targets... file ..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0\debug\link-static\runtime-link-static\windows-api-phone\config_info.obj.rsp "config_info.cpp" -Fo"..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0\debug\link-static\runtime-link-static\windows-api-phone\config_info.obj" -TP /Z7 /Od /Ob0 /W3 /GR /Zc:forScope /Zc:wchar_t /MTd /wd4675 /EHs -c -DBOOST_ALL_NO_LIB=1 -DWINAPI_FAMILY=WINAPI_FAMILY_PHONE_APP -D_WIN32_WINNT=0x0602 "-I..\..\.." compile-c-c++ ..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0\debug\link-static\runtime-link-static\windows-api-phone\config_info.obj /Zm800 -nologo @"..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0\debug\link-static\runtime-link-static\windows-api-phone\config_info.obj.rsp" '/Zm800' is not recognized as an internal or external command, operable program or batch file. Any ideas what I'm doing wrong? BTW I can't find any docs mentioning these options - and it's something end users building Boost may well need? Finally a supplementary question: has anyone succeeded in running regression tests on either the store or phone platforms? If I run: /bjam config_info msvc-14.0 windows-api=store I get: testing.capture-output ..\..\..\bin.v2\libs\config\test\config_info.test\msvc-14.0\debug\link-static\runtime-link-static\windows-api-store\config_info.run ====== BEGIN OUTPUT ====== Access is denied. EXIT STATUS: 5 Along with a screen message saying the app can't be run on my PC. Any ideas? Many thanks, John.

3 4

[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

The release branch will close tonight for the 1.60 beta
by Marshall Clow 05 Nov '15

05 Nov '15

Please do not merge to the release branch after tonight until the 1.60 beta is released (scheduled for next Wednesday) unless you have specific approval from the release managers. Thank you. (There will be a chance to merge bug fixes and documentation updates after the beta) -- Marshall (and the rest of the release managers)

2 2

[config] macro for portable restrict and restrict references
by Joel FALCOU 04 Nov '15

04 Nov '15

I pushed a PR that adds the macro BOOST_RESTRICT to take place of the compielr specific __restrcict/__restrict__ keyword. It also comes with an indicator if said keyword can be applied to references. https://github.com/boostorg/config/pull/81 Comments welcome.

1 0

[String Algo] Any reason the predicates don't optimize for random access iterators?
by Nevin Liber 04 Nov '15

04 Nov '15

I was looking in boost/algorithm/string/predicate.hpp and noticed that that the predicates *starts_with, *ends_with, *contains and *equals don't optimize for random access iterators. While I haven't done any benchmarks yet, it seems like it would be faster for random access iterators to do an O(1) length check at the beginning and then while looping only check one iterator against its end instead of two. Thoughts? Nevin :-) -- Nevin ":-)" Liber <mailto:nevin@c <nevin(a)eviloverlord.com>plusplusguy.com> (847) 691-1404

2 1

[test][serialization] Fwd: [Boost-testing] regression testing failure on develop branch
by Rene Rivera 03 Nov '15

03 Nov '15

---------- Forwarded message ---------- From: Aparna Kumta <aparna.kumta(a)oracle.com> Date: Mon, Nov 2, 2015 at 2:42 PM Subject: [Boost-testing] regression testing failure on develop branch To: Running Boost regression tests <boost-testing(a)lists.boost.org> My regresion tests are failing on develop branch as follows: error: at /export/home/boost_regression_develop/boost_sparc-S2_stlport4/boost_bb/src/kernel/modules.jam:107 error: Unable to find file or target named error: 'test_boost_array.cpp' error: referred to from project at error: '../libs/serialization/test' Anyone seeing this issue? Thanks, Aparna _______________________________________________ Boost-Testing mailing list Boost-Testing(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-testing -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

4 3

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

[base_from_member][sun-next_cpp11] problem with variadics at base_from_member
by Joaquín M López Muñoz 02 Nov '15

02 Nov '15

Hi, In 2012, boost::base_from_member was equipped with variadics machinery to perfect-forward construction arguments to the contained member. Unfortunately, Solaris Studio 12.5 on Intel chokes on it (http://tinyurl.com/no7trgb ): "../boost/utility/base_from_member.hpp", line 137: Error: Parameter pack 'x' not expanded with '...' [...] Oddly enough, the same compiler does work fine on Sparc. May I suggest that lines 129-132 of boost/utility/base_from_member.hpp #if !defined(BOOST_NO_CXX11_RVALUE_REFERENCES) && \ !defined(BOOST_NO_CXX11_VARIADIC_TEMPLATES) && \ !defined(BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS) && \ !(defined(__GNUC__) && (__GNUC__ == 4) && (__GNUC_MINOR__ < 4)) be added a special provision for this environment (the same way it already has for GCC 4 and prior)? #if !defined(BOOST_NO_CXX11_RVALUE_REFERENCES) && \ !defined(BOOST_NO_CXX11_VARIADIC_TEMPLATES) && \ !defined(BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS) && \ !(defined(__GNUC__) && (__GNUC__ == 4) && (__GNUC_MINOR__ < 4)) && \ !(defined(__SUNPRO_CC) && defined(__i386) && (__SUNPRO_CC <= 0x5140)) I can't unfortunately test this myself as I don't have access to the compiler. FWIW, my interest in having this fixed is that it's seemingly the only bug preventing Oracle Solaris Studio 12.5 on Intel from supporting Boost.MultiIndex. Joaquín M López Muñoz Telefónica

3 3

[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