[Describe] Clarification on the library scope
Hi Everyone, First of all, I wanted to thank Peter for writing and sharing this library. A number of people already indicated it is useful, and I also have use cases that would be addressed by this library. I would lie to clarify if my understanding of the scope of this library is correct. From the discussion so far, I understood that the goal is to provide a low-level minimum building block that enables writing more elaborate libraries for providing type introspection. The library gives me the following guarantee: if a user used macro BOOST_DESCRIBE_STRUCT for some type T (and there are no ODR violations) than I can use `boost::describe::members` to see what those members are: their name, their type, and a pointer. If I want to use this data in a convenient way, I have to use another library atop of Boost.Describe. For instance, when I need to observe struct X as a tuple of references, I will write my own library, which: 1. Checks if Boost.PFR can figure it out automagically. If so, use this magic 2. If not, resort to Boost.Describe, and based on its interface, form a tuple of references. Did I capture it correctly? In that case, requesting high-level features in Boost.Describe is against its design goals. It is a low-level piece, not necessarily to be used directly. Regard, &rzej;
On 3/8/2021 6:20 AM, Andrzej Krzemienski via Boost wrote:
Hi Everyone, First of all, I wanted to thank Peter for writing and sharing this library. A number of people already indicated it is useful, and I also have use cases that would be addressed by this library.
I would lie to clarify if my understanding of the scope of this library is correct. From the discussion so far, I understood that the goal is to provide a low-level minimum building block that enables writing more elaborate libraries for providing type introspection. The library gives me the following guarantee: if a user used macro BOOST_DESCRIBE_STRUCT for some type T (and there are no ODR violations) than I can use `boost::describe::members` to see what those members are: their name, their type, and a pointer.
If in a template a class ( typename ) template parameter has been Described with the BOOST_DESCRIBE_STRUCT or BOOST_DESCRIBE_CLASS macro you will be able to use the Describe library's describe_bases<T, M> and describe_members<T, M> function templates to introspect that template parameter. You can do the same thing if your template parameter is an enumeration and you can use the describe_enumerators<E> functionality. This lets you treat class/structs and enumerations generically in template code as to what functionality they may contain. What use you make of the information is up to you. This is my own interpretation of the Describe library and why I voted to ACCEPT it as being useful in Boost. I do hope in the future of C++ that C++ reflection information can be automatically generated by the compiler rather than manually generated by what Peter has done and others may do, as Peter has stated in the documentation what the limitations Describe has in regard to class/structs. As others have pointed out also, class/structs in third-party libraries, to which the code is not available, as in the C++ standard library, can not be manually annotated with the Describe macros. Nonetheless the library can be certainly useful for Boost users.
If I want to use this data in a convenient way, I have to use another library atop of Boost.Describe. For instance, when I need to observe struct X as a tuple of references, I will write my own library, which:
1. Checks if Boost.PFR can figure it out automagically. If so, use this magic 2. If not, resort to Boost.Describe, and based on its interface, form a tuple of references.
Did I capture it correctly? In that case, requesting high-level features in Boost.Describe is against its design goals. It is a low-level piece, not necessarily to be used directly.
Regard, &rzej;
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Andrzej Krzemienski wrote:
Hi Everyone, First of all, I wanted to thank Peter for writing and sharing this library. A number of people already indicated it is useful, and I also have use cases that would be addressed by this library.
I would lie to clarify if my understanding of the scope of this library is correct. From the discussion so far, I understood that the goal is to provide a low-level minimum building block that enables writing more elaborate libraries for providing type introspection. The library gives me the following guarantee: if a user used macro BOOST_DESCRIBE_STRUCT for some type T (and there are no ODR violations) than I can use `boost::describe::members` to see what those members are: their name, their type, and a pointer.
If I want to use this data in a convenient way, I have to use another library atop of Boost.Describe. For instance, when I need to observe struct X as a tuple of references, I will write my own library, which:
1. Checks if Boost.PFR can figure it out automagically. If so, use this magic 2. If not, resort to Boost.Describe, and based on its interface, form a tuple of references.
The primary goal of the library is indeed to serve as a helper building block for other libraries, but I don't think the chronology as described (you'd write your own library on top of Describe) is what I had in mind. Rather, the intended use is that you already have written your own library, such as Boost.JSON. It provides customizable facilities for handling types in a certain way (value_to, value_from), and can handle a number of standard types (e.g. std::vector) by default, but not user-defined types, because it knows nothing about them. By using Describe, JSON can provide default handling for user-defined types as well, so that C++ to/from JSON conversions magically work out of the box without customizing value_to/value_from. (And the same example can be given with a serialization library, or a hashing library.) I wouldn't necessarily rule out the library being used directly by end users though. It's not very friendly in this initial form, but it's usable, and convenience functions will eventually get added.
participants (3)
-
Andrzej Krzemienski
-
Edward Diener
-
Peter Dimov