- Boost - lists.preview.boost.org

[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

[serialization]cannot build libboost_serialization.so.1.60.0 with Oracle Solaris Studio
by Aparna Kumta 28 Oct '15

28 Oct '15

I see the following error when compiling Boost 1.60 in develop branch with Oracle Solaris Studio development compiler with -library=stlport4. "CC" -compat=5 -library=stlport4 -temp=/tmp/bn -xO4 -mt -erroff=%none -m32 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I".." -c -o "/export/home/sstrunk-tester/boost_regression/boost_regression_develop/boost_sparc-S2_stlport4/results/boost/bin.v2/libs/serialization/build/sun-next_stlport4/release/link-static/threading-multi/basic_text_iprimitive.o" "../libs/serialization/src/basic_text_iprimitive.cpp" "../boost/archive/basic_streambuf_locale_saver.hpp", line 75: Error: sync is not a member of std::ios . "../boost/archive/impl/basic_text_iprimitive.ipp", line 112: Where: While instantiating "boost::archive::basic_ios_locale_saver<char, std::char_traits<char>>::~basic_ios_locale_saver()". "../boost/archive/impl/basic_text_iprimitive.ipp", line 112: Where: Instantiated from boost::archive::basic_text_iprimitive<std::istream>::basic_text_iprimitive(std::istream &, bool). "../libs/serialization/src/basic_text_iprimitive.cpp", line 25: Where: Instantiated from non-template code. 1 Error(s) detected. This seems to prevent building libboost_serialization.so.1.60.0, and a recent regression after changes to the serialization library. Thanks, Aparna

3 4

[type_traits][multi_index][msvc-7.1] problems with is_const in VC 7.1
by Joaquin M López Muñoz 27 Oct '15

27 Oct '15

> Hi, Boost.MultiIndex is failing at master for VC 7.1: http://tinyurl.com/oxflkj6 .\boost\multi_index\identity.hpp(75) : error C2535: 'Type &boost::multi_index::detail::const_identity_base<Type>::operator() (const boost::reference_wrapper<Type> &) const' : member function already defined or declared the problem seemingly being with boost::is_const. The offending code looks like template<typename Type> struct const_identity_base { // produces the error above if Type is not const }; template<typename Type> struct non_const_identity_base { ... }; template<class Type> struct identity: mpl::if_c< is_const<Type>::value, detail::const_identity_base<Type>, detail::non_const_identity_base<Type> >::type { }; Boost.TypeTraits recently changed its is_const implementation to the very simple template <class T> struct is_const : public false_type {}; template <class T> struct is_const<T const> : public true_type{}; template <class T, size_t N> struct is_const<T const[N]> : public true_type{}; template <class T> struct is_const<T const[]> : public true_type{}; which relies on template partial specialization (supposedly supported by VC 7.1). Yet, seems like const_identity_base is wrongly selected for a non-const Type. Any clues about what might be going on? Thank you, Joaquín M López Muñoz Telefónica

5 15

[tools] updating sun.jam
by Aparna Kumta 27 Oct '15

27 Oct '15

I am not familiar with the syntax to update sun.jam file. In tools/build/src/tools/sun.jam, lines 153-156 contain 153: actions link.dll bind LIBRARIES 154: { 155: "$(CONFIG_COMMAND)" $(OPTIONS) -L"$(LINKPATH)" -R"$(RPATH)" -o "$(<)" -h$(<[1]:D=) -G "$(>)" "$(LIBRARIES)" -Bdynamic -l$(FINDLIBS-SA) -Bstatic -l$(FINDLIBS-ST) -B$(LINK-RUNTIME) 156: } Only if compiling with -std=c+11 or -std=c++14, I need to replace '-G' above with '-G -library=stdcpp,CrunG3' Any help on modifying this is appreciated. Thanks, Aparna

1 0

1.60 closes for major changes next Wednesday
by Vladimir Prus 27 Oct '15

27 Oct '15

1.60 is now closed for new libraries and breaking changes - please don't merge such changes for master. We'll be closed for major changes next Wednesday, Oct 28, at the end of the day. Thanks, -- Vladimir Prus http://vladimirprus.com

3 3

[vmd] Added to new release
by Edward Diener 26 Oct '15

26 Oct '15

I would like to make sure the VMD library is added to the upcoming Boost 1.60 release. Is there anything further I have to do to affect that ?

1 0

[Hana] Postponing release to 1.61.0
by Louis Dionne 24 Oct '15

24 Oct '15

Hi, Some of you might know that I have been pushing hard to deliver Hana with the next Boost release. I have even taken the (soft) engagement to do so at CppCon in last September. However, due to some time constraints, it is now clear that Hana will not be included in Boost 1.60.0, the limit for new libraries being yesterday. I hoped really hard to make it in time for Boost 1.60.0, but the closing of the release branch ~1 month before the release date got me by surprise. All in all, this is not too bad since there are still a couple issues that must be addressed, and I believe that taking more time to address them properly will be beneficial to the community in the long term. Also, while I really wanted to make Hana available to the wider community ASAP, I do not think waiting 3 more months will be very harmful. Given the current level of C++14 support in compilers, only people on Clang >= 3.5 would have been able to use Hana, and I do not think this represents such a huge amount of potential users. As a side note, given my previous announcements, some users might find it strange not to see Hana as part of 1.60.0. Hence, I wonder whether it would be possible to include a short note with a link to this message somewhere in the release notes for 1.60.0? Regards, Louis

3 4