Re: [Boost-users] [Fusion] Associate arbitrary compile/runtime annotations with members of fusion sequence

Subject: Re: [Boost-users] [Fusion] Associate arbitrary compile/runtime annotations with members of fusion sequence
From: Kozlov Taras (kozlov.taras_at_[hidden])
Date: 2013-02-24 17:31:14

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.