July 2017 - Boost - lists.preview.boost.org

Re: [boost] Boost tests with cmake
by Rene Rivera 29 Jul '17

29 Jul '17

Accidentally replied to the wrong target.. Putting it back on dev list.. On Fri, Jul 28, 2017 at 11:27 PM, P F <pfultz2(a)yahoo.com> wrote: > > On Jul 28, 2017, at 11:22 PM, Rene Rivera <grafikrobot(a)gmail.com> wrote: > > On Fri, Jul 28, 2017 at 11:01 PM, P F <pfultz2(a)yahoo.com> wrote: > >> >> > On Jul 28, 2017, at 7:25 PM, Rene Rivera via Boost < >> boost(a)lists.boost.org> wrote: >> > >> > The predef script is incorrect. This < >> > https://github.com/pfultz2/boost-cmake-demo/blob/bcm-test- >> demo/libs/predef/test/CMakeLists.txt#L25> >> > is not equivalent to the original < >> > https://github.com/pfultz2/boost-cmake-demo/blob/bcm-test- >> demo/libs/predef/test/build.jam#L60>. >> > As the "-DCHECK_VALUE=true" is not passed to compiler in response to the >> > evaluation of '"BOOST_COMP_CLANG > 0.0.0" "BOOST_OS_LINUX == 0"'. It >> needs >> > to try to compile and run one of the programs from here < >> > https://github.com/pfultz2/boost-cmake-demo/tree/bcm-test- >> demo/libs/predef/tools/check>. >> > The test is verifying that both this < >> > https://github.com/pfultz2/boost-cmake-demo/blob/bcm-test- >> demo/libs/predef/tools/check/predef.jam> >> > and this < >> > https://github.com/pfultz2/boost-cmake-demo/blob/bcm-test- >> demo/libs/predef/tools/check/predef_check.h> >> > work as expected. For cmake you would need still need to test the >> latter, >> > still. >> >> Yes, I need to add a custom function `predef_check` in cmake to support >> this, > > > Right. > > >> although it would be best to do the detection directly in cmake rather >> than through the running the tool > > > Not sure what you mean by that. > > > Because when cross compiling you can’t always run the executable, and > using a host compiler seems it would be give different results than the > target compiler. However, a preprocessor expression can be evaluated > through cmake’s try compile, which will safely work with cross compiling. > Perhaps this is what bjam’s rule does already. > Sorry.. I misspoke. They are compile checks, not run checks. If the compile succeeds (of one of the "predef_check_cc_as_*.*") it needs to add the "-DCHECK_VALUE=true" to the compile and run of "check_value.cpp". But the test data in this case would also need to change if you are going to use a try-compile target. As the b2 code parses out those strings and reformulates them as a -DCHECK=.. compile option. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[concurrent] Fast, lock-based queue implementation
by David Stone 29 Jul '17

29 Jul '17

I have written a new concurrent queue that has a focus on high throughput. You can check it out here: https://github.com/davidstone/concurrent-queue Some highlights of this queue: * The bulk interface is faster than other queues for many common load patterns * Almost any element type is supported with very few requirements * Supports any number of producers * Supports any number of consumers (although it works best with only one) * Can dynamically grow and shrink in memory as needed * The interface allows for very little undefined behavior: for the most part, as long as your special member functions like move constructors do not reference the queue you are inserting into, you are fine * Interface based on the pattern of moving values in and returning values via return, rather than other queues which use reference output parameters * Header-only * Design should be fairly straightforward to verify for correctness * Compiles warning free with a very high warning level on gcc and clang * Does not have any errors under ubsan, asan, or tsan I would like to submit this for inclusion in Boost if people find it interesting and useful, but first I would like to get some feedback on the design, implementation, documentation, tests, etc. I have tested this exact version on Gentoo Linux under clang 4.0 and gcc 6.3.0. I will be testing out Visual Studio 2015 and 2017 in the near future to ensure there have not been any regressions. I have run fundamentally the same queue on Visual Studio 2012 (no longer supported due to C++14 features), Visual Studio 2015 (Windows Server 2008 R2, Windows Server 2012), gcc 4.9.1 (Red Hat 6 under developer toolset 3), gcc 4.9.2 (Red Hat 7), and clang 3.9.0 (Red Hat 7) for several years now with no issues, so it is a fairly mature design.

2 4

Documentation snapshot not cycling
by Joaquin M López Muñoz 28 Jul '17

28 Jul '17

Hi, Looks like the documentation snapshot for develop http://www.boost.org/doc/libs/develop/ was last updated five days ago. Any chance this can be given a rebuild? Thank you, Joaquín M López Muñoz

