- Boost - lists.preview.boost.org

[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

[review][json] My review
by Gavin Lambert 30 Sep '20

30 Sep '20

- Do you think the library should be accepted as a Boost library? Yes, my vote is to ACCEPT this library. - What is your evaluation of the design? Much has been debated recently on the merits of push parsers vs. pull parsers. Boost.JSON provides both a push parser (SAX-like interface) and a DOM parser (which is somewhat pull-like but I don't think is technically either kind). It does not provide a "real" pull parser, which are sometimes more efficient for deserialisation into custom types; the SAX parser can somewhat do that but is not composable, which makes it harder to use in practice, unless I'm missing something (this is usually why I end up never using SAX parsers). If so, I'd like to see a more complete example where the handler delegates part of the parsing to a class that in turn delegates part to another class (as with reading typed sub-values). I don't think this is currently possible. So I think I can understand some of the debate around this point; while I don't think it's strictly necessary that this particular library implement that, if it doesn't then another library will end up having potentially competing types and the natural Boost.Json name will already be taken. Personally, however, I don't think this is sufficient reason to block acceptance of this library. Direct pull parsing doesn't mesh well with JSON, due to the requirement to tolerate reordered keys, so any non-defective parser would have to have something DOM-like under the hood anyway. (Some kind of cache, if not necessarily a traditional DOM.) As such it should be sufficient to use json::value itself as part of a pull-like parsing interface. Regarding the SAX parser specifically, I dislike the *_part methods in the callback interface. I feel that these should be removed and only the final form retained, called only when the complete text of the value has been determined. I don't feel it is ever sensible to call back with a partially-parsed value (unless I am misunderstanding what these are for, but there is little explanation in the docs, and I wasn't able to get them called at all in my test). I also don't see the point of supplying a size argument to on_key* and on_string, as this can be read from the string_view argument instead. The various number methods don't pass this separately. Similarly, having a bool return as well as an error_code output argument seems peculiar; one or the other should be sufficient, as is it just invites inconsistency. parser.write() is incremental but basic_parser.write() is not, which seems odd. I assume this means that parser is storing an incrementally populated buffer of the full document rather than _really_ incrementally parsing. parse/parser do not appear to support consuming only part of the supplied input as a complete JSON value (returning how much was consumed), which is useful for streams where multiple objects are concatenated without explicit separation. Regarding other aspects of design, I haven't drilled down in great detail but the basic interface seems reasonably sound, other than the concerns raised above. I have mixed feelings on the initializer-list construction method -- I like that there is some method of doing this, and it seems like idiomatic C++ (particularly regarding how key-value pairs appear), but also very non-JSON -- an array of objects ends up having three nested braces. But I don't have any specific suggestion for improvement. - What is your evaluation of the implementation? It seems unfortunate (though understandable, due to heap allocation) that you cannot declare a json::value / json::object as constexpr, for cases where you do want some kind of constant reference object (e.g. a schema description). You can somewhat work around this by declaring the JSON as a constexpr string_view and later parsing it to a non-constexpr json::value, but that seems a bit awkward (and potentially bad-perf-prone if someone parses it multiple times). Otherwise I didn't really look into the implementation at all. - What is your evaluation of the documentation? Overall, good, if perhaps a bit sparse on some aspects. One pet peeve however is that most of the examples appear to be written as if "using namespace boost::json" is in effect, which I feel both encourages bad practice and makes it harder to distinguish which types are provided by the library vs. exist only for the example. This is especially confusing in the examples for tag_invoke, but not only there -- another example of confusion are the aliases for types present in both boost and std namespaces. I strongly recommend going through and changing these to explicitly use a json:: namespace prefix on all library types (including the boost/std aliases). Brevity is useful, but not at the expense of clarity. The "Using Numbers" section of the docs appears to be entirely blank. "serializer can be used to incrementally serialize a value incrementally" (redundant words are redundant) (On a related note, an example use case for serializer is listed as "ensure a fixed amount of work is performed in each cycle", but the only means of control is the length of the provided buffer. I guess this is equating work to number of characters output, which seems dubious. But I have no specific objections.) - What is your evaluation of the potential usefulness of the library? The library seems well suited for JSON as inter-process/network data interchange, other than perhaps the omission of partial input parsing. It seems less suited for JSON as configuration file -- while it can parse such files (via common extensions such as ignoring comments and trailing commas) it lacks means to pretty-print and to round-trip the comments, which would be essential if writing back a config file intended for human use. However while supporting this use case would be nice, I don't consider it mandatory. - Did you try to use the library? With what compiler? Did you have any problems? I tried it out with MSVC 2017 in standalone header-only mode, though only with a few small examples. The basic_parser examples do not compile out of the box -- with the suggested json.hpp and src.hpp includes there are link errors with basic_parser symbols. Additionally including basic_parser.hpp resolves these but starts complaining about missing max_{key,string,array,object}_size members of the handler type, which are not documented. After these are supplied then it works as expected. I don't see why these should be needed, however. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Roughly four hours over a few days reviewing docs and trying some small experiments. - Are you knowledgeable about the problem domain? I have some apps that use JSON as both interchange and configuration storage formats, although most of these do not use C++. So, "somewhat".

9 23

Review Manager needed for Boost.Lambda2
by Peter Dimov 30 Sep '20

30 Sep '20

Greetings, Some time ago I wrote a blog post, https://pdimov.github.io/blog/2020/07/22/a-c14-lambda-library/, which described how a simple lambda library can be implemented in ~50 lines using the facilities already available in C++14's <functional> standard header. I turned this into a mini-library, https://github.com/pdimov/lambda2, and I'd like to submit that to Boost. I'm looking for a review manager. The library is trivial, so managing the review should be as easy as theoretically possible for a Boost review. Thanks in advance.

7 20

new macros
by Gero Peterhoff 28 Sep '20

28 Sep '20

Hello Developer, can you please provide these 2 macros: - BOOST_HAS_LIB_INT128 - BOOST_NO_INT8_T and there is another bug in boost::is_unsigned with char8_t. See https://godbolt.org/z/o8z1aq thx Gero

1 0

[review][JSON] json::value as a vocabulary type
by Andrzej Krzemienski 26 Sep '20

26 Sep '20

Hi Everyone, I have heard this claim a number of times: json::value is suitable for a vocabulary type. I am not sure what that actually means: no templates? Guarantee that layout or mangled symbol will never change? Anything else? My understanding of a "vocabulary type" is that it should be usable (not necessarily with maximum efficiency) for *any* usage. In the case of JSON that would mean that I should be able to represent any value that corresponds to a valid JSON when converted to text. I do not think that json::value can claim that without the ability to serialize arbitrarily big numbers. I understand that the goal of the library is to address the most common cases, and big numbers do not fall into this category. I am just saying that the name "vocabulary type" may not be accurate here. Regards, &rzej;

11 25

Changing virtual memory amount in Appveyor and Travis CI tests
by Edward Diener 25 Sep '20

25 Sep '20

Is it possible through .yml file for Appveyor and Travis CI to change the amount of virtual memory when running a CI test. I am running CI tests for Boost PP which heavily use the preprocessor, and some of the extended tests I am running fail on both Appveyor and Travis CI with out of memory conditions while on my own local computer, with about 32 GB of ram, the tests succeed. I think in the real world most users now have at least 32 GB of ram or more, while these virtual environments in Appveyor and/or Travis CI probably run their tests with much less overall virtual memory than an average user would have.

4 12

Re: [boost] Endorsement, review manager sought for Boost.Describe
by Peter Dimov 24 Sep '20

24 Sep '20

> Vinícius dos Santos Oliveira wrore: > > Hi Peter, > > > > could you consider using "compile-time strings" such as Hana's? I don't > > have much use for a const char* in TMP algorithms. > > The descriptor strings are "compile-time". This, for instance, works. ... Here's how you can get a Hana string: #include <boost/describe.hpp> #include <boost/mp11.hpp> #include <boost/hana.hpp> #include <cstddef> using namespace boost::describe; using namespace boost::mp11; enum E { v1 }; BOOST_DESCRIBE_ENUM(E, v1) constexpr std::size_t strlen_( char const * s ) { std::size_t n = 0; while( *s++ ) ++n; return n; } template<class D, std::size_t... I> constexpr auto to_string_impl( index_sequence<I...> ) { return boost::hana::string_c<D::name[I]...>; } template<class D> constexpr auto to_string() { return to_string_impl<D>( make_index_sequence<strlen_(D::name)>() ); } using D = mp_first< describe_enumerators<E> >; constexpr auto st = to_string<D>(); #include <typeinfo> #include <cstdio> int main() { std::printf( "%s\n", typeid(st).name() ); }

1 0