On 2/25/13 6:31 AM, Kozlov Taras wrote:
24.02.2013 6:46, Joel de Guzman пишет:
7. Generic question about adapt macroses in fusion.
I used BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF to define has_annotations metafunction that determine if type members were defined with CPPAN_DECLARE_AND_ANNOTATE. Then I wrote fusion extension which enables for arbitraty type if has_annotations<T> is true.
This approach allowed to move CPPAN_DECLARE_AND_ANNOTATE inside of struct definition.
Can BOOST_FUSION_DEFINE_STRUCT be reimplemented in that way? This will allow to get rid of namespaces sequence and struct_name parameters. I believe this will also make needless _TPL and _INLINE versions of BOOST_FUSION_DEFINE_STRUCT macroses.
Are there any compiler portability or design problems with such approach.
I'm not sure at the moment about the implications. If the tests pass, then that's a good indication that it's good.
To be honest, the fusion macros need a lot of time, attention and love right now. I'm not quite happy with the way they are implemented, to be frank. Just reading the code drives me nuts! It seems that you know your way around the macros. If you could find a good way to clean them up, then we should talk.
I'd love to see your extensions added, of course if you are interested in contributing and maintaining them; along with the other adapt/define macro- siblings. If you are interested, it would be crucial to have symmetry and uniformity. Thus to follow up on my answer above (***), if you intend to somehow have your code assimilated in fusion, then we cannot break the precedent and have a new way of doing things because that will confuse users.
Regards,
Well, I guess most of people would be happy to contribute something usefull into Boost, and I`m not an exception here :)
Here is how I see next generation of define and adapt macroses in fusion:
1. Intrusive.
BOOST_FUSION_DECLARE_MEMBERS( (base_type0)(base_type1)..., (member_type0, member_name0) (member_type1, member_name1) ... )
BOOST_FUSION_DECLARE_ASSOC_MEMBERS( (base_type0)(base_type1)..., (member_type0, member_name0, key_type0) (member_type1, member_name1, key_type1) ... )
Example:
struct name_key; struct age_key;
struct D : B1, B2 { BOOST_FUSION_DECLARE_ASSOC_MEMBERS( (B1)(B2), (std::string, name_, name_key) (int, age_, age_key) ) };
I believe we can easily reimplement current adapt macroses BOOST_FUSION_DEFINE_STRUCT BOOST_FUSION_DEFINE_TPL_STRUCT BOOST_FUSION_DEFINE_STRUCT_INLINE BOOST_FUSION_DEFINE_TPL_STRUCT_INLINE BOOST_FUSION_DEFINE_ASSOC_STRUCT BOOST_FUSION_DEFINE_ASSOC_TPL_STRUCT on top of them
Having BOOST_FUSION_DECLARE_ASSOC_MEMBERS will also make implementation of CPPAN_DECLARE_AND_ANNOTATE trivial.
2. Non-intrusive
As far as I see, each BOOST_FUSION_ADAPT_* macro should have _WITH_BASE paired macro with additional base type sequence parameter.
BOOST_FUSION_ADAPT_STRUCT_WITH_BASE( struct_name, (base_type0)(base_type1)..., (member_type0, member_name0) (member_type1, member_name1) ... )
I think I should move forward step by step:
1. Implement BOOST_FUSION_DECLARE_MEMBERS BOOST_FUSION_DECLARE_ASSOC_MEMBERS
2. Implement the most complex case from non-instrusive macroses. I guess that can be BOOST_FUSION_ADAPT_ASSOC_TPL_ADT_WITH_BASE
Hope this will help to get complete view of common implementation details between instrusive and non-instrusive macroses.
3. Reimplement current instrusive macroses based on new BOOST_FUSION_DECLARE_MEMBERS
4. Other version of _WITH_BASE non-intrusive macroses
5. Trivial reimplementation of current non-intrusive macroses based on _WITH_BASE versions.
Sounds wonderful! I'd also wish for a lot more tests, if you will :-) Let us follow up on this offline. Feel free to email me directly. Regards, -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/