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

[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