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

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

[review][mp11] Reminder of ongoing formal review
by Bjorn Reese 25 Jul '17

25 Jul '17

The formal review of Mp11 continues until (and including) Monday, July 24th. There have been four formal reviews so far. I would like to ask the Boost community for two favours: 1. Please postpone the discussions about CMake and the future directions of Boost until the formal review has ended. 2. Please review the Mp11 library instead. If you disagree with any of the above, please contact me off-list. Here is the call for review once more: 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

7 12

[review][mp11] Review of Mp11 has ended
by Bjorn Reese 25 Jul '17

25 Jul '17

The review of Mp11 has ended with a total of 12 formal reviews (and one pending.) I would like to thank all who have participated in the review, as well as those who agreed to postpone CMake discussions until the end of the review. The review report will be posted in the near future.

1 0

[config] What Feature is this??
by John Maddock 25 Jul '17

25 Jul '17

Folks, I think I'm looking to add a new C++11 defect macro, but don't know what the feature is called, nor can I see a way of detecting it with clang's __has_feature function. The code I want to enable involves function overloading based on a decltype return type as in: auto integrate(args...) -> decltype(expression1); auto integrate(args...) -> decltype(expression2); where expression1 and expression2 are two mutually exclusive options (the conceptual requirements of args means that only one of these 2 will ever be satisfied). This works fine in msvc-14 and later and gcc-4.8 and later, but I don't see any current config macros which cover this case, nor can I figure out what this trick should be called. Alternatively, if anyone has a better way of differentiating between unary and binary functions I'm happy to hear about it ;) Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

6 13

[review][mp11] Formal review of Mp11
by Glen Fernandes 25 Jul '17

25 Jul '17

