Re: [Boost-users] [fusion] BOOST_FUSION_DEFINE_STRUCT with user defined methods

Subject: Re: [Boost-users] [fusion] BOOST_FUSION_DEFINE_STRUCT with user defined methods
From: Damien Buhl (damien.buhl_at_[hidden])
Date: 2014-09-13 11:52:50

On 09/11/2014 06:52 PM, pfultz2 wrote:
>> Which would use the same techniques that Abel Sinkovics metaparse to
>> parse the struct and automatically expand to the boilerplate template
>> code for Boost.Fusion. 
> 
> 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.

>> I'm naturally open for a first iteration in this direction to see how we
>> could change the DEFINE_STRUCT to allow adding own code to the structs
>> from your experience. 
> 
> 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 ?

> 
> And then we could have another `INLINE_CONSTRUCT` that will generate the
> constructor:
> 
>     struct person : equality<person>, streamable<person>
>     {
>         BOOST_FUSION_INLINE_CONSTRUCT(person,
>             (std::string, name)
>             (int, age)
>         );
>     };
> 
> Then for those that want a define all together, we could have a macro like
> this:
> 
>     BOOST_FUSION_DEFINE(person, equality<person>, streamable<person>)
>     (
>         (std::string, name)
>         (int, age)
>     )
> 
> So that way the user can add in the behaviours they want through
> inheritance.
> 
> Additionally, we could also switch the type and field name order so we could
> handle types with commas in it:
> 
>     struct person : equality<person>, streamable<person>
>     {
>         BOOST_FUSION_INLINE(
>             (name, std::string)
>             (age, int)
>             (locations, std::map<std::string, int>)
>         );
>     };
> 
> Plus, by reversing the order we could handle the associative keys with same
> macro:
> 
>     struct person : equality<person>, streamable<person>
>     {
>         struct keys
>         {
>             struct name {};
>             struct age {};
>             struct locations {};
>         }
>         BOOST_FUSION_INLINE(
>             (name, std::string, keys::name)
>             (age, int, keys::age)
>             (locations, std::map<std::string, int>, keys::locations)
>         );
>     };
> 
> I could add some pull requests for this, starting with the enable
> parameters,
> if there is interest in something like this. Of course, this is difference
> than Damien's work, which looks it was making the type optional in the
> adapts
> macros.

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.

> 
> Paul Fultz II
> 
> 
> 
> 
> 
> --
> View this message in context: http://boost.2283326.n4.nabble.com/fusion-BOOST-FUSION-DEFINE-STRUCT-with-user-defined-methods-tp4666985p4667491.html
> Sent from the Boost - Users mailing list archive at Nabble.com.
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>