October 2020 - Boost - lists.preview.boost.org

Boost.Text is looking for a (mini-)review manager
by Zach Laine 07 Dec '22

07 Dec '22

I've made all the recommended changes to Boost.Text that came up in the review. Glen, the previous review manager, recommended a mini review of Boost.Text once I'd made those changes. If you'd like to manage the mini-review, please let me know. For everyone, including potential reviewers and review managers, here are the major changes: * All the specific review feedback issues have been addressed. * The string layer is now gone. * The text layer got a major re-work. It is now a set of template-based adaptors (basic_text<>, vs. a text typedef. etc.), which lets everyone get what they want. You can change the underlying storage type (including whatever allocator you prefer), select UTF-8 or UTF-16, and change the normalization form. Glen recommended I drop this layer, but the library is way less useful without this stuff, and these changes address all the concerns raised about the text layer in the review. The updated docs can be found here: https://tzlaine.github.io/text/doc/html/index.html Oh yeah, and I added concept constraints to the whole library when you build in C++20 mode. Zach

17 46

[review][JSON] Review of JSON starts today: Sept 14 - Sept 23
by Pranam Lashkari 09 Aug '22

09 Aug '22

Boost formal review of Vinnie Falco and Krystian Stasiowski's library JSON starts today and will run for 10 days ending on 23 Sept 2020. Both of these authors have already developed a couple of libraries which are accepted in Boost(boost beast and Static String) This library focuses on a common and popular use-case for JSON. It provides a container to hold parsed and serialised JSON types. It provides more flexibility and better benchmark performance than its competitors. JSON highlights the following features in the documentation: - Fast compilation - Require only C++11 - Fast streaming parser and serializer - Easy and safe API with allocator support - Constant-time key lookup for objects - Options to allow non-standard JSON - Compile without Boost, define BOOST_JSON_STANDALONE - Optional header-only, without linking to a library (a point I would like to add in highlight: it has cool Jason logo 😝) To quickly understand and get the flavour of the library take a look at "Quick Look" <http://master.json.cpp.al/json/usage/quick_look.html> You can find the source code to be reviewed here: <https://github.com/CPPAlliance/json/tree/master> You can find the latest documentation here: <http://master.json.cpp.al/> Benchmarks are also given in the document which can be found here: <http://master.json.cpp.al/json/benchmarks.html> Some people have also given the early reviews, the thread can be found here: <https://lists.boost.org/Archives/boost/2020/09/249745.php> Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including JSON as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found here: <http://www.boost.org/community/reviews.html> Thank you for your effort in the Boost community. -- Thank you, Pranam Lashkari, https://lpranam.github.io/

21 73

Adding my sorting algorithm, ska_sort, to boost, attempt 2
by Malte Skarupke 24 Nov '21

24 Nov '21

Hi everyone, I started a discussion about this in October, but at the time the maintainer of the sort library was busy, then I was busy, so now it's January... I wrote a generalized version of radix sort a couple years ago and gave a talk about it here: https://www.youtube.com/watch?v=zqs87a_7zxw I would like to get a new version of that sorting algorithm into boost. It's faster than what I showed several years ago. It's also even more general and has a new interface that should be easier to extend. I uploaded the code here: https://github.com/skarupke/sort/tree/master The documentation is also already updated with new benchmark results. Let me know what's required to get this into boost. Would you like this in the form of a pull request? One of the big things that probably needs review is the interface, since radix sorting works differently than comparison based sorting. For most normal uses you just need to provide a sort key, but more complicated cases can get more complicated. I tried very hard to make everything easy, but I'd also be curious if others can come up with better ways of doing the interface. Thanks, Malte -- Malte Skarupke malteskarupke(a)fastmail.fm

8 10

[1.75 release] Merging 'develop' to 'master' for Embarcadero fix
by Edward Diener 06 Nov '20

06 Nov '20

A number of libraries have my PR to enable Embarcadero C++ clang-based compilers for Boost in their 'develop' branch but the branch has not been merged to 'master' for the 1.75 release. In the large majority of cases my PR for Embarcadero is the only difference between 'develop' and 'master'. These libraries are: assign circular_buffer container_hash date_time foreach graph iostreams numeric_conversion optional pool ptr_container random static_assert thread typeof units unordered If any of the maintainers of these libraries could see fit to get my PR in 'master' from 'develop' for the 1.75 release, it would be appreciated. I can assert that the PR causes no problems in the 'develop' regression tests for the aforementioned libraries. I have also opened up an issue for each of the aforementioned libraries in their Github page regarding my request.

7 18

1.75 schedule reminder
by Peter Dimov 03 Nov '20

03 Nov '20

