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-15 15:39:50

On 09/15/2014 06:03 AM, pfultz2 wrote:
>>>
>>> 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.

I wasn't referring to access classes, in fact I want to implement a C++
declaration parser that would expand to the templates instantiation
needed by Boost.Fusion. This is crazy and would take ages to compile,
but with a subset of metaparse specific for the job it could be usable
on modern compilers.

> 
>>> 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 may however be better for maintenance of all the code, but start it
aside, and we can see how we can merge this then it works for one
compiler. I'm currently setting up a farm of virtual appliances to test
all those compilers, especially to test my patch for the ADAPT_STRUCT.
I'll give you access too, to the buildbots.

> 
>> 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

Then to avoid slowing you down, do it directly to the repository of
boostorg/fusion when you'll be finished, don't stress that's open source
;). I'll follow your repo and watch all pull-requests to boostorg/fusion
so I would comment there too, where are you on github ?

Don't hesitate to ask for what you would need me when you'll be deeper
in your draft, possibly is Tobias Loew also interested and would also
want to know how to help.

Cheers,
--
Damien Buhl