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