On 21/07/14 13:01, Michael Shepanski wrote:
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?
Your users might be already using Fusion, or using types that have already been made compatible with Fusion.
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?)
Because the type is needed.
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.
From what you described, you needed a way to list the members of a structure, like what can be done with tuples. This is what Fusion does.
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.)
There are plenty of classes all over Boost and elsewhere that are already Fusion compatible. Why not just use this concept instead of reinventing your own?