On 21/07/2014 6:53 PM, Mathias Gaunard wrote:
On 15/07/14 14:45, Michael Shepanski wrote:
Could you clarify what you mean by "do this"? QUINCE_MAP_CLASS builds a class with exactly the data members, function members, and bases that quince requires.
Boost.Fusion defines tuple concepts, and provides utilities to adapt a class to a tuple (or define a class and adapt it at the same time).
To maximize compatibility, and to prevent users having to say that their structure is tuple-like a billion times, it's better to reuse this.
So you are suggesting that users who want to say QUINCE_MAP_CLASS be made to say BOOST_FUSION_ADAPT_STRUCT instead? I see that BOOST_FUSION_ADAPT_STRUCT asks users to repeat the members' types, in a way that QUINCE_MAP_CLASS doesn't. (Why is that, btw?) I don't (yet) see how BOOST_FUSION_ADAPT_STRUCT could be used to replace QUINCE_MAP_CLASS_WITH_BASES. Also I don't see how any of this is going to produce the mapper classes with all the specific features that the rest of quince needs. I think that would be an extra step.
Any type that is Fusion-compatible should be made compatible with your library too.
Quince already allows std::tuples to be mapped types. So I guess quince could, similarly, allow fusion sequences to be mapped types. Then a user who has a class could indeed choose to get it mapped by the circuitous route of adapting it to a Fusion sequence and then mapping that. (It wouldn't be my choice, but to each his own.)
Also, building as you do seems quite intrusive. You probably want to support a non-intrusive approach anyway.
What do you mean? --- Michael