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

[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

How to get tests running for new library
by Steven Ross 19 Jan '15

19 Jan '15

I've added the new Sort library: https://github.com/boostorg/sort How do I get automated tests running and generating results at: http://www.boost.org/development/tests/master/developer/math.html ? Also, how do I add Sort to Trac, so I can get bug reports?

5 6

[math][integer] Moving integer utilities out of the math lib.
by John Maddock 19 Jan '15

19 Jan '15

This does look to me like a good idea, but to remain coherent, all of http://www.boost.org/doc/libs/1_57_0/libs/math/doc/html/gcd_lcm.html should move, which means: common_factor.hpp common_factor_rt.hpp common_factor_ct.hpp Plus docs and tests. Further I'd like to see the headers under boost/integer/*.hpp and the namespace changed to boost::integer. For backwards compatibility the boost/math/*.hpp headers should be present also but merely include the new ones and import the symbols into boost::math via using declarations. One SNAFU I see is that boost.integer is a largely unmaintained ragbag of utilities (though often very useful). It would be nice if someone would take responsibility for this library: any takers? It might be the right time too to move the rest of Boost.Integer into boost::integer rather than dumping everything in namespace boost? And finally to provide a "soft landing" for existing users, the Math lib docs should retain a stub page for these utilities that points to the new docs - Paul and I can take care of that one. Does that look like a plan? Anyone care to take it on? Best, John.

8 18

Warning policy? local variable hides (i.e. shadows) global variable
by Beman Dawes 19 Jan '15

19 Jan '15

GCC and Clang have had a warning for years (-Wshadow): "Warn whenever a local variable or type declaration shadows another variable, parameter, type, class member (in C++), or instance variable (in Objective-C) or whenever a built-in function is shadowed. Note that in C++, the compiler warns if a local variable shadows an explicit typedef, but not if it shadows a struct/class/enum." VC++ 2015 (aka 14.0) Preview has now added a similar warning, C4459. For example, "c:\boost\modular\develop\boost\lexical_cast\detail\converter_lexical_streams.hpp(429): warning C4459: declaration of 'n' hides global declaration". The VC++ warning also provides location info so is easy to view both the declarations involved. In this case, the declaration "bool operator<<(short n)" is shadowing a variable name in the unnamed namespace of the calling translation unit. The process of clearing these shadow warnings occasionally finds bugs that are otherwise difficult to detect. Peter Dimov and I have both found bugs in our code in the process of clearing the new C4459 warning. Even though most of the warnings don't actually signify bugs, I'm finding that clearing them makes code clearer and less confusing, particularly code I haven't looked at in a long while. Should Boost have policy to clear these warnings? A lot of the warnings involve function argument names. Should we have a guideline to prevent shadow warnings? A convention for argument names would make it easier to submit pull requests. Possible guidelines: * Prefix function argument names with "a_". Rationale: The "m_" prefix for member names has been a success. * Suffix function argument names with "_". Rationale: Short and less distracting than "m_" prefix. Thoughts? --Beman

12 29