January 2015 - Boost - lists.preview.boost.org

Re: [boost] updated Boost.Test devel->master: documentation needs
by Dave Gomboc 22 Jan '15

22 Jan '15

Gennadiy Rozental <rogeeff <at> gmail.com> writes: > Dave Gomboc <dave_gomboc <at> acm.org> writes: > > > I'll volunteer to write up a section on the production use of > > Boost.Test. I will, however, need source material in order to do so. > > Hi Dave, > > Thank you for your proposal. This section is really not something, which is > a showstopper for the move. Can I interest you in something which is? Well, I have not received any source material to date, so what I had in mind isn't going to fly anyway. I'll contact you privately after Feb. 15 (I am not realistically available to contribute sooner than that). Dave

1 0

Re: [boost] [type_traits] Rewrite and dependency free version
by Dave Gomboc 22 Jan '15

22 Jan '15

On 1/15/2015 3:12PM, Edward Diener wrote: > Trying gcc-3.4.2 it has the same result as gcc-3.4.5 using master and > Version2 branches. > > Trying gcc-3.3.3 it complains: > > "cc1plus.exe: error: unrecognized option `-Wextra'" > > for every file whether using master or version2. > > Whether type_traits should compile with these old gcc-3 versions is up > to you. Older versions of gcc (including the unofficial 2.96 versions that are still being used in 2015, by the way) will accept -W, but not know about -Wextra (the newer name for -W). However, do not confuse -W with -w. I have actually been able to implement things like integral_constant directly that compile and work on gcc 2.96. The main workaround required is to split up the template specialization into two lines: create an int const some_name = <some compile-time calculable value>, then perform the template specialization on a second line of code using ... ::value = some_name. So, supporting gcc 3.x should be a breeze. ;-) Dave

1 0

[config] defining __has_extension in suffix.hpp?
by Peter Dimov 22 Jan '15

22 Jan '15

It's useful to have #ifndef __has_feature #define __has_feature(x) 0 #endif #ifndef __has_extension #define __has_extension __has_feature #endif in suffix.hpp so that one can then use __has_extension(foo) everywhere without fear. Otherwise, even #if defined(__clang__) && defined(__has_extension) && __has_extension(foo) is a preprocessor error when __has_extension is not defined (which it isn't when not on Clang.)

4 4

[regression] master regression results do not show up
by Andrzej Krzemienski 22 Jan '15

22 Jan '15

Just try it: http://www.boost.org/development/tests/master/developer/summary.html Regards, &rzej

2 1

[config] <atomic> disabled on clang-3.6?
by Peter Dimov 22 Jan '15

22 Jan '15

libstdcpp3.hpp contains: #if defined(__clang_major__) && ((__clang_major__ < 3) || ((__clang_major__ == 3) && (__clang_minor__ < 7))) // As of clang-3.6, libstdc++ header <atomic> throws up errors with clang: # define BOOST_NO_CXX11_HDR_ATOMIC #endif but in the sibling thread about issues with clang-3.6 and thread sanitizer, SmartPtr has been reported to work with -DBOOST_SP_USE_STD_ATOMIC, which uses <atomic>. The reported g++ version is 4.9.2: g++ (Ubuntu 4.9.2-0ubuntu1~14.04) 4.9.2 and Clang is: Ubuntu clang version 3.6.0-svn225356-1~exp1 (trunk) (based on LLVM 3.6.0)

1 0

[type_traits][general] Best practice for inline namespaces?
by John Maddock 21 Jan '15

21 Jan '15

I was thinking of adding inline namespace support (ie lib versioning) to type_traits, but what's the best practice for naming the inline namespace? I was thinking of going with some mangled version of BOOST_VERSION which would effectively change the namespace with each release. That feels like it's probably right to me: old versions of any traits would then be archived in boost::tt105600:: or whatever version the change happened. Comments? Thanks, John.

9 12

[compute] Some remarks
by Thomas Heller 21 Jan '15

21 Jan '15

