[boost] [Describe] Boost.Describe vs Boost.Fusion
Andrzej Krzemienski via Boost
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/tutorials/employee.html
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/adapt_struct.html
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/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).
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;
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Edward Diener via Boost
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.
Peter Dimov via Boost
> 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/tutorials/employee.html
> 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/adapt_struct.html
>
> The first question is, can Boost.Describe's interface be plugged into
> Boost.Spirit?
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"?
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).
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)
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.)
Andrzej Krzemienski via Boost
napisał(a):
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;
Peter Dimov via Boost
> wt., 2 mar 2021 o 15:05 Edward Diener via Boost <bo...@lists.boost.org>
> napisał(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. :-)
Andrzej Krzemienski via Boost
napisał(a):
> Andrzej Krzemienski wrote:
> > wt., 2 mar 2021 o 15:05 Edward Diener via Boost <bo...@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;
Peter Dimov via Boost
> wt., 2 mar 2021 o 16:34 Peter Dimov via Boost <bo...@lists.boost.org>
> napisał(a):
>
> > 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.
Nikita Kniazev via Boost
otherwise fall back to Boost.Fusion.
a replacement that will work with both libraries.
Andrzej Krzemienski via Boost
napisał(a):
> Andrzej Krzemienski wrote:
> > wt., 2 mar 2021 o 16:34 Peter Dimov via Boost <bo...@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;