What follows is my review of the Mp11 library: [Should the library be accepted into Boost?] Yes. I vote for an unconditional ACCEPT. [What is your evaluation of the design?] Excellent. The design where any template can serve as a list, and any template can serve as a meta-function is both elegant and powerful. The additional quoted meta-function support with utilities such as mp_bind, mp_bind_front, and mp_bind_back, addresses the other request I had when reviewing an earlier version of Mp11. While HOMF were never essential, as the article pointed out, users appreciate more ways to one-line things without having to write a helper type. Some additional primitives are desired, as mentioned later in this review (e.g. min and max functionality) but overall the toolkit is already vast and useful. [What is your evaluation of the implementation? Excellent. The focus on performance is definitely appreciated while we still have to depend on libraries for many of these meta-programming primitives. Ideally many of these would be provided in the standard library and have implementations that only a compiler vendor could provide with built in support, and offer performance beyond what a library could offer. In the meanwhile, the performance offered by Mp11 is great, more than sufficient for my needs, and in my opinion also for the majority of users. In comparison, the tiny C++11 meta-programming library that I have implemented, uses only the obvious C++11 implementations for most functionality, and does not offer the same fast compile times as the equivalents in Mp11. The techniques used by Mp11 via C++11 constexpr, C++14 constexpr, and even C++17 fold expressions, besides improving Mp11 performance, were a valuable source to learn from. Suggestion: Can all the workarounds for MSVC versions 1800 and older for the empty list cases be avoided by instead using a helper trait? i.e. template<template<class...> class L, class... T, template<class...> class P> struct mp_find_if_impl<L<T...>, P> { using type = typename mp_find_if_impl_2<P, T...>::type; }; i.e. Introduce mp_find_if_impl_2 which would then have the obvious implementation as before, only without requiring the MSVC workaround? This is only worth considering if you find it to offer some benefit such as: Additional maintainability of the Mp11 code, with less workarounds, and no costs, e.g. no increase in compilation times as a consequence. [What is your evaluation of the documentation? Very good. The reference documentation is clear, and easily understood. More example and tutorial content before the reference section would always be welcome, but not necessary. Suggestion: The two-part article that Peter wrote (which is referenced in the documentation) is in my opinion so valuable for users to gain better understanding and appreciation of the library that it should be included in the library distribution as part of the documentation. Ideally in the same Asciidoc form as the current documentation, as a supplemental document (or Appendix entry). Suggestion: Does it make sense for the documentation to have a section describing the conventions the library uses, for potential contributors as much as users? e.g. If someone was designing an mp_min_element, should it yield the element type result, or the list index size constant result? Is there an established convention of when an error is acceptable for an empty list versus returning an index? Correction: Under heading mp_find_if<L, P>: "mp_find_f<L, P> is an" should be "mp_find_if<L, P> is an". [What is your evaluation of the potential usefulness of the library? Incredibly useful in its current form, and this is only going to increase as the library is extended based on user requests for additional functionality. Almost every meta-programming primitive that I have needed recently either already exists in Mp11, or I am able to implement using Mp11 with a little effort. During this review I replaced the use of my own meta-programming library in a project of mine without any issues. As part of this review I also tried several exercises where I implemented certain traits and meta-functions using Mp11. Of all the exercises that I attempted, the only one where the library lacked the necessary utility was an "mp_min_element" function: This was an implementation of the typical "type_with_alignment" trait, which can easily be implemented using a "min_element" functionality. Mp11 does not have mp_min, mp_max, mp_min_element, mp_max_element presently, and I believe they should be added because they are useful and users will probably find themselves implementing it. Sure, mp_sort exists, but I would not use a sort when a min_element can suffice. In this case, type_with_alignment<N> could use mp_min_element with a predicate that finds the type in an mp_list of several scalar types, that matches has an alignment of at least N and has the smallest size, and then check that the result element type of the mp_min_element is at least N. The litmus test for me for a meta-programming library is the question: Would I use Mp11 in library code? The answer for me is "yes". If it was part of Boost, I would use it in other Boost libraries (that already require C++11 or higher). [Did you try to use the library? With which compiler(s)? Did you have any problems?] Yes. I used the library as a replacement for an existing meta-programming library of mine in real (non-toy, non-exercise) project code that is compiled with g++ 4.8.5 in c++11 mode for x86 and x86_64 Linux, using Boost 1.64.0, on 64-bit RHEL 6 and measured compilation times. I also used the library in a few exercises that I compiled with g++ 7.1 and clang 4.0.0, for x86 and x86_64 Linux, using the current Boost master branch, for c++11 and c++14, on 64-bit Fedora 26, and again measured compilation times. I also compiled and ran the Mp11 unit tests with the compilers, C++ standard modes, architectures, Boost distributions, and operating systems mentioned. [How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?] More than ten hours over this weekend reading the documentation, reviewing the implementation and tests, using Mp11 in a project replacing my own C++11 meta-programming library, using it in various exercises, and running the Mp11 unit tests with the various compilers, C++ standard modes, targets, and Boost distributions listed above. Prior to the preparation for the review, I had spent some time with an earlier version of Mp11 and comparing it to Metal for implementing a few meta-functions, including the "instantiates_" example from my library: instantiates_<T, templates_<std::set, std::multiset, std::unordered_set> > Where instantiates_ should be implemented in terms of "is_instantiation_of_": is_instantiation_of_<T, std::set> Which has the obvious behavior indicated by the trait name. The Mp11 approach provided by Peter for this case, and the relative ease with which I was able to implement the other meta-functions using Mp11 were a convincing demonstration of the usefulness of the library. [Are you knowledgeable about the problem domain?] Like many of us, I had written a meta-programming library as C++11 language features have become available. Before that, if Boost.MPL solved a problem, more often than not it was convenient and useful enough to just use it, even if writing my own implementation would result in faster compilation times. Peter's article, however, opened my eyes to a more elegant design, and changed how I implemented my C++11 meta-programming library, and in general shaped what I think about meta-programming in modern C++. Thank you Peter for your work on Mp11, for submitting it for inclusion in Boost, and for the articles that motivated it and taught the rest of us. Glen

6 5

[BB++] Now fixes all of your memory leak nightmares
by Phil Bouchard 24 Jul '17

24 Jul '17

Greetings, Now I have an example showing off the cyclic reference handling. Please see: https://github.com/philippeb8/root_ptr/blob/bb++/bbpp2cpp/tests/input2.bb This program correctly outputs: Document::Document(const boost::node_proxy&) auto __0(boost::node_proxy&, int) 1 Document::Document(const boost::node_proxy&) Document::~Document() 2 Document::~Document() So I just came to realize we could use this tool to parse entire projects to generate the right C++ code, after having disabled the 'operator delete', and then run the executable, which still is 3.5x faster than Node.JS. For the newcomer please see: https://github.com/philippeb8/root_ptr/tree/bb++/bbpp2cpp I am going to present this to NASA and company. Meanwhile anybody is welcome to help me out extending the parser to support template syntaxes. Regards, -Phil http://bbplusplus.com/

4 6

[asio] windows service async server crashes after running for a while; though it works fine from console
by Kyoryu Kurayami 24 Jul '17

24 Jul '17

I have an existing console async server that I converted to a windows service. After running for a while (about 1-2 hours), the service would eventually crash caused by stack overflow on different parts of the code (been trying different approach on the code that causes the stack overflow exception but to no avail as it would still crash on a different location) Now, I have been wondering if an async server approach is really suitable for a windows server or should I then opt to convert it to synchronous instead. I used the combination of *io_service::reset()* and* io_service::run() *to block the current code as I've read somewhere that thread running the *io_service::run()* shouldn't immediately exit if it is running as a windows service. Do note that my previous implementation was just calling the *io_service::run() *on another thread, but this doesn't seem to work as per the explanation and solution mentioned above.

2 1

[review][mp11] Review of Mp11
by Glen Fernandes 23 Jul '17

23 Jul '17

What follows is my review of the Mp11 library: [Should the library be accepted into Boost?] Yes. I vote for an unconditional ACCEPT. [What is your evaluation of the design?] Excellent. The design where any template can serve as a list, and any template can serve as a meta-function is both elegant and powerful. The additional quoted meta-function support with utilities such as mp_bind, mp_bind_front, and mp_bind_back, addresses the other request I had when reviewing an earlier version of Mp11. While HOMF were never essential, as the article pointed out, users appreciate more ways to one-line things without having to write a helper type. Some additional primitives are desired, as mentioned later in this review (e.g. min and max functionality) but overall the toolkit is already vast and useful. [What is your evaluation of the implementation? Excellent. The focus on performance is definitely appreciated while we still have to depend on libraries for many of these meta-programming primitives. Ideally many of these would be provided in the standard library and have implementations that only a compiler vendor could provide with built in support, and offer performance beyond what a library could offer. In the meanwhile, the performance offered by Mp11 is great, more than sufficient for my needs, and in my opinion also for the majority of users. In comparison, the tiny C++11 meta-programming library that I have implemented, uses only the obvious C++11 implementations for most functionality, and does not offer the same fast compile times as the equivalents in Mp11. The techniques used by Mp11 via C++11 constexpr, C++14 constexpr, and even C++17 fold expressions, besides improving Mp11 performance, were a valuable source to learn from. Suggestion: Can all the workarounds for MSVC versions 1800 and older for the empty list cases be avoided by instead using a helper trait? i.e. template<template<class...> class L, class... T, template<class...> class P> struct mp_find_if_impl<L<T...>, P> { using type = typename mp_find_if_impl_2<P, T...>::type; }; i.e. Introduce mp_find_if_impl_2 which would then have the obvious implementation as before, only without requiring the MSVC workaround? This is only worth considering if you find it to offer some benefit such as: Additional maintainability of the Mp11 code, with less workarounds, and no costs, e.g. no increase in compilation times as a consequence. [What is your evaluation of the documentation? Very good. The reference documentation is clear, and easily understood. More example and tutorial content before the reference section would always be welcome, but not necessary. Suggestion: The two-part article that Peter wrote (which is referenced in the documentation) is in my opinion so valuable for users to gain better understanding and appreciation of the library that it should be included in the library distribution as part of the documentation. Ideally in the same Asciidoc form as the current documentation, as a supplemental document (or Appendix entry). Suggestion: Does it make sense for the documentation to have a section describing the conventions the library uses, for potential contributors as much as users? e.g. If someone was designing an mp_min_element, should it yield the element type result, or the list index size constant result? Is there an established convention of when an error is acceptable for an empty list versus returning an index? Correction: Under heading mp_find_if<L, P>: "mp_find_f<L, P> is an" should be "mp_find_if<L, P> is an". [What is your evaluation of the potential usefulness of the library? Incredibly useful in its current form, and this is only going to increase as the library is extended based on user requests for additional functionality. Almost every meta-programming primitive that I have needed recently either already exists in Mp11, or I am able to implement using Mp11 with a little effort. During this review I replaced the use of my own meta-programming library in a project of mine without any issues. As part of this review I also tried several exercises where I implemented certain traits and meta-functions using Mp11. Of all the exercises that I attempted, the only one where the library lacked the necessary utility was an "mp_min_element" function: This was an implementation of the typical "type_with_alignment" trait, which can easily be implemented using a "min_element" functionality. Mp11 does not have mp_min, mp_max, mp_min_element, mp_max_element presently, and I believe they should be added because they are useful and users will probably find themselves implementing it. Sure, mp_sort exists, but I would not use a sort when a min_element can suffice. In this case, type_with_alignment<N> could use mp_min_element with a predicate that finds the type in an mp_list of several scalar types, that matches has an alignment of at least N and has the smallest size, and then check that the result element type of the mp_min_element is at least N. The litmus test for me for a meta-programming library is the question: Would I use Mp11 in library code? The answer for me is "yes". If it was part of Boost, I would use it in other Boost libraries (that already require C++11 or higher). [Did you try to use the library? With which compiler(s)? Did you have any problems?] Yes. I used the library as a replacement for an existing meta-programming library of mine in real (non-toy, non-exercise) project code that is compiled with g++ 4.8.5 in c++11 mode for x86 and x86_64 Linux, using Boost 1.64.0, on 64-bit RHEL 6 and measured compilation times. I also used the library in a few exercises that I compiled with g++ 7.1 and clang 4.0.0, for x86 and x86_64 Linux, using the current Boost master branch, for c++11 and c++14, on 64-bit Fedora 26, and again measured compilation times. I also compiled and ran the Mp11 unit tests with the compilers, C++ standard modes, architectures, Boost distributions, and operating systems mentioned. [How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?] More than ten hours over this weekend reading the documentation, reviewing the implementation and tests, using Mp11 in a project replacing my own C++11 meta-programming library, using it in various exercises, and running the Mp11 unit tests with the various compilers, C++ standard modes, targets, and Boost distributions listed above. Prior to the preparation for the review, I had spent some time with an earlier version of Mp11 and comparing it to Metal for implementing a few meta-functions, including the "instantiates_" example from my library: instantiates_<T, templates_<std::set, std::multiset, std::unordered_set> > Where instantiates_ should be implemented in terms of "is_instantiation_of_": is_instantiation_of_<T, std::set> Which has the obvious behavior indicated by the trait name. The Mp11 approach provided by Peter for this case, and the relative ease with which I was able to implement the other meta-functions using Mp11 were a convincing demonstration of the usefulness of the library. [Are you knowledgeable about the problem domain?] Like many of us, I had written a meta-programming library as C++11 language features have become available. Before that, if Boost.MPL solved a problem, more often than not it was convenient and useful enough to just use it, even if writing my own implementation would result in faster compilation times. Peter's article, however, opened my eyes to a more elegant design, and changed how I implemented my C++11 meta-programming library, and in general shaped what I think about meta-programming in modern C++. Thank you Peter for your work on Mp11, for submitting it for inclusion in Boost, and for the articles that motivated it and taught the rest of us. Glen

1 0

[reflection] Which if any reflection library to use
by RAM 22 Jul '17

22 Jul '17

I'm working on code that will need to use reflection, and would like to know if boost already has a reflection library, or uses one preferred library? I know there are future C++ proposals such as those listed below, and am curious if any of them have already been implemented somewhere? http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0590r0.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0385r2.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0194r2.html

4 5

Re: [boost] CMake Announcement from Boost Steering Committee
by Brian Wood 22 Jul '17

22 Jul '17

Klemens Morgenstern writes: >Am 21.07.2017 um 22:50 schrieb Niall Douglas via Boost: > >> Some would say that what has been achieved so far is a pale shadow of >> what would have been achieved without the self-serving elitism. If you >> look at the bits of Boost which got into the C++ standard, they are very >> obviously the simple bits. There's a lesson in that. > Let's see: > > Without templates > - boost.system_error > - boost.error_code > - boost.thread > - boost.filesystem > > With type erasure: > - boost.any > - boost.function > > With templates: > - boost.SmartPtr > - boost.variant > - boost.optional > - boost.bind > - boost.tuple > > Template black magic: > - boost.type_traits > - boost.asio (probably as the networking TS) > - boost.EnableIf > > May I ask what you based your statement on? Did you even look at the > list or would actually checking facts be elitism? I think you have to "chew the meat and spit the bones" (*) when it comes to Boost and the standard. And you left out the best one imo -- array. String_view is a good one also. On the other hand, I avoid std::any and I'm skeptical about filesystem. I make conservative use of unique_ptr and try to avoid shared_ptr. (*) My rabbi in Austin, Texas used to say this -- not in relation to Boost though. Brian Ebenezer Enterprises http://webEbenezer.net

1 0

boostorg now no longer a fork of har999y. [Fwd: Severing a 'fork' connection]
by Glen Fernandes 22 Jul '17

22 Jul '17

No longer related to har999y in any boostorg repositories. Glen ---------- Forwarded message ---------- From: Antonio Diaz (GitHub Staff) <support(a)github.com> Date: Fri, Jul 21, 2017 at 9:54 PM Subject: Re: Severing a 'fork' connection To: Glen Fernandes <glen.fernandes(a)gmail.com> Hey Glen, Thanks for that approval! I've detached that fork for you. Please let me know if you need anything else. Cheers, Antonio GitHub Support

2 1

Re: [boost] [review][mp11] Reminder of ongoing formal review
by Jason Rice 22 Jul '17

22 Jul '17

Hello, my name is Jason Rice, and this is my first Boost review so please take that into consideration. I'm also new to this mailing list thing so let me know if I did something wrong here. Please consider the following review for the proposed Boost.Mp11 library: 1. Should Mp11 be accepted into Boost? Please state all conditions for acceptance explicity. ACCEPT. No conditions 2. What is your evaluation of the design? The interface is very straight forward. It is mostly templates but the user is not burdened with accessing a nested "type" with every metafunction. The list algorithms are flexible in that they take any kind of list which is very handy. I did notice that the user is burdened with ensuring that a list is not const or they will just get a "implicit instantiation of undefined template" error which doesn't really point to the problem. (e.g. when using mp_append with many lists) The `mp_` prefix is welcome if this is destined for the `std` namespace. The `tuple_apply` could probably just be called `apply` since appears to be a shim of `std::apply`. The interface of map functions accepting any list of list is very nice. 3. What is your evaluation of the implementation? The implementation is very clean. I looked at `mp_map_find_impl` and it is very concise and easy to understand. I did find it annoying though that some of the public facing functions are defined inside detail files which makes the source code a little more difficult to traverse. I'd like to see mp_product perform on par with the other libs on metaben.ch 4. What is your evaluation of the documentation? For the interface, it gets the job done. The table of contents has some text wrapping that could be fixed. There is no instructions for installation that I could find anywhere. It fails to mention that Boost.Config is a dependency. (AFAICT) 5. What is your evaluation of the potential usefulness of the library? I use Boost.Hana quite a bit. I'm currently using a library like this to help where optimization for compile-time performance is needed so it is definitely useful. 6. Did you try to use the library? With what compiler? Did you have any problems? I used it in my library Nbdl to augment my use of Boost.Hana in a couple of places. The compiler is a recent pull of the Emscripten fork of clang targeting X86. I did get stuck for a while on a weird error I mentioned before because a used a const list. I didn't like having to also install Boost.Config. (I'm not using the Boost monolith build) 7. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent a few hours on it. I used mp_append and mp_with_index in my lib with great results. I just looked at the implementation of mp_map_find. I scoured the documentation looking for stuff and seeing what else was available. 8. Are you knowledgeable about the problem domain? Yes, I have done TMP and I am also a contributor to Boost.Hana. Jason Rice

2 1

Are there libraries without ACTIVE maintainers?
by Alexander Zaitsev 22 Jul '17

22 Jul '17

Hello. I think it's very important question: are there libraries without ACTIVE maintainers? For what? Because without active maintainers we can't guarantee quality of the libraries. Is Boost community sure, that for all Boost libraries there are active maintainers? E.g. see on Boost.Property_tree - on Github repo you can find a lot of "dead" pull requests without any answer. What should we do with it?

11 14

Re: [boost] Switch to CMake -- Analysis
by Rene Rivera 22 Jul '17

22 Jul '17

On Jul 22, 2017 4:41 AM, "Peter Dimov via Boost" <boost(a)lists.boost.org> wrote: Tim Blechmann wrote: fwiw, cmake and b2 have different architecture as one is a build system the > other is a generator for build systems. > I wonder how many of the people who repeat this mantra understand either Boost.Build or CMake. CMake does not generate build _systems_, it generates build _scripts_. So does, incidentally, Boost.Build, which is a major reason why it's so hard to understand. It would be more accurate to say that cmake generates build "scripts". And B2 generates build "instructions" (since it's internal data structure management).

2 1

Moving CMake forward
by John Maddock 22 Jul '17

22 Jul '17

Man but there's been a lot of hot air expanded on this subject.... guys if we're going to do this, just do it. We're empiricists around here: lets see what the proponents of CMake can come up with, yes I know there are straw man proposals, but I want something that demonstrates it can fully handle the complex cases at least as well as Boost.Build, and be maintainable by CMake ignorants like myself, because lets face it, once the transition is over, library authors will have to do the maintenance grunt work as before: and if we can't easily see how to do that, then the project probably fails. As a minimal first step, what I would like to see come up for review (yes a review folks!) is a system that: * Provides users with a way to build those libraries with source via CMake. All of them together, or just some subset. * Provides an install option for all of Boost. * Is trivially easy for non-CMakers like myself to maintain. Documentation should be provided (Boost/CMake best practice is...). * Is fully compatible with current auto-linking naming on Windows (plus whatever else comes along later like address-model and architecture name mangling that's in the works and has long been requested). * Supports libraries with non-trivial build requirements (regex, locale, what others?). * Is usable by end users to be able to easily reference Boost libraries from their own CMake projects (note, might be limited to libraries with source, since header only libraries are kind of trivial). An example, and how to documentation should be provided. * It would be nice if generated VS projects were reference-able from our own solutions as well, but I accept that may not be possible. * Is at a minimum, no worse than what we have now. What else? Takers? BTW, I don't see a need for this to encompass every Boost library with source before some kind of mini-review to iron out the warts... Just hoping to move things along, John. --- This email has been checked for viruses by AVG. http://www.avg.com

5 7

Re: [boost] Switch to CMake -- Analysis
by Thomas Heller 21 Jul '17

21 Jul '17

Am 21.07.2017 6:42 nachm. schrieb "Vinnie Falco via Boost" < boost(a)lists.boost.org>: On Fri, Jul 21, 2017 at 9:34 AM, Stefan Seefeld via Boost <boost(a)lists.boost.org> wrote: > Then *please* let's not add unrelated points to the discussion, for the > sake of getting a handle of what problems we have to solve, and how. Hmm...my apologies but I think this error is very much on-topic: >CMake Warning at cmake/share/cmake-3.8/Modules/FindBoost.cmake:762 (message): >Imported targets not available for Boost version It's a symptom of the problem. It is off topic in the regard that insisting that the problem exists won't make it go away. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

1 0

[review][beast] Beast Review Results
by Michael Caisse 21 Jul '17

21 Jul '17

In an effort to get you all to just read this announcement sequentially, I will start with the result: Beast is ACCEPTED into Boost without conditions The entire community is served when the Boost review process works well and I would like to personally thank each of you who took your valuable time and worked to make Boost better. We had 21 formal reviews submitted from a demographic that included both seasoned participants and first-time reviewers. It is gratifying to have such participation for what some might see as a niche library. * Thank you Vinnie for your effort to assemble a high-quality package for review and for your responsiveness on the mail-lists. GitHub, and Slack. * Thank you to the individuals that submitted their first Boost review. * Thank you to the veteran contributors and authors for continuing to devote energy to the community. I found the discussion surrounding the library beneficial and I know that Vinnie walked away with actionable items to improve Beast. -------------------- The Stats: -------------------- While the review process is not exactly tallying up votes and casting a verdict, we can gain some insight of the general, gross-scale opinion of the library. Official reviews were received from: Reviewer Accept | Reject ------------------------------------------ * Zach Laine : X * Nik Bougalis : X * Artyom Beilis : X * Peter Dimov : X * Klemens Morgenstern : X * Glen Fernades : X * Marcel Ebmer : X * Scott Determan : X * Stanislav Karchebnyy : X * Michael Larson : X * Vadim Zeitlin : X * Jared Wyles : X * Niall Douglas : X * Barrett Adair : X * Gyorgy Szekely : X * Daniela Engert : X * Jens Weller : X * Phil Endecott : X * Bjorn Reese : X * Rüdiger Berlich : X * Christopher Kohlhoff : X Most of the reviewers agreed on the inclusion of Beast into Boost and at the same time that Beast isn't a great name for the library. (Just say Boost.Beast 10-times-fast). Vinnie has a FAQ item discussing the name and his continuing use is deliberate. He has heard the petitions to change and weighed them. -------------------- Concerns: -------------------- A variety of concerns and comments were made during the review. An impressive number of items were addressed in code or documentation during the review period itself. Some of the stated concern for rejection included: * Too many templates * Run-time polymorphism / OO would be better. * Library scope is too small and provides no real value to users - This is clearly one of those value judgements and for some users the not-in-scope nature of Beast made the feature set not compelling enough to use or have as a Boost library. Other users spent time converting existing projects to use Beast. This included projects previously running POCO, libcurl, and homegrown solutions. Beast has existing commercial and open-source users. The library clearly meets the needs of some users. * Premature optimization * Security concerns * Poor support for HTTP chunking - Vinnie proposed and then later made changes addressing the chunking concerns. Unfortunately, the reviewer with the complaint did not respond to multiple requests for feedback. * Licensing - Four files have dual licenses (BSL and another). Boost's legal counsel is reviewing the situation and we hope to have guidance by the end of this week. I have not placed a condition on the acceptance of Beast based on the legal feedback because Vinnie knows licensing issues must be remedied before the repository is merged into Boost. -------------------- The Upsides: -------------------- There were lots of great things said about the Beast package. Some of these include: * Great documentation * High quality implementation. * Thorough test suites * Already being used by commercial entities and others * Lots of successful real-life conversions of existing clients/servers * Extremely responsive developer (do you sleep Vinnie?) -------------------- An Author as much as a Library: -------------------- Accepting a library into Boost is also accepting an author. Boost authors have enormous latitude in the control and modifications of their libraries. Vinnie has shown dedication to addressing issues, listening to constructive input, making changes when appropriate, and protecting his vision of what the Beast is. I believe Vinnie will serve the community well as a contributor. -------------------- Final Thoughts: -------------------- Reviews are hard. It is hard to have your work torn apart and remain considerate. It is hard to repeat answers to previously asked questions. It is hard to explain specific use-cases and why it is important a library supports them. It is difficult to critique a large body of work. It is hard to stick with conversations to make overall improvements. I was impressed with the participants in the review. We are all opinionated and passionate -- likely a prerequisite to being part of the Boost community. Thank you all for making Boost better. I'm looking forward to seeing additional libraries and application built with Beast. -- Michael Caisse Ciere Consulting ciere.com

6 10

[OFF] Inclusive language (Was: [review][beast] Review of Beast starts today : July 1 - July 10)
by Vinícius dos Santos Oliveira 21 Jul '17

21 Jul '17

2017-07-01 21:54 GMT+02:00 Vinnie Falco via Boost <boost(a)lists.boost.org>: > Such language is non-inclusive and diminishes the stature of the list > (in my opinion). So what? What's the problem of non inclusive languages? This is just automatic reaction. Rust language community is full of this shit and is unbearable. “but-but-but the feelings... oppression”. Grow up. If you're on the Rust community, you cannot criticize design decisions that anyone will answer with “you have a very negative tone indeed”. That community is cancer (oh... I just used an oppressive word... how unpleasant I'm looking now...). And it's the same community which will **applaud** a guy who says shit about async I/O... like... “I think the proper way to use async I/O is creating threads”. The same fucker who says “I don't like Windows... that's why I don't support Windows”. As a matter of fact, I don't like Windows either, but I leave my non-important programming tastes out of my working environment (so oppressive). Next time you will want to ban blacklist/whitelist from your repos because that's racist. Stop this fucking nonsensical bullshit. You end up hiding yourself behind a prepared excuse. The only part I agree with you is the part on keeping the topic focused. That's why I'm creating another topic just for that. Niall's comment was absolutely on topic as a critique of the obvious. He could just say in other words, like “you're not programming seriously if you ignore error handling”. Or he could be so desperately concerned about politically correct. It'd be a great and unnecessary distraction. He would start to censor himself and not say everything which may be of value because he is scary of “improper language”. He didn't even need to censor himself this time (you've done this for him — a community of self-vigilant sheep... how wonderful will be our future... just like Rust and its “nazi-demographic surveys/corrections-to-be-done”). Do not mirror Rust's bad practices here. Do as Niall and try to mirror the good parts instead (e.g. error handling). Feel free to only answer after review of Beast finishes. Otherwise I'll steal focus that shouldn't be stolen now. Actually, I suggest to only answer after the review period finishes. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

7 10

Strawman proposals for CMake support
by Louis Dionne 21 Jul '17

21 Jul '17

Hi, I'd like to expose two strawman proposals for adding CMake support to Boost. Both proposals would solve the following problems, with different advantages and disadvantages: (1) Users have a hard time integrating Boost into their build system, which is CMake more often than not. (2) Prospective Boost developers are sometimes driven away from submitting because they would have to learn Boost.Build, which is not widely used and has a limited knowledge base. FIRST PROPOSAL ============== The first proposal is to move completely to CMake and to render Boost.Build support optional. The possible rollout plan would look something like: 1. We start requiring that new libraries support both Boost.Build and CMake. 2. We start adding CMake support to existing libraries. This will take time. 2.1 We start moving our infrastructure to be CMake-based. 3. We release Boost with dual support for a while, letting time for things to bake. 4. We remove the requirement that Boot libraries can be built with B2. Libraries (existing and new ones) are free to provide such support, but they are not required to. This would bring CMake to the status of "primary" build system for Boost. This could be based on Paul Fultz's work in progress at [1]. This has the following advantages (in the long term): - Less technical debt because we only have one "official" build system to maintain. - The build system is uniform across all of Boost, which means it's easier for folks to maintain it and understand it. - It gives maximal flexibility to CMake-based users. However, it has the following drawbacks: - We'll need to do a wholesale migration to build system XYZ when CMake is not cool anymore. - It's harder to get buy-in from some developers that love Boost.Build SECOND PROPOSAL =============== The second proposal is to make Boost into an almost build-system agnostic collection of libraries. Basically, 1. Provide CMake package config files for all Boost libraries so that they can be used from CMake (either automatically, manually, or a mixture of both). This could be based on Peter Dimov's work at [2] (or [3], not sure which one is most current). 2. Make it possible to build CMake-based projects from Boost.Build, or the other way around, or provide a build system agnostic script to build all of Boost. This way, Boost libraries can decide whether they want to support B2 or CMake. This has the following advantages: - Possibly easier to implement - We could possibly support other build systems too (e.g. if a Boost author really wants to use scons for his/her library) - We don't have to do a wholesale move to XYZ when CMake is not cool anymore I see the following disadvantages: - Boost's infrastructure could grow more complex as a result - Our build system would be less uniform - We would have to depend on all the build systems that we want Boost libraries to be usable with My personal preference is towards the first option, since I think it would be simpler in the long term. I could certainly be convinced otherwise. There are probably other ways we can solve problems (1) and (2) exposed above. There are also certainly advantages and disadvantages that I forgot to mention above. I'd love to get some feedback on those two approaches and see whether one of them (or something else completely) can get some consensus on this list. Cheers, Louis [1]: https://github.com/boost-cmake/bcm [2]: https://github.com/pdimov/boost-cmake-demo-2 [3]: https://github.com/pdimov/boost-cmake-demo -- View this message in context: http://boost.2283326.n4.nabble.com/Strawman-proposals-for-CMake-support-tp4… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 9

A vision of Boost
by David Sankel 21 Jul '17

21 Jul '17

I got involved with Boost in 1999. I was 17, attempting to learn C++, and saw a footnote in "The C++ Standard Library" that mentioned boost.org as a place where quality C++ libraries are found. For me, it was love at first sight. Automatic pointers? Amazing. 'std::array'? Fantastic. I've been using C++ and Boost ever since. Never in my wildest dreams would I have imagined that eighteen years later I'd be sitting on the C++ standardization and Boost steering committees. As I listen in the Library Evolution Working Group I imagine what it must've been like for Beman and Dave to sit in similar meetings and ask themselves "wouldn't it be great if there were an online place that collects freely available C++ libraries and offers a peer-review process for incorporation? It'd be hugely beneficial for C++ users and the C++ standard as well." People get involved in Boost for many reasons. Some think it'll improve the chances they get their library standardized (and it's true!). Some think it'll improve their consulting or job prospects (true as well!). Others hone in on particular aspects, such as the build system, the people, or individual libraries. All these reasons are great, but for me the key was Boost's mission: to improve the way people code. At first it was more about improving the way I code, but as time went on it became more and more about helping others. For me, this is something worthwhile; worth sacrificing for. Now there are pros and cons with moving Boost to CMake, but at the center of all steering committee discussions has been the Boost mission. "How is this going to help us reach more users?" "How is this going to help us reach more developers?" "How is this going to impact the standard and the greater C++ community?" We may have made the wrong choice (though I doubt it). We may have communicated it in a non-ideal way. However, one thing is for sure: We made the decision based on furthering Boost's mission. A mission I want others to fall in love with like I have. So, we're moving to CMake. And, yes, we'll get there together. Many questions still exist and we'll have to figure out the answers as a community. The stalemate, however, is now over. -- David Sankel

2 1