Hey list, These are just a few remarks I wanted to share that I made during the compute review phase. Unfortunately, I don't have the time to write a full review. As I mostly skimmed over everything so take it with a grain of salt. First of all, I really like the general idea of Boost.Compute. That is, I like the idea of having a proper API for OpenCL capable devices and I like the idea of having parallel algorithms. With that being said, i think it is a waste of opportunities to have the two tied together so closely especially considering N4104 with the combination of different execution policies which would allow for a wonderful API for using different parallelization backends (where boost.compute could be the reference implementation or some such). Additionally, I think that the author and other reviewers are running in circles when it comes to synchronization. IMHO, the event alone is enough and perfectly fine. An OpenCL event has interesting similarities to std::future<void>, and the clEnqueue functions to std::async. I'd consider the command queue however similar to std::thread (and threads should be considered harmful...). With that being said, a event should be perfectly fine to express synchronization points. Together with executors, it would even fit into the more higher level stdlib parallel algorithms. It would be very nice to get rid of a publicly exposed event class though and have one future to rule them all (one can dream...). But having a future and event in Boost.compute is, IMHO, not a good idea. Cheers, Thomas

15 70

[Boost.DI] Formal review request
by Krzysztof Jusiak 20 Jan '15

20 Jan '15

Dear Boost, I'd like to request a formal review of Boost.DI. Description: Boost.DI is C++14 header only, type safe library providing compile time, macro free constructor dependency injection. - Reduces boilerplate code - Reduces cost of maintenance effort - Reduces testing effort - Gives better control of what and how is created - Gives better understanding about objects hierarchy Source Code: https://github.com/krzysztof-jusiak/di Documentation: http://krzysztof-jusiak.github.io/di/boost/libs/di/doc/html Boost Library Incubator: http://rrsd.com/blincubator.com/bi_library/di-dependency-injection/?gform_p… Interest: http://lists.boost.org/Archives/boost/2014/07/215487.php Thanks, Kris

2 2

Clang 3.4 failing to compile boost 1.57 headers
by Robert Dailey 19 Jan '15

19 Jan '15

I'm including <boost/format.hpp> and getting this error from Clang 3.4 on Ubuntu 12: In file included from /home/fe/frontend/Core/ThirdParty/boost/include/boost/format.hpp:38: In file included from /home/fe/frontend/Core/ThirdParty/boost/include/boost/format/internals.hpp:23: In file included from /home/fe/frontend/Core/ThirdParty/boost/include/boost/format/alt_sstream.hpp:21: In file included from /home/fe/frontend/Core/ThirdParty/boost/include/boost/shared_ptr.hpp:17: In file included from /home/fe/frontend/Core/ThirdParty/boost/include/boost/smart_ptr/shared_ptr.hpp:28: In file included from /home/fe/frontend/Core/ThirdParty/boost/include/boost/smart_ptr/detail/shared_count.hpp:30: /home/fe/frontend/Core/ThirdParty/boost/include/boost/smart_ptr/detail/sp_counted_impl.hpp:229:31: error: no type named 'allocator_traits' in namespace 'std' typedef typename std::allocator_traits<A>::template rebind_alloc< this_type > A2; ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~ Is this a bug or am I missing something? I'm using -std=C++11 flag.

6 20

Testing and toolsets
by Andrzej Krzemienski 19 Jan '15

19 Jan '15

Hi Everyone, Could anyone give me some information on how regression test matrix is supposed to work? I can see that when testers run their tests they specify a toolset; this toolset is reported in test matrix, and based on this toolset name failures in tests can be labeled as expected. Did I get it right? However, the fact that a tester turns C++11 support or not, is not necessarily reflected in the toolset name (some testers indicate it in the toolset name, others don't). On the other hand C++11 being turned on or off can affect the test results. In that case the toolset name alone is not sufficient to make a decision whether I expect a failure or not. Is there some policy for addressing this problem? Am I the only person to be affected? Regards, &rzej

8 13