Boost logo

Boost :

Subject: Re: [boost] quince: queries in C++ expressions
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2014-07-21 11:57:38


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?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk