Boost logo

Boost Users :

Subject: Re: [Boost-users] [fusion] BOOST_FUSION_DEFINE_STRUCT with user defined methods
From: pfultz2 (pfultz2_at_[hidden])
Date: 2014-09-15 00:03:43


> >
> > I don't think metaparse can be used for this. It can't reference the
> members
> > in the struct.
> >
>
> I don't see why it couldn't, as it can parse strings at compile time and
> generate therefore the types needed for a struct to be adapted. We are
> probably referring to a different mechanism of metaparse.

Yes you can parse a string and have it generate a template type, but you
can't
create a template that accesses a member by a name that is in the string.
That
is templates can't map a string to a symbol names. For example, say you want
to access members as single letters:

    struct point
    {
        int x;
        int y;
    };

    point p{};
    access<'x'>::get(p) = 5; // Set the 'x' member field to 5

Now you can't write this access class:

    template<char MemberName>
    struct access
    {
        template<class T>
        static auto& get(T& x)
        {
            return x.MemberName; // This isn't possible
        }
    };

Of course, you could specialize the template for every possible `char`
input,
but that just isn't feasible. The only way is to use the preprocessor.

> > As a first iteration, it would be nice if the extension metafunctions(ie
> > `access::struct_member`, `struct_member_name`, `struct_assoc_key`) would
> > provide an enable parameter. This would allow the struct definitions to
> be
> > inline. Boost.Fusion already provides `INLINE_STRUCT` but it doesn't
> provide
> > the member name nor an associative key.
> >
> > When we have the members inline, we can then inherit from the base
> operators
> > we would like for the class:
> >
> > struct person : equality<person>, streamable<person>
> > {
> > BOOST_FUSION_INLINE(
> > (std::string, name)
> > (int, age)
> > );
> > };
>
> with BOOS_FUSION_INLINE, you mean BOOST_FUSION_DEFINE_STRUCT_INLINE no ?

Well, thats what im referring to. However, we may want to have a different
name for two reasons:

1) If we switch the order of the variable and type so it can handle types
with
  commas in them, this will break backwards compatibility.

2) There is a lot of work that has been done to get the current
  `BOOST_FUSION_DEFINE_STRUCT_INLINE` to work on older compilers. Changing
the
  implenetation could affect that, and I dont really have access to some of
  those older compilers.

> This is naturally different, as we have two different use-cases :
>
> 1. existing structs that we want to adapt (we don't want to repeat the
> type there)
> 2. Directly defining structs (we want to declare the type) as boost
> fusion enabled types.
>
> What I'm doing is for the use case 1. and this only touch ADAPT_STRUCT
> macros, what you are proposing is for the 2nd use case which extends
> DEFINE_STRUCT macros.
>
> So concurrent work won't collide, eventually we can do this in the same
> repository ? I can give you access to mine or we can open up a
> mini-organization on github (e.g. boost-fusion-staging) to handle this
> work, so that we can then make a clean pull-request to the official repo.
>
> @Tobias Loew would it also solve your problems? Or do you still think
> modifying BOOST_FUSION_DEFINE_STRUCT would be better ?
>
> Could we work all three together on this? We just have to cleanly define
> who does what to avoid being slowed down by each other (all doing the
> same differently). I'm soon finished with the ADAPT_* macros, so I'll be
> able to focus on this.

Yes, we shouldn't collide. I can start something in my repo, and either open
a
pull request to your repo, or I could directly to Boost.Fusion and you and
Joel can take a look at it. I'll try to come up with something this week.

Paul Fultz II

--
View this message in context: http://boost.2283326.n4.nabble.com/fusion-BOOST-FUSION-DEFINE-STRUCT-with-user-defined-methods-tp4666985p4667580.html
Sent from the Boost - Users mailing list archive at Nabble.com.

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net