[Describe] Boost.Describe vs Boost.Fusion
Hi Everyone (but mainly Peter), Boost.Spirit needs to have an index-based access to user defined types, as explained in the tutorial: https://www.boost.org/doc/libs/1_75_0/libs/spirit/doc/x3/html/spirit_x3/tuto... Currently Boost.Spirit uses the interface of Boost.Fusion, and users are encouraged to use macros like BOOST_FUSION_ADAPT_STRUCT: https://www.boost.org/doc/libs/1_75_0/libs/fusion/doc/html/fusion/adapted/ad... The first question is, can Boost.Describe's interface be plugged into Boost.Spirit? It is not that obvious to me for a couple of reasons. For instance, it would require an interface in Boost.Describe for answering the question, "has describe::members been specialized for type X"? The second question is, can is Boost.Describe capable of replacing the adapter macros in Boost.Fusion? For instance, Boost.Fusion allows the users to define and adapt a user defined type with one macro: https://www.boost.org/doc/libs/1_75_0/libs/fusion/doc/html/fusion/adapted/de... This is similar in concept to what macro BOOST_DEFINE_ENUM does for enums. What is the motivation behind allowing the definition of enums in this way but not classes (at least the aggregate classes). My general observation is that we have a number of libraries with overlapping goals: Boost.Describe, Boost.PFR, Boost.Fusion (the part for adapting UDTs) Maybe it is ok, but does it mean that there are so many incompatible use cases? Maybe there is a way to reduce this number. Regards, &rzej;
On 3/2/2021 8:48 AM, Andrzej Krzemienski via Boost wrote:
Hi Everyone (but mainly Peter), Boost.Spirit needs to have an index-based access to user defined types, as explained in the tutorial: https://www.boost.org/doc/libs/1_75_0/libs/spirit/doc/x3/html/spirit_x3/tuto... Currently Boost.Spirit uses the interface of Boost.Fusion, and users are encouraged to use macros like BOOST_FUSION_ADAPT_STRUCT: https://www.boost.org/doc/libs/1_75_0/libs/fusion/doc/html/fusion/adapted/ad...
The first question is, can Boost.Describe's interface be plugged into Boost.Spirit? It is not that obvious to me for a couple of reasons. For instance, it would require an interface in Boost.Describe for answering the question, "has describe::members been specialized for type X"?
The second question is, can is Boost.Describe capable of replacing the adapter macros in Boost.Fusion? For instance, Boost.Fusion allows the users to define and adapt a user defined type with one macro: https://www.boost.org/doc/libs/1_75_0/libs/fusion/doc/html/fusion/adapted/de...
This is similar in concept to what macro BOOST_DEFINE_ENUM does for enums. What is the motivation behind allowing the definition of enums in this way but not classes (at least the aggregate classes).
My general observation is that we have a number of libraries with overlapping goals: Boost.Describe, Boost.PFR, Boost.Fusion (the part for adapting UDTs)
Maybe it is ok, but does it mean that there are so many incompatible use cases? Maybe there is a way to reduce this number.
Boost.Fusion/Boost.Spirit are C++03 libraries while Describe is a C++14 library. So while Describe might be capable of replacing the BOOST_FUSION_ADAPT_STRUCT interface in Boost.Fusion I would imagine that Boost.Fusion/Boost.Spirit might have to upgrade their minimum C++ level to C++14 in order to do so. I agree with you that having multiple libraries use a common interface is certainly desired, and thought about the same thing you have expressed here when I read about the Describe macros.
wt., 2 mar 2021 o 15:05 Edward Diener via Boost <boost@lists.boost.org> napisał(a):
On 3/2/2021 8:48 AM, Andrzej Krzemienski via Boost wrote:
Hi Everyone (but mainly Peter), Boost.Spirit needs to have an index-based access to user defined types, as explained in the tutorial:
https://www.boost.org/doc/libs/1_75_0/libs/spirit/doc/x3/html/spirit_x3/tuto...
Currently Boost.Spirit uses the interface of Boost.Fusion, and users are encouraged to use macros like BOOST_FUSION_ADAPT_STRUCT:
https://www.boost.org/doc/libs/1_75_0/libs/fusion/doc/html/fusion/adapted/ad...
The first question is, can Boost.Describe's interface be plugged into Boost.Spirit? It is not that obvious to me for a couple of reasons. For instance, it would require an interface in Boost.Describe for answering the question, "has describe::members been specialized for type X"?
The second question is, can is Boost.Describe capable of replacing the adapter macros in Boost.Fusion? For instance, Boost.Fusion allows the users to define and adapt a user defined type with one macro:
https://www.boost.org/doc/libs/1_75_0/libs/fusion/doc/html/fusion/adapted/de...
This is similar in concept to what macro BOOST_DEFINE_ENUM does for
enums.
What is the motivation behind allowing the definition of enums in this way but not classes (at least the aggregate classes).
My general observation is that we have a number of libraries with overlapping goals: Boost.Describe, Boost.PFR, Boost.Fusion (the part for adapting UDTs)
Maybe it is ok, but does it mean that there are so many incompatible use cases? Maybe there is a way to reduce this number.
Boost.Fusion/Boost.Spirit are C++03 libraries while Describe is a C++14 library. So while Describe might be capable of replacing the BOOST_FUSION_ADAPT_STRUCT interface in Boost.Fusion I would imagine that Boost.Fusion/Boost.Spirit might have to upgrade their minimum C++ level to C++14 in order to do so.
Sorry, I wasn't clear. BoostSpirit comes with the x3 variant which already requires c++14: https://www.boost.org/doc/libs/1_75_0/libs/spirit/doc/x3/html/index.html I meant this one only. Regards, &rzej;
I agree with you that having multiple libraries use a common interface is certainly desired, and thought about the same thing you have expressed here when I read about the Describe macros.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Andrzej Krzemienski wrote:
wt., 2 mar 2021 o 15:05 Edward Diener via Boost <boost@lists.boost.org> napisał(a):
Boost.Fusion/Boost.Spirit are C++03 libraries while Describe is a C++14 library. So while Describe might be capable of replacing the BOOST_FUSION_ADAPT_STRUCT interface in Boost.Fusion I would imagine that Boost.Fusion/Boost.Spirit might have to upgrade their minimum C++ level to C++14 in order to do so.
Sorry, I wasn't clear. BoostSpirit comes with the x3 variant which already requires c++14: https://www.boost.org/doc/libs/1_75_0/libs/spirit/doc/x3/html/index.html I meant this one only.
That's true, but Spirit relies on Fusion for the support of user-defined structs, so the straightforward way to make it work on described types is to make Fusion recognize them. That's ifdefable and should be doable, but I don't have a proof at this time. :-)
wt., 2 mar 2021 o 16:34 Peter Dimov via Boost <boost@lists.boost.org> napisał(a):
Andrzej Krzemienski wrote:
wt., 2 mar 2021 o 15:05 Edward Diener via Boost <boost@lists.boost.org> napisał(a):
Boost.Fusion/Boost.Spirit are C++03 libraries while Describe is a C++14 library. So while Describe might be capable of replacing the BOOST_FUSION_ADAPT_STRUCT interface in Boost.Fusion I would imagine that Boost.Fusion/Boost.Spirit might have to upgrade their minimum C++ level to C++14 in order to do so.
Sorry, I wasn't clear. BoostSpirit comes with the x3 variant which already requires c++14: https://www.boost.org/doc/libs/1_75_0/libs/spirit/doc/x3/html/index.html I meant this one only.
That's true, but Spirit relies on Fusion for the support of user-defined structs, so the straightforward way to make it work on described types is to make Fusion recognize them.
Or have Spirit perform a check: if `describe::members` is found use it, otherwise fall back to Boost.Fusion. Regards, &rzej;
That's ifdefable and should be doable, but I don't have a proof at this time. :-)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Andrzej Krzemienski wrote:
wt., 2 mar 2021 o 16:34 Peter Dimov via Boost <boost@lists.boost.org> napisał(a):
That's true, but Spirit relies on Fusion for the support of user-defined structs, so the straightforward way to make it work on described types is to make Fusion recognize them.
Or have Spirit perform a check: if `describe::members` is found use it, otherwise fall back to Boost.Fusion.
That's possible, but it would require patching all uses of e.g. fusion::at_c in Spirit. It's easier to only add this support to fusion::at_c, which would not only take care of Spirit automatically, but of all other clients of Fusion.
wt., 2 mar 2021 o 18:02 Peter Dimov via Boost <boost@lists.boost.org> napisał(a):
Andrzej Krzemienski wrote:
wt., 2 mar 2021 o 16:34 Peter Dimov via Boost <boost@lists.boost.org> napisał(a):
That's true, but Spirit relies on Fusion for the support of user-defined structs, so the straightforward way to make it work on described types is to make Fusion recognize them.
Or have Spirit perform a check: if `describe::members` is found use it, otherwise fall back to Boost.Fusion.
That's possible, but it would require patching all uses of e.g. fusion::at_c in Spirit. It's easier to only add this support to fusion::at_c, which would not only take care of Spirit automatically, but of all other clients of Fusion.
Ok, I now have a better understanding of the matter. BoostFusion ADAPT macros and Boost.Describe have different purpose and scope. The goal of Boost.Describe is to emulate static reflection of declarations in C++. The goal of ADAPT macros in Boost.Fusion is to adapt a given class type as a fusion sequence. This does not require respecting the data members of the struct. For instance, I may have a struct `Point` that stores Cartessian coordinate in 2D space, but when adapting as a fusion sequence, I may want the data to be set as polar coordinates: ``` struct Point { double x; double y; double get_distance() const; double get_angle() const; void set_distance(double r); void set_angle(double a); }; BOOST_FUSION_ADAPT_ADT( Point, (obj.get_angle(), obj.set_angle(val)) (obj.get_distance(), obj.set_distance(val))) ``` This is orthogonal to having reflection of structures. I would still like Boost.Spirit to operate with Boost.Describe, but I do not know how that maps on the idea for adapting Boost.Fuson to work with Boost.Describe, and if the latter would be consistent with Boost.Fusion design goals. Regards, &rzej;
Andrzej Krzemienski wrote:
Hi Everyone (but mainly Peter), Boost.Spirit needs to have an index-based access to user defined types, as explained in the tutorial: https://www.boost.org/doc/libs/1_75_0/libs/spirit/doc/x3/html/spirit_x3/tuto... Currently Boost.Spirit uses the interface of Boost.Fusion, and users are encouraged to use macros like BOOST_FUSION_ADAPT_STRUCT: https://www.boost.org/doc/libs/1_75_0/libs/fusion/doc/html/fusion/adapted/ad...
The first question is, can Boost.Describe's interface be plugged into Boost.Spirit?
I'll need to take a closer look at Fusion to be able to tell; it _should_ be possible.
It is not that obvious to me for a couple of reasons. For instance, it would require an interface in Boost.Describe for answering the question, "has describe::members been specialized for type X"?
describe_members<T, M> fails substitution when not specialized, which can be used as a check. The examples use this to implicitly disable their overloads. E.g. the overload ``` template<class T, class Bd = describe_bases<T, mod_any_access>, class Md = describe_members<T, mod_any_access>> std::ostream& operator<<( std::ostream & os, T const & t ) { ``` will not be considered when T hasn't been described, because both describe_bases and describe_members will fail substitution.
The second question is, can is Boost.Describe capable of replacing the adapter macros in Boost.Fusion? For instance, Boost.Fusion allows the users to define and adapt a user defined type with one macro: https://www.boost.org/doc/libs/1_75_0/libs/fusion/doc/html/fusion/adapte d/define_struct.html
This is similar in concept to what macro BOOST_DEFINE_ENUM does for enums. What is the motivation behind allowing the definition of enums in this way but not classes (at least the aggregate classes).
I suppose this can be added, if there's demand. Taking the BOOST_DEFINE_ENUM macro seemed acceptable as there's currently no Boost library targeting enums, but BOOST_DEFINE_STRUCT is quite the land grab, and BOOST_DESCRIBE_DEFINE_STRUCT is just awkward. Typically, repeating the member names of an aggregate is less annoying than repeating the enumerators, but, as I said, we can add a DEFINE_STRUCT macro in principle if this is considered necessary and acceptable.
My general observation is that we have a number of libraries with overlapping goals: Boost.Describe, Boost.PFR, Boost.Fusion (the part for adapting UDTs)
+ Boost.Hana The aspiration is to have a single library that only deals with describing types so that others don't need to provide this functionality over and over. Although of course there's that classic xkcd. https://xkcd.com/927/ (The other aspiration is to make the describe_* primitives standard and compiler built-ins, so that the macros wouldn't be necessary. But at this point, it's not clear how feasible that is.)
participants (3)
-
Andrzej Krzemienski -
Edward Diener -
Peter Dimov