- Boost - lists.boost.org

Best boost documentation
by Damian Vicino 23 Jan '15

23 Jan '15

Hi, I’m preparing a library to be proposed and I’m adapting the documentation I had to be more Boost-like. I saw there is different writing styles in the documentation. Something I’m specially interested is in the document structure, I saw some start with a tutorial, others with an overview of the concepts, others just go straight to the internals. I’m wondering if there is a preferred style or document structure to use. Best regards, Damian

3 2

[config] [regression] Regression test failures due to compiler bugs -- your advice needed
by Andrzej Krzemienski 23 Jan '15

23 Jan '15

Hi Everyone, I need the advice from the experts, on what is the recommended way to handle the following situation with regression tests. A number of tests of Boost.Optional fail. (see here: http://www.boost.org/development/tests/develop/developer/optional.html) These are the failures in optional<T&> (optional references), because quite a lot of compilers implement reference binding in a non-standard-conforming manner. (For details of these bugs see here: http://www.boost.org/doc/libs/develop/libs/optional/doc/html/boost_optional… ). The question is, how these testing failures should be reflected in regression testing configuration, so that they do not appear as bugs in the implementation of Boost.Optional? 1. I hear that marking explicit failures is not recommended, and build config based on Boost.Config should be preferred. Also, the markup will not work because from the toolset name alone I cannot make the decision whether to mark the explicit failure or not. 2. On the other hand, I hear that Boost.config should not be used to detect any bug in a compiler that is relevant only to a single Boost library. These two pieces of advice appear contradictory in my case. I would like to abide to the recommendations in Boost, but in this case it appears that I am stuck. Is there any recommendation in such case for Boost developers? Regards, &rzej

5 14

Boost.Sort - new library documentation
by Paul A. Bristow 23 Jan '15

23 Jan '15

Is there anything more that should be done to ensure that Boost.Sort new library documentation is added to the build system. It uses Quickbook, Doxygen and Autoindex. So does anything need adding to modular-boost\doc\Jamfile.v2 ? Perhaps, if I have understood this comment correctly: # Note that when refering to libraries that use auto-index we must process all the way to # docbook before including here. We must also ensure that auto-index uses it's own index # generation, otherwise we get one big index that's repeated in each library. Xslt's index # generation is also so slow that it's impractical for a build this large (takes ~ 9 hrs # to build with just 3 indexed libraries). Hence we refer to these libraries as for example: # # ../libs/interprocess/doc//standalone/<format>docbook then this needs adding ## Build the various generated docs (Doxygen and QuickBook)... <dependency>../libs/sort/doc//standalone/<format>docbook ## Add path references to the QuickBook generated docs... <implicit-dependency>../libs/sort/doc//standalone/<format>docbook but I am not clear if this is right, so I am not providing a pull request. I'm also unclear who should/will do this. Thanks Paul PS I suspect that I will also need this for Boost.Integer update soon. --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

3 3

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