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-us... Sent from the Boost - Users mailing list archive at Nabble.com. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users