On 9/12/14, 12:52 AM, 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'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) ); };
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.
I like this! Can we somehow merge this with Damien's work? Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/