Boost logo

Boost Users :

Subject: Re: [Boost-users] [fusion] BOOST_FUSION_DEFINE_STRUCT with user defined methods
From: Damien Buhl (damien.buhl_at_[hidden])
Date: 2014-08-29 02:23:48


Hi Joel and Tobias,

Sorry I wasn't on Boost Users, I was only looking at devel, but now it's
done. Thank you Joel for forwarding.

My replies below :

On 08/28/2014 05:09 AM, Joel de Guzman wrote:
> On 8/27/14, 2:07 PM, Tobias Loew wrote:
>> Hi,
>>
>> I often use BOOST_FUSION_DEFINE_STRUCT not to generate a
>> fusion-sequence per
>> se, but to get a struct with
>>
>> - default initialisation for all members
>> - a reasonable set of constructors
>> - equality-check
>> - all above without additional code
>>
>>
>> But sometimes I would like to have additional methods in those
>> structs, but
>> deriving from those or fusion-adapting them loses at least one of the
>> nice
>> properties above.
>> After looking at the BOOST_FUSION_DEFINE_STRUCT implementation I though
>> about splitting the makro BOOST_FUSION_DEFINE_STRUCT_IMPL an inject my
>> code
>> in-between.
>> Now my questions are:
>>
>> - Is there anything I've overseen and might detroy some fusion-mechanism?
>> - Is there any chance to get macros like
>> BOOST_FUSION_DEFINE_STRUCT_[BEGIN|END] (and also for the other
>> BOOST_FUSION_DEFINE_... macros?

Actually I'm not so much a fan of the DEFINE_STRUCT macros in their
current state, and I would prefer something new (just thinking outloud)
like this :

```cpp

BOOST_FUSION_ADAPT_STRUCT(
        {
                add_constructors=true,
                default_initialize_members=true
        },
        (struct mystruct {
                public:
                        int i;
                        int member2;
        }));

```

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.

But as this is bleeding edge and will take longer (i.e. I didn't start
anything in this direction, I'm just playing a bit with metaparse and
thinking how it could be done),

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.

Currently I have to finish the ADAPT_ macros which are doing type
deduction for declared field (actually I'm just missing the ADT_ASSOC
and I'm done, but I've been alot busy last month).

And if you want we can start something together Tobias to see where we
will land in changing the DEFINE_STRUCT with a BEGIN and END.

Would you like to work together on this ? I believe we can do something
which won't break the existing DEFINE macros and allows adding own code
to the defined struct.

>
> The only problem I see is that the mechanism is private and is not
> guaranteed to remain unchanged.
Yes if Tobias copy/paste the code in it's project and split the macro
this maybe broken by future versions of Boost.Fusion as the
BOOST_FUSION_DEFINE_STRUCT_IMPL is private.

>From a user point-of-view without copy pasting the whole
BOOST_FUSION_DEFINE_STRUCT implementation there is no guarantee that it
won't break.

Because it could be so that we add new extensions and so to the struct.
This is dangerous for Tobias's code, as he wouldn't necessarily see why
it's code is failing when using newer boost.

We cannot give the guarantee that what the official macros do won't
change. Tobias you are probably aware of this, but that means that
you'll have to update your macros each time you make a boost update, or
at least check they are still the same, until we get the feature
upstream. :)

> Actually there's work in progress
> cleaning up the macros and the implementation by Damien Buhl.
> CC'ing him now. Your thoughts, Damien?

>
> Regards,

Cheers,

--
Damien Buhl

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