3 3

[optional] Suggestion for adding an optional_number class
by Viktor Sehr 28 Jul '17

28 Jul '17

I'd like to make a suggestion for adding an optional class for number types, called optional_number, where the max value of the number type is utilized as the uninitalized value. Differences compared to std::optional<int, float, enum etc>: *- No size overhead from the wrapped type* - Theoretically faster (althrough in practice probably negilble) - Can be assigned to any value except the max value - Operator-> is removed as it does not make sense for an integer Notes: - Throws if assigned the numeric_limits<T>::max - Also works with enums, using the underlying_type - The operator bool conversion is missing in the prototype implementation Attaching a prototype implementation (currently for C++14). /Viktor

5 8

Proposal for moving Boost to CMake
by David Sankel 27 Jul '17

27 Jul '17

Howdy all, This is a request for comments on a possible path for migrating Boost's build system to CMake. I am not speaking for the Boost Program Committee here, but I plan on bringing this up with them after getting feedback. The motivation is simple. CMake is currently the dominant player in the area of open-source, cross-platform, C++ build-systems. I make this claim based on Google trends graphs and discussions with others at the conferences I attend (CppCon, C++Now, and ISO C++ meetings). If we make Boost buildable and usable out-of-the-box with CMake, we would significantly lower the barriers to entry for both Boost users and new Boost developers. Boost serves the greater C++ community and making Boost more accessible would be of great utility. * To ease the migration path, both Boost.Build (the current jam-based build system) and CMake will be supported for a time. * Boost sources would provide a compatible, drop-in replacement for the 'FindBoost' module that is distributed with CMake. A CMake-based application could point to it and, instead of using the system Boost libraries, Boost targets would be built from source as part of the user build. * The built Boost **binaries** would also provide a compatible, drop-in replacement for the 'FindBoost' module distributed with CMake. The behavior is similar to the previous bullet, except the built binaries would be used instead of the source code. * The style of the 'CMakeLists.txt' files would follow current best practice. We'd resist the temptation to write macros which replace the core CMake functions. There would be repetition in the files, to be sure, but I think we should avoid attempting to innovate CMake. I've seen this fail on many occasions and would like to keep our goal focused, at this point, on migrating Boost to CMake. In the future we could revisit this. * There would be a list of CMake guidelines that we'd use. * Boost libraries should be buildable in isolation and use 'find_package(Boost...)' to discover their Boost dependencies. * We would work with CMake towards eventually taking over maintenance of the FindBoost module distributed with CMake. I see this progressing with several milestones. 1. Release of a CMake-buildable Boost and the CMake conventions. In this stage each Boost library can be built in isolation or with the entire distribution and all the 'FindBoost' functionality mentioned above would be incorporated. 2. The unit tests for all Boost libraries are incorporated into CTest (the CMake unit test orchestration tools). 3. The Boost infrastructure is modified to use CTest for unit testing. 4. Unit testing functionality is removed from Boost.Build. 5. Boost.Build is removed. Although there are many other great ideas floating around (e.g. modularization of Boost, Boost-Classic, and Boost2), I'd like to keep this focused on CMakification of Boost because I think it is something that would have big impact and is small enough to be doable. One question that is going to come up is "who is going to do all this work?". Once we decide on a direction, I don't foresee a problem making this happen. Between volunteers, the importance this project has for companies, and the Steering Committee reserves, we should have the resources necessary. Another concern is that some authors may resist. Authors have a lot of leeway when it comes to how they maintain their libraries, what conventions they use, and backwards compatibility concerns. However, there are some things that authors need to conform to, such as our current Boost.Build build and testing infrastructure. I liken this to the development of a city: building developers can make their buildings however they want, but the streets, which control transit between buildings, are centrally regulated. Thanks for your consideration. -- David Sankel

29 140

PGI C++ compiler support
by David Olsen 27 Jul '17

27 Jul '17

