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

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

CMake Announcement from Boost Steering Committee
by Jon Kalb 28 Jul '17

28 Jul '17

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 199

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

Mp11 review
by paul 25 Jul '17

25 Jul '17

Hi, this is my review of mp11. Please answer the following questions in your review [4]: > 1. Should Mp11 be accepted into Boost? Please state all conditions > for acceptance explicity. Yes Mp11 should be Accepted. > > 2. What is your evaluation of the design? Very good design overall. I don't know if I really like the `mp_` prefix. Trailing underscores is common in boost, but the mp prefix makes sense for standardization. It uses the `std::integral_constant`, but it might be nice to use another implementation, as that can help make it consistent between C++11 and C++14. Also, providing an integral constant with operators could help improve interoperability with hana-style metaprogramming(which also help interoperate with the Fit library as well). Of course, I don't know if mp11 is right place for it. It seems it would be better to have a separate library for this and the other C+14 features as well. Also why is `mp_with_index` only constexpr on C++14 and higher? > > 3. What is your evaluation of the implementation? The implementation seems to be good and provides competive performance with other metaprogramming libraries, but I do wonder if some of Odin's metaprogramming techniques(such as recursive aliases) can be used to improve the performance as well. > > 4. What is your evaluation of the documentation? Very well documented and organized. > > 5. What is your evaluation of the potential usefulness of the library? I think this library can be very useful for C++11 metaprogramming where I have needed. I don't think it would be as useful for the Fit and Tick library because they still target gcc 4.6, which mp11 doesn't support due to being based around template aliases. > > 6. Did you try to use the library? With what compiler? Did you have > any problems? Yes, I did, and also ran the tests. I tried to run the tests on some configurations that aren't ran in the travis CI(like clang 3.5 with C++14). And all the tests do pass. > > 7. How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? I spent a couple hours reviewing, and I have implement ad-hoc versions of these in my own libraries as well. Paul

1 0