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