Many years ago, Boost was configured to work well with the PGI C++ compiler (http://www.pgroup.com/) But maintenance of the PGI support within Boost stopped about five years ago, and PGI will no longer build Boost without modifications to the Boost sources. I am working on restoring support for the PGI C++ compiler. Many PGI customers want to use Boost, so we at PGI are putting in the effort to make that easy to do. I have already fixed a bunch of bugs in the PGI compiler that were triggered by Boost code. Now it is time to make necessary adjustments to the Boost source. I have created six pull requests that make it possible to build Boost with PGI. https://github.com/boostorg/build/pull/218 https://github.com/boostorg/filesystem/pull/49 https://github.com/boostorg/mpl/pull/30 https://github.com/boostorg/spirit/pull/236 https://github.com/boostorg/type_traits/pull/45 https://github.com/boostorg/config/pull/169 The only big change is overhauling the pgi.jam file. The other changes are just removing an obsolete #if or changing an #if expression. None of the changes should affect any compiler other than PGI. Next I am planning to make any necessary changes to test code and to header-only libraries so that PGI gets decent results when running the Boost tests. Then I will look into setting up a test bot for the PGI compiler here at PGI. -- David Olsen (dolsen(a)nvidia.com) NVIDIA - PGI Beaverton, Oregon

5 6

[type_erasure] link to any_cast reference section
by Joaquin M López Muñoz 27 Jul '17

27 Jul '17

Hi, Unlike most classes/functions in Boost.TypeErasure, the following http://www.boost.org/doc/html/boost/type_erasure/any_cast.html does not go to the reference for boost::type_erasure::any_cast, the proper link being http://www.boost.org/doc/html/boost/type_erasure/any_cast_idp758556752.html Problem is this seemingly autogenerated file name is unstable. For instance, for Boost 1.63 the link was http://www.boost.org/doc/libs/1_63_0/doc/html/boost/type_erasure/any_cast_i… in develop it is http://www.boost.org/doc/libs/develop/doc/html/boost/type_erasure/any_cast_… and in master it is http://www.boost.org/doc/libs/master/doc/html/boost/type_erasure/any_cast_i… which makes it impossible to refer to this section of Boost.TypeErasure documentation from other pages. Maybe this can be fixed? Thank you Joaquín M López Muñoz

2 5

[review][mp11] Formal review of Mp11
by Bjorn Reese 27 Jul '17

27 Jul '17

The formal review of Peter Dimov's Mp11 library is scheduled for July 15 - July 24, 2017 [1]. Mp11 is a C++11 metaprogramming library for compile-time manipulation of data structures that contain types. It’s based on template aliases and variadic templates and implements the approach outlined in the article "Simple C++ metaprogramming" [2] and its sequel [3]. These articles are useful background information for the review. * Mp11 aims to make simple usage simple, and to support complex usage without complicating the simple use cases. * Mp11 works on any type-list, whether its own type-list mp_list, or standard type-lists such as std::tuple and std::variant, or user-defined type-lists. * Mp11 works with any meta-function, such as C++11 or Boost type-traits, or user-defined type-traits. Mp11 can be found here: * Documentation: https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html * Source code: https://github.com/pdimov/mp11/tree/master Please answer the following questions in your review [4]: 1. Should Mp11 be accepted into Boost? Please state all conditions for acceptance explicity. 2. What is your evaluation of the design? 3. What is your evaluation of the implementation? 4. What is your evaluation of the documentation? 5. What is your evaluation of the potential usefulness of the library? 6. Did you try to use the library? With what compiler? Did you have any problems? 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 8. Are you knowledgeable about the problem domain? [1] http://www.boost.org/community/review_schedule.html [2] http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [3] http://pdimov.com/cpp2/simple_cxx11_metaprogramming_2.html [4] http://www.boost.org/community/reviews.html

18 56

[Signals2] library fails to compile with -fno-exceptions
by Jackie Kay 26 Jul '17

26 Jul '17

The signals2 Git repo does not have issues enabled, so I thought I'd ping the list about this. Trying to compile any program that includes boost/signals2 with -fno-exceptions fails as of 1.64: #include <boost/signals2.hpp> // boost/signals2/slot.hpp will also reproduce the error int main() { } g++ prog.cc -I<path to Boost 1.64.0 headers> -std=c++11 -fno-exceptions View it on Wandbox: https://wandbox.org/permlink/vZVpF5bb8E9K7sDz I was also able to reproduce this locally on the develop branch. It appears this is because the slot_base lock function is not defined when exceptions are disabled, but this is not checked when it lock is called in `slot_template.hpp`. I am working on a fix, but I would like to know what the path moving forward for the fix would be. Signals2 is currently unusable in 1.64 with exceptions turned off.

1 0

Separate Boost CMake mailing list
by Edward Diener 25 Jul '17

25 Jul '17

I think that a separate Boost CMake mailing list would be beneficial, rather than have all the discussion about the move to CMake, as the default Boost build system, as well as further uses of CMake with Boost libraries and tools, on the developers mailing list. This is similar to the way that Boost currently has a separate mailing list for Boost Build.

5 8