A reminder that Oct 21 was the cutoff date for new library additions, and the upcoming deadlines are - Oct 28: Boost 1.75.0 closed for major changes - Nov 4: Boost 1.75.0 closed for beta - Nov 11: Boost 1.75.0 beta - Dec 2: Boost 1.75.0 closed for release - Dec 9: Boost 1.75.0 release (See the calendar at https://www.boost.org/development/index.html.)

5 4

sticky question regarding boost rational
by Robert Ramey 02 Nov '20

02 Nov '20

boost rational is tripping up one of my examples in safe numerics: // solution: use safe integer in rational definition using safe_rational = boost::rational< boost::safe_numerics::safe<int> >; // use rationals created with safe_t const safe_rational sc {1, std::numeric_limits<int>::max()}; std::cout << "c = " << sc << std::endl; const safe_rational sd {1, 2}; std::cout << "d = " << sd << std::endl; std::cout << "c * d = "; try { // multiply them. This will overflow std::cout << sc * sd << std::endl; // use of overload operator * is ambiguous. rational.hpp contains - among other things, the following definitions for the * operator: template <class IntType, class Arg> BOOST_CXX14_CONSTEXPR inline typename boost::enable_if_c < rational_detail::is_compatible_integer<Arg, IntType>::value || is_same<rational<IntType>, Arg>::value, rational<IntType> >::type operator * (const rational<IntType>& a, const Arg& b) { rational<IntType> t(a); return t *= b; } template <class Arg, class IntType> BOOST_CXX14_CONSTEXPR inline typename boost::enable_if_c < rational_detail::is_compatible_integer<Arg, IntType>::value, rational<IntType> >::type operator * (const Arg& b, const rational<IntType>& a) { rational<IntType> t(a); return t *= b; } Soooooo - it seems that sc * sd will match both of the above definitions. Its unclear what the purpose of these two different overloads are. They look pretty similar to me. the definition for is_compatible_integer. namespace rational_detail{ template <class FromInt, class ToInt, typename Enable = void> struct is_compatible_integer; template <class FromInt, class ToInt> struct is_compatible_integer<FromInt, ToInt, typename enable_if_c<!is_array<FromInt>::value>::type> { BOOST_STATIC_CONSTANT(bool, value = ((std::numeric_limits<FromInt>::is_specialized && std::numeric_limits<FromInt>::is_integer && (std::numeric_limits<FromInt>::digits <=std::numeric_limits<ToInt>::digits) && (std::numeric_limits<FromInt>::radix == std::numeric_limits<ToInt>::radix) && ((std::numeric_limits<FromInt>::is_signed == false) || (std::numeric_limits<ToInt>::is_signed == true)) && is_convertible<FromInt, ToInt>::value) || is_same<FromInt, ToInt>::value) || (is_class<ToInt>::value && is_class<FromInt>::value && is_convertible<FromInt, ToInt>::value)); }; ... In fact, since it looks like if FromInt and ToInt are the same types (as they are in my case, one will always got more than one match. Is anyone (John Maddock - where are you?) able to shed some light on this for me? Robert Ramey

2 1

Compile failure in boost.signals2 with latest clang, c++20 and libc++
by Richard Hodges 31 Oct '20

31 Oct '20

Details in the linked issue: https://github.com/boostorg/signals2/issues/46 -- Richard Hodges

1 0

[Algorithm] Implementing: Find Longest Palindromic Substring(Sub-vector).
by Kanishk 31 Oct '20

31 Oct '20

Hello all, I'm new to the Boost community and this is my first time posting to the mailing group. What brought me here: I'm a Computer Science student and I often have to code up string/sequence related algorithms. An algorithm that I found was missing from the boost libraries was "Find Longest Palindromic Substring(or generic Sub-vector)". Boost has *is_palindrome *( https://www.boost.org/doc/libs/1_66_0/boost/algorithm/is_palindrome.hpp), but using that to check every possible substring will result in an O(N^3) runtime. It is trivial to implement an O(N^2) algorithm for this purpose using dynamic-programming. It is also possible to implement this in O(N) using the Manacher's algorithm ( https://en.wikipedia.org/wiki/Longest_palindromic_substring#Manacher's_algorithm ). Will this be a useful addition to the Boost.Algorithm library? If so, I would love to start contributing to boost through this. Regards, Kanishk

1 0

[histogram][type_traits] strange compile error in boost.histogram for gcc-7.1+ with -std=c++17; possible bug in gcc?
by Hans Dembinski 30 Oct '20

30 Oct '20

Dear John and the other gurus, a strange bug was reported for Boost.Histogram. It is a difficult one for which I would like to ask for help. To me it looks like a bug in gcc. Here is the issue: https://github.com/boostorg/histogram/issues/290 And here is a link to reproduce it: https://godbolt.org/z/oK4866 The following innocent code compiled with gcc-7.1 or newer with -std=c++17 ``` #include <boost/type_traits/rank.hpp> #include <boost/histogram/axis/traits.hpp> int main() { return 0; } ``` produces this error message (excerpt): ``` cc1plus: error: return type specified for deduction guide In file included from <source>:2: /celibs/boost_1_74_0/boost/histogram/axis/traits.hpp:411:11: error: 'decl-specifier' in declaration of deduction guide 411 | constexpr unsigned rank(const Axis& axis) { | ^~~~~~~~ /celibs/boost_1_74_0/boost/histogram/axis/traits.hpp:411:1: error: 'decl-specifier' in declaration of deduction guide 411 | constexpr unsigned rank(const Axis& axis) { | ^~~~~~~~~ /celibs/boost_1_74_0/boost/histogram/axis/traits.hpp:411:11: error: 'unsigned' specified with 'rank<...auto...>' 411 | constexpr unsigned rank(const Axis& axis) { | ^~~~~~~~ /celibs/boost_1_74_0/boost/histogram/axis/traits.hpp:411:20: error: deduction guide for 'boost::rank<T>' must have trailing return type 411 | constexpr unsigned rank(const Axis& axis) { | ^~~~ In file included from <source>:1: /celibs/boost_1_74_0/boost/type_traits/rank.hpp:82:27: note: 'template<class T> struct boost::rank' declared here 82 | template <class T> struct rank : public integral_constant<std::size_t, (::boost::detail::rank_imp<T, 0>::value)>{}; | ^~~~ ``` gcc interprets my function called `rank` as a deduction guide for `boost::rank` in boost/type_traits/rank.hpp. It then continues to complain that this function does not look like a deduction guide. Well, it isn't one, duh. I can see nothing wrong with my code or the code in boost/type_traits, so my guess is a bug in gcc. If you all agree, I would report this. If this is really a bug in gcc, however, it exists since v7.1 all the way to gcc trunk. In either case, it would be great if we could use a workaround in Boost until that problem is fixed. I found a workaround is to replace line 82 in boost/type_traits/rank.hpp with: ``` template <class T> using rank = integral_constant<std::size_t, (::boost::detail::rank_imp<T, 0>::value)>; ``` This avoids the issue because now the struct ``rank`` is gone and therefore gcc does not try to find a deduction guide for it. Is there a better solution? Best regards, Hans

3 4

[gil] Phasing out support C++11 and switching to C++17
by Mateusz Loskot 27 Oct '20

27 Oct '20

Hi, We're discussing [1] to start switching GIL to C++17 in the near future and, following Peter Dimov's policy on phasing out C++XY support [2], we'd like to: 1. Declare C++11 support deprecated in 1.75 (December 2020) 2. Drop C++11 support in 1.77 (?) (August 2021) Could anyone help us validate and confirm that it's a good plan or are we overlooking any policies from Boost's release perspective? [1] https://lists.boost.org/boost-gil/2020/10/0465.php [2] https://pdimov.github.io/articles/phasing_out_cxx03.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

7 18

[pfr] Ready for informal mini review
by Antony Polukhin 20 Oct '20

20 Oct '20

Hi, Issues noted during the review period were fixed. Mainly: * global_ops.hpp is removed * boost::pfr::ops::operator* were changed to functions and moved to boost::pfr:: namespace * Flat reflection was purged * Big rewrite of docs I'd appreciate a look at the updated library https://github.com/boostorg/pfr and its docs https://apolukhin.github.io/magic_get/index.html Any comments and feedback is welcomed! -- Best regards, Antony Polukhin

2 3

Re: [boost] [pfr] Ready for informal mini review
by Glen Fernandes 20 Oct '20

20 Oct '20

Antony Polukhin wrote: > I'd appreciate a look at the updated library > > https://github.com/boostorg/pfr and its docs > https://apolukhin.github.io/magic_get/index.html > > Any comments and feedback is welcomed! Note that the last day for new libraries for Boost 1.75 is tomorrow (2020-10-21). PFR has a develop submodule, but no master submodule yet. I was waiting until you believe it is ready, and have ironed out all the issues on develop. If you want it included in the 1.75 release, and there are no objections from any reviewers, I can add the master submodule today. (It was already added to the in-progress release notes for 1.75, but that can be removed if you don't want to release it until 1.76). Glen

2 2

[FPR] Review of FPR starts Today: Sept 28 - Oct 7
by Benedek Thaler 16 Oct '20

16 Oct '20

The Boost formal review of the FPR (Flat Precise Reflection, ex Magic Get, ex PODs Flat Reflection) starts Today, taking place from September 28, 2020 to October 7, 2020. The library is authored by Antony Polukhin, author of Boost.DLL, Stacktrace, Type Index libraries. Documentation: http://apolukhin.github.io/magic_get/ Source: https://github.com/apolukhin/magic_get The library is meant for accessing structure elements by index and providing other std::tuple like methods for user defined types without any macro or boilerplate code. The FPR documentation summarizes the out-of-the-box added functionality for aggregate initializable structures: - comparison operators - heterogeneous comparators - hash - stream operators - access to members by index - member reflections - methods for cooperation with std::tuple - methods to visit each field of the structure If the description isn't immediately obvious for you, here's a motivating example: // requires: C++14 #include <iostream> #include <string> #include "boost/pfr/precise.hpp" struct some_person { std::string name; unsigned birth_year; }; int main() { some_person val{"Edgar Allan Poe", 1809}; std::cout << boost::pfr::get<0>(val) // No macro! << " was born in " << boost::pfr::get<1>(val); // Works with any aggregate initializables! } Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including FPR as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found at: http://www.boost.org/community/reviews.html Thank you for your effort in the Boost community. Benedek - review manager of the FPR library

8 12

Latest boost documentation
by Raghu Huchchannavar 15 Oct '20

15 Oct '20

Hi, Can anyone help me in getting the latest boost documentation either a link or the pdf one. -- Regards Raghavendra Huchchannavar.

3 2

boost::asio::deadline_timer segmentation in version 1.71
by Jupiter 14 Oct '20

14 Oct '20

Hi, My application is running one thread under boost::asio::io_service, it is an embedded system running on an ARM processor with Linux, so no gdb installed. The application is also using a boost::asio::deadline_timer to call a function every second, but I got following segmentation stack trace: _ZN5boost4asio6detail9scheduler10do_run_oneERNS1_27conditionally_enabled_mutex11scoped_lockERNS1_21scheduler_thread_infoERKNS_6system10error_codeE+0xdd _ZN5boost4asio6detail9scheduler3runERNS_6system10error_codeE+0x83 I thought I could run c++filt to demangling the library name, not sure why it didn't demangle the name today. I used the same boost::asio::deadline_timer version 1.69 for another application running on Ubuntu which was working fine, what I could be missing? Thank you. Kind regards, Jupiter

2 2

[PFR][review] Result
by Benedek Thaler 10 Oct '20

10 Oct '20

Thanks to all of you who participated in the formal review of PFR, henceforth known as Boost.PFR, and Antony Polukhin for submitting this magical library. PFR is ACCEPTed into Boost, with the following results: ACCEPT: 5 votes CONDITIONAL ACCEPT: 1 vote REJECT: 0 votes Reviewers highlighted that the library is "very useful", "magical" and "provides a form of reflection in a simpler manner than other solutions thus far". During the review, several points of improvements were identified, and Antony committed to improve the library accordingly. The main concerns were: - Definition of the type concept the library can work with - Clarification of the flat / precise use-cases - The presence of global operators - The way output formatting is defined - Dropping "Reflection" from the name (this is already reflected in the docs) Antony plans to: - Remove Flat reflection - Remove global_ops - Add more examples to the docs, introduce terms in a cleaner manner - Improve the reference section - Take another look at the pfr::ops and macro for operators After all these changes have been implemented, Antony would really like to have a mini-review, regardless that the library is already ACCEPTed, further confirming his high standards. Good luck Antony, keep up the good work! Benedek review wizard

7 15

[PFR][review] Review of PFR ends Today
by Benedek Thaler 07 Oct '20

07 Oct '20

The review of the PFR: Precise and Flat tuple Representation (ex Precise and Flat Reflection, ex Magic Get, ex PODs Flat Reflection) ends Today. Do not hesitate to send late reviews, there's still time. Documentation: http://apolukhin.github.io/magic_get/ Source: https://github.com/apolukhin/magic_get I'll announce the review results soon. Benedek review manager

2 1

[PFR][review] Andrzej's review
by Andrzej Krzemienski 07 Oct '20

07 Oct '20

Hi Everyone, This is my partial review of PFR library. I have read the docs, watched Antony's talk, played with some toy examples, and had a brief look at the implementation of pfr::tuple_size. I spent like 14 hours in total on this. I have studied the subject of tuple-like access to class objects a while back, which resulted in this proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3326.pdf. I like the library, I think it has the potential to address a small but a well understood demand. While I would like to see it included in Boost, I believe it should not be accepted just yet, in its current shape. I disagree with parts of the design (injecting the interface of user types) as explained below. Missing documentation parts (I mean the concept "Baseless Aggregate") is also an issue for me. First, it might be an indication of a flaw in the design. Second, it might cover some bugs in the implementation. Third, making another review with updated docs might attract more reviews and may make people appreciate the library more. Alternatively, I could have called it a conditional acceptance with everything listed below as conditions. Since reviewers are not casting votes but give recommendations instead, the Review Manager may want to take this into account. I think that this type of the library is mostly about the documentation and design (like, the scope). The implementation will necessarily be a number of hacks to provide the magic. Since I question parts of the design, I didn't find it necessary to review the implementation in detail. The following list may appear long, and look like a long list of complaints, so I need to make this clear up front. I really like the library, and I intend to use it next time I have a need for the tuple-like access to PODs, even download it from GitHub. I recommend the rejection because I see the second review as an opportunity for the library to become even better. DOCUMENTATION Documentation does explain how to use the library, and after a while it becomes easy to use every function, at least the functions that I tried. But it is missing some important parts, therefore it confuses the potential users as to what its scope is, and gives an (false) impression that it is defective. (Some of the below points may not hold anymore, as I have noticed the documentation has changed during the review period.) 1. The library name is misleading. It uses the name "reflection" but it doesn't really implement reflection. A reflection would be a way of querying the system for different properties of declarations in the program. This is not the case here. 2. The intro page misses the opportunity to present the scope of the library, its power, and the minimal example of how to use it and how it makes the life of the programmer easier. It is a very good library, and it would be a great loss if it was overlooked due to not being advertised effectively. I volunteer to provide the content of the initial page that I believe would meet the criteria. 3. The library buds on a basic concept of "Base-less aggregate". It must document it up front. And if possible try to statically detect if the types satisfy it to the extent that this is doable. After reading the docs, the user has to have a clear picture which types will and which won't work with the library. 4. It should contain a couple of motivating use cases, both for flat and precise representation. It is not enough to show how they work. The user must also see why they would be useful for anyone. Some users immediately see that this library addresses their use, others are confused, and cannot see any purpose in having it. 5. One use case for flat reflection is when a couple of aggregates have a common subset: ``` struct Person { std::string firstName; std::string lastName; int age; }; struct Employee { Person person; double salary; }; struct Prisoner { Person person int cellNumber; }; std::set<Person, boost::pfr::flat_less<>>; std::set<Employee , boost::pfr::flat_less<>>; std::set<Prisoner , boost::pfr::flat_less<>>; ``` Just saying, "use flat variants when you want to flatten your aggregate" is not enough to make the user see the capabilities of this library. I think that this use case should be documented. 6. I believe that individual operations are underspecified. For instance: i. pfr::write (http://apolukhin.github.io/magic_get/boost/pfr/write.html) has a section "Description", but it doesn't say what the function is doing. To some extent, we can guess that from the signature but some important questions remain unanswered: What format of the serialized output does the library guarantee? Does it guarantee any format at all? Do you leave yourself a freedom to change it in the future without notice? Can users customize it? If so, where is it specified? (This would be a no-problem if the library didn't provide stream insertion operations.) ii. The library says it can inject relational operators (and others) but it doesn't specify what their semantics are. 7. The means of specifying the semantics of the functions could be improved (i.e., made shorter and more precise) if you specified prf::structure_to_tuple (and pfr::flat_structure_to_tuple) very precisely as std::tie() on the corresponding aggregate elements, and then define the semantics of every other function in terms of prf::structure_to_tuple. Instead, I can see that prf::structure_to_tuple is underspecified ( http://apolukhin.github.io/magic_get/boost/pfr/structure_to_tuple.html). Section "Description" does not describe what the function is doing. DESIGN 1. I am missing the concept "Base-less aggregate" that is a basic building block of this library. I would expect it to appear in one of the front pages of the docs, and static checks in the code that would mention this name, so that I am immediately informed if I fail to satisfy the concept. I realize that defining a type trait for this is impossible, but even if it is a line of code deep inside the implementation that breaks (like, decomposing the aggregate into a structure binding), this line should have a comment saying something like "if compilation breaks on this line, it is likely because your type does not satisfy the requirements of a BaselessAggregate." 2. I appreciate functions that this library defines in namespace boost::pfr, such as pfr::less or pfr::for_each_field or pfr::structure_to_tuple; but I do not appreciate that this library injects functions into global namespace or my namespace or even that it provides operators (like <<, which are naturally part of my classes' interface) for my types in namespace boost::pfr. I really consider this harmful, causing subtle ADL-related bugs. If I want my types logged, I would rather expect to be able to type: ``` // in my namespace inline std::ostream& operator<<(std::ostream& o, MyAggregate const& a) { return boost::fpr::write(o, a); } ``` Same with relational operators: rather than library injecting them (and potentially causing ADL problems or ODR violations, especially in C++20), I would rather use a named PFR function where needed: ``` sort(myAggregates.begin(), myAggregates.end(), boost::fpr::less<>{}); std::set<MyAggregate, boost::fpr::less<>> map; ``` This is a bit more verbose, but: i. Still does not require me to list members anywhere (the primary advantage of this library). ii. There is no possibility of getting any ADL- or ODR-related bug. The ODR-violation bugs are really nasty. You do everything fine in your .cpp file and you have no clue why the program desn't work as you expect. And this is because someone else in another .cpp file has put different declarations. And if you have 100.000 cpp files, you may not be able to find the cause for weeks. Offering these operators encourages this type of bugs. 3. If we eliminate the injected operators from the picture, we get a sound interface that can be reused in the future revisions of C++, where the internals will be able to use native C++26 reflection instead of the current hacks. We would get the beautiful effect that the initial Boost libraries provided: an interface that can work uniformly both with old and modern versions of C++. 4. There is another reason why I do not like the stream insertion operators. They just don't belong conceptually to this library. Stream insertion is another problem domain: i. How do you serialize type `char`: as a numeric value, or as a graphical symbol ii. How do you serialize a pointer? As an address it represents? Do you make an exception for type `const char *`? Do you make an exception for type `char32_t const*`? iii. How do you separate the individual values? What character do you use for grouping them? iv. How do you allow users to control what happens for individual types? v. What if the user is nonetheless disappointed with your design choices? These issues go far beyond providing a tuple-like access to aggregates. They should be addressed by a separate library built on top of PFR. 5. Docs say, "provides other std::tuple like methods for user defined types without any macro or boilerplate code."This is not actually the case. In order to get the operators for aggregates -- at least in one mode -- one has to use a macro. 6. I would also say that this is inconvenient that the library, as documented, allows me to inject all the operators or none. I cannot opt into taking only relational operators. At least this is not documented. But I cannot honestly complain about it, because I do not agree with PFR synthesizing any of these operations at all. FInally, I wanted to thank Antony for writing and sharing this library here. I learned a great lot from it. I didn't realize that such reflection was possible in C++17. I hope that my review does not sound discouraging. Regards, &rzej;

4 15

[JSON][review] Result
by Pranam Lashkari 05 Oct '20

05 Oct '20

I would like to thank Vinnie Falco and Krystian Stasiowski for developing this library and bringing it to the boost. I will try to keep the mail short and point to point. ---- RESULT ---- Boost.JSON is ACCEPTED into the Boost. Now the process to transition repository to boost can start and get this library published in next release according to the guidelines. There was some heat around the discussion, I would like to clarify that this is not a completely democratic decision. Though there are more accept votes but I was a bit leaned toward the arguments made in the favour of reject as those arguments were analysed thoroughly and on point and I agreed with them. On the other hand, considering the targeted audience and the goal of the library those arguments are weighed less in my opinion. "Can't reject an Apple because it is not an Orange". In general, the library looks great to me and I am sure it will attract new users too because it has good documentation, friendly APIs and design and good performance too. ---- REVIEWS ---- There was a good amount of discussion and definitely more reviews than I expected including a few first-time reviewers. Summary: Accept: 14 Reject: 3 Conditional accept: 1 Some positive reviews: It is very good, and meets the highest Boost standards. I mean both the > tutorial and reference sections. While doing this review I had to look at > the documentation of the competing libraries, and they are really bad. This > is why I can appreciate the big effort you put in making these docs. There > is a section "Comparison" that compares Boost.JSON to other JSON > libraries. > I personally think it should also mention the documentation. The design takes some time to get used to, but it fits well to the > problem being tackled (a JSON-DOM library). > Switching my codebases using RapidJSON to this library made the code > more readable and it will also allow me to get rid of a significant > amount of boilerplate. The fact that this value type has been highly optimized is the great > strength of this library. Design is very good. The parser interfaces and object building interfaces > meet my needs. I especially want to call out the pmr support and it's > support for either sharing or transferring ownership of resources. Some critical reviews: Binary size matters a lot, since onboard Flash is very limited. I am > using a "big" MCU, and that means my whole binary must be under ~512 KB. > Right now Boost JSON is not great. In doing a simple serialization and > parse, the library itself adds ~58 KB to my .text section. This is OK for > now, but surprisingly big. I know the team is aware of this and has some > ideas to reduce the binary size. I will likely need those fixes to actually > port my app to Boost JSON. It would be better for the library to just template on allocator just like > the vector class in the C++ standard ...and many more positive and critical reviews... A Thing I was explicitly asked to note: > The memory management model is extremely simple. I wonder if storage_ptr > could be moved somewhere else long term so other libraries can use it. I think that's it. I would like to thank everyone who was involved in the review process every review was important and gives new insight and helps to make boost better. Best of luck to the authors and the maintainers of the library. -- Thank you, Pranam Lashkari, https://lpranam.github.io/

7 17

[PFR] Some questions
by Gavin Lambert 05 Oct '20

05 Oct '20

This is not (yet?) a review, although I guess this could be counted as a partial review towards the current state of the docs; but after reading them I have several questions. 1. Why is the term "reflection" used at all? As far as I am aware, this is primarily used to refer to accessing member names from the structure, which is not something that this library provides at all, so at best this seems highly misleading. The original "magic get" name seems more appropriate since it is primarily about extending tuple-get to basic structures without boilerplate macros. 2. An up-front clarification on the limitations of supported structures would be nice. "Aggregate initialisable" is not a concept that everyone is familiar with. 3. What is the motivation for "flat" reflection to exist, at all? I can't find any explanation of why one might want to do it; other than completely disregarding type safety, which seems like a bad thing. (I assume there is some reason that I'm not aware of, but that's why an explanation would be nice.) 4. Flat reflection is stated to be non-portable, raising further questions as to why it exists at all. 5. Many of the intro pages talk about "disabling loophole" with no explanation of what that is. The configuration macros page finally presents a link that doesn't really explain anything anyway, other than suggesting it is a Dark Magic that was intended to be banned but nobody had gotten around to it yet. 6. Speaking of the configuration macros page, it doesn't indicate what values are the defaults, other than it "auto-detects your compiler". I assume from the surrounding text that it would prefer to use C++17 and would use "loophole" (whatever that is) otherwise, but it would be good to make that (or whatever it actually does instead) explicit. Granted #3 can't get you into *too* much trouble with the limitation on only supporting aggregate-initialised types... but on the other hand, type hierarchies are still significant for aggregates (it can be important to distinguish a "handle" from a plain int, or a Boost.Units value from another with different unit). And it feels like you're doing C++ wrong if you're using aggregate types much; they're only a little better than PODs. (In all existing codebases I use, there are almost no aggregate types, although there are a few almost-aggregates that have simple initialising constructors, for example, or make member fields private and use a get-set method pattern "just in case". I imagine this is likely to be true of most real-world codebases.) Having said that, I can see some value in aggregate types as DTOs (for database/json/etc translation) and for reducing usage of std::pair and std::tuple, which is a good thing, though only if used in limited scope. But that usage doesn't explain "flat" either; the type hierarchy still should be important. Precise reflection, on the other hand, seems more potentially useful, save for the unfortunate -- though understandable -- limitation on only aggregates. Having said that, I've personally never found a use-case for a tuple-like get interface for anything, so perhaps I'm just not the target audience for this library. (I also have a strong dislike for aggregate initialisation being order-based in the first place; I would have preferred something like C99's named initialisation. C++20 is adding something that they're calling that, but is utterly useless and crippled instead of doing it properly.)

4 6

traits
by Gero Peterhoff 03 Oct '20

03 Oct '20

Hello Peter, I've designed a couple of traits here. Is that right so far so that they can be included in boost? But there are these problems: 1) char8_t is still missing in your is_unsigned 2) my implementations of - is_native; if the type exists natively on the platform - is_vectorisable; if the type can be vectorized on the platform (simd) - is_integer are still incomplete, as I cannot find out whether the corresponding types are available; e.g. on some platforms there is int56_t, but no int8_t (__CHAR_BIT__ > 8), etc. The specializations of is_logic and is_rational should better be done in the libs. If a concept is created, it is stored in boost::mata so that there are no naming conflicts. Similar to math::constants there is also a string::constants; maybe also makes sense. regards Gero

2 3

new type traits
by Gero Peterhoff 03 Oct '20

03 Oct '20

Hello Developers, I would like to retrofit some type-traits in boost, but I have read https://pdimov.github.io/articles/phasing_out_cxx03.html. Now I don't know how to do it best, as the boost-type-traits may be removed. Would the following procedure make sense? We get the std-traits and concepts in a namespace boost::meta, eg file boost/type_traits/meta.hpp: #ifndef BOOST_META_HPP #define BOOST_META_HPP #include <type_traits> #if defined(__cpp_concepts) #include <concepts> #endif namespace boost::meta { template <typename Type> using is_integral = std::is_integral<Type>; template <typename Type> inline constexpr bool is_integral_v = std::is_integral_v<Type>; template <typename Type> using is_pointer = std::is_pointer<Type>; template <typename Type> inline constexpr bool is_pointer_v = std::is_pointer_v<Type>; ... all other #if defined(__cpp_concepts) template <typename Type> concept integral = std::integral<Type>; template <typename Type> concept pointer = is_pointer_v<Type>; ... #endif } // boost::meta #endif // BOOST_META_HPP Then you could possibly map this in boost/type_traits.hpp to boost:: (if that makes sense): #ifndef BOOST_TYPE_TRAITS_HPP #define BOOST_TYPE_TRAITS_HPP #include <boost/type_traits/meta.hpp> remove boost implementations namespace boost { using namespace boost::meta; } // boost #endif // BOOST_TYPE_TRAITS_HPP In this way, new traits can be added in boost/type_traits/meta.hpp that are based on the std-traits, e.g. is_logic namespace boost::meta { template <typename Type> struct is_logic : std::false_type{}; template <typename Type> inline constexpr bool is_logic_v = is_logic<Type>::value; template <> struct is_logic<bool> : std::true_type{}; #if defined(__cpp_concepts) template <typename Type> concept logic = is_logic_v<Type>; #endif } // boost::meta and in this case add in boost/logic/tribool.hpp namespace boost::meta { template <> struct is_logic<boost::tribool> : std::true_type{}; } // boost::meta Or do you have a better idea? regards Gero

6 15

[FPR] Some feedback
by Andrzej Krzemienski 03 Oct '20

03 Oct '20

Hi Everyone, Not sure if I will be able to provide a decent review, so I wanted to at least share some thoughts. 1. Do not use "reflection" in the library name. "Reflection" means "any information I could ever need about any part of the program". In particular, people might expect that you will be able to give the class member names; you cannot, and they will call it a bug in the library, because it implied that it would be able to do this, as this is what you expect from reflection. What this library does is to give a tuple-like access to class members (plus a number of things atop of this). Maybe it should be called Tuple-like Element Access (TEA)? 2. The library can only provide tuple-like access to classes that meet certain criteria, but these criteria are not obvious. Calling it an aggregate-initializable struct is not good enough: ``` struct B {}; struct D : B { int i, j; }; ``` Struct D is an aggregate (in C++20) and can be aggregate-initialized with three elements, but will not work with the library. I suggest you list requirements and give them a name. Bjarne Stroustrup called something similar a "flat": https://www.youtube.com/watch?v=ERzENfQ51Ck&feature=youtu.be&t=376 but I am not sure if this is the right one. Maybe "simple aggregate". This would help users prepare for what to expect. I do not know if this can be statically tested (like if a class has any base) but this does not matter as long as the requirements are listed in the docs. This concept is core to the library. 3. Does this library bring any value for arrays? It works for arrays, but arrays already provide index-based element access. 4. Thank you for writing and sharing this library. I really like it. Regards, &rzej;

4 3

[review][pfr] PFR review
by Hadriel Kaplan 02 Oct '20

02 Oct '20

Howdy, I vote to ACCEPT PFR into boost. It provides a form of reflection in a simpler manner than other solutions thus far, and for the types it can handle it’s really slick. My only minor complaint is with streaming, as discussed below. I’d also like to thank the author for responding to issues quickly on GitHub, and for bringing it to boost! - What is your evaluation of the design? Good.(?) I'm not sure how to differentiate this question from the implementation question, for this type of library. - What is your evaluation of the implementation? I didn’t study the internals, but rather used it as a user of the library. It has some behaviors I don’t personally like, but fundamentally it does what it says as far as I can tell. My only complaint is that unsigned char and signed char (and thus uint8_t and int8_t) are streamed as their char values, and thus as their unadorned ASCII characters. Since they can be non-printable values, I consider this behavior undesirable. Even as printable characters it is confusing to see - especially if the value happens to be a numeric character or a space or linefeed or whatever. The author pointed out I can choose to _not_ use the provided streaming operator, but instead roll my own streaming operator - and I did so. But I still think it’s not what the implementation should do out-of-the-box as a Boost library. Lots of aggregate types use uint8_t/int8_t for fields, I think. For example network protocol headers, data-driven-design structures to minimize cache line usage, bit fields, etc. Many (most?) people would have to write their own streaming operator due to this issue. Also, I’m a bit concerned with forward-compatibility. The definition of what constitutes an aggregate type is changing slightly in C++20, and becoming stricter I believe; so I’m worried users might find they can’t upgrade to C++20 while still using PFR for some types. But I don’t have a C++20 compiler easily available to me, so I can’t prove this to be an issue or not. (perhaps it’s not an issue at all) - What is your evaluation of the documentation? Good. It explains what needs to be explained, in a brief but reasonable manner. I didn’t study it that closely, however. - What is your evaluation of the potential usefulness of the library? In some ways this is a tough question to answer - in others it’s easy. It’s easy because - for the aggregate types it can support - it is far simpler than any other solution I know of, and thus very useful. But it’s also difficult to answer because at least for the code base in my day job, and everywhere I have worked previously, very few class/struct types would be usable with it in practice. It is not the case that it supports every aggregate type - it cannot (currently) support ones with empty base classes, including CRTP-based empty bases. We happen to use CRTP frequently in my code base; for example boost::operators. And we have a lot of data structures that are _almost_ aggregates, except they end up having either one or more private members, or user-provided constructors, or unions, or whatever. Even types in our data-driven-design code areas, ended up not being true aggregates over time. But this is not something PFR can fix or address, as far as I’m aware, nor a reason to reject it - I’m merely pointing it out as something that reduces the applicability of such an approach. (Ironically PFR is making me consider changing some of them to be true aggregates, just so that we could use PFR - so I guess in that way it’s good? :) I presume, however, that there are plenty of code bases that have lots of true aggregates, and without empty bases - and for them it would be _extremely_ useful I would think. - Did you try to use the library? Yes. I did NOT try every possible operation that PFR makes available - I mostly only did streaming/printing, iteration, and member access by index. - With which compiler(s)? Gcc 7.3, C++17 mode. - Did you have any problems? My biggest problem was finding a C++ type in my code base that PFR could support. :) There was also the printing/streaming issue described earlier. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Just a few hours of using it. - Are you knowledgeable about the problem domain? No, not really. I have never tried implementing “reflection" without using macros that required the user to identify the type’s name and all of its members. (If one can call that “reflection”) As far as I’m concerned, PFR is black magic and if this were the 17th century I would report the author to church officials. -hadriel

5 7

[PFR] The user's perspective
by Andrzej Krzemienski 02 Oct '20

02 Oct '20

Hi Everyone, I am now trying to study the PFR library, and wanted to share some thoughts and see what others think. First, thanks Antony for writing and sharing this library. I have watched your video on it, read the docs, and I find it amazing that you were able to implement such reflection in C++. This is in the spirit of the good old Boost libraries that just implemented magic. Now, to the critique. From looking at the docs and the videos, I inferred (perhaps incorrectly) that the library was created in this order: "We can do type introspection for aggregates, so let's see to what extent we can provide an interface of a reflection library." The extent is quite amazing (e.g., I really appreciate having pfr::less<> out of the box), but to the end user, I think, the library will still appear as incomplete. That is, when my type is an aggregate it will work, but when I need to add a convenience constructor it will immediately break, and I will have to switch to another library, like Peter's Describe ( https://github.com/pdimov/describe/tree/master). With Describe, I will have to type more, but I have a guarantee of a uniform experience both for aggregates and for other types. And given that I have to use Describe at some point there may be no point in also keeping PFR and forcing on myself and my colleagues two different interfaces. Describe is not a perfect solution either, because for aggregates I have to declare the mapping, which is unnecessary as PFR has demonstrated. My ideal solution would be if these two libraries (PFR and Describe) would be merged into one, so that: 1. They provide the same interface 2. A user can easily instruct the library: "this is an aggregate: figure out the mapping yourself". I am sorry if it sounds arrogant: people are devoting their private time to write and share a cool library, and all they hear back is "do more." But I thought it would also be unfair not to give this feedback. I am also not sure if the goals of the two libraries are compatible (e.g., Describe is also interested in giving names of the members) . I would be curious to see what the authors think about it. Regards, &rzej;

5 6

Cache Size
by Matt Borland 01 Oct '20

01 Oct '20

A recurring discussion in Boost.Math has been needing a cross-platform way to query the L1D cache size of a machine. I have most of a solution in a [personal repo](https://github.com/mborland/cache). It did not make sense to us to have this in Boost.Math because it would be useful outside of that scope, but we did not know where it should go. Is there an existing library where this would fit? If necessary I can roll it into a library submission that exposes the functionality of CPUID. Matt

3 3