Subject: Re: [boost] quince: queries in C++ expressions
From: Michael Shepanski (mps_at_[hidden])
Date: 2014-07-21 22:02:57
On 22/07/2014 1:57 AM, Mathias Gaunard wrote:
>> I don't (yet) see how BOOST_FUSION_ADAPT_STRUCT could be used to replace
>> 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.
Yes, I need a way to list the members of a structure. And you assumed
that is all I needed -- am I right?
>>> 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?
Obviously I have given numerous answers already. I take this question as
a request for a summary.
In order to provide the syntax "points->x", I need a macro that
generates a class with member names that match the user's member names.
None of the admonitions about reinventing wheels etc. have shown how to
do that without the macro.
The objects I am dealing with are class-like rather than sequence-like,
in this sense: they have inheritance (including multiple inheritance). I
have asked how Boost.Fusion can do the work of
QUINCE_MAP_CLASS_WITH_BASES and there has been no answer. I currently
believe that it cannot.
Most of the code in my macros is due to the foregoing two points, which
are *not* reinventions of anything in Boost.Tuple. So I really think it
is time we put the "reinvention" argument to bed. It's a distraction
from any other arguments that are still live ...
Based on my reading of http://www.boost.org/development/reuse.html , I
should only introduce a dependence on another significant Boost library
if there are benefits. Now, as just explained, I don't think there are
benefits in the form of code savings inside quince, so the quince
maintainer is not a beneficiary. Then who is? ...
The more recent discussion has mentioned the user who already has
classes adapted to Fusion tuples, and who would presumably like to avoid
the burden of *also* typing QUINCE_MAP_CLASS or
QUINCE_MAP_CLASS_WITH_BASES (aka "having to say their structure is
tuple-like a billion times"). Very well, then for that person I concede
that there is a benefit it in providing a new sort of quince mapper
class, similar to quince::tuple_mapper, but for Fusion sequences instead
of std::tuples. Let's call it quince::sequence_mapper. It would be done
without macros (just as quince::tuple_mapper is done without macros), it
would not support inheritance, and it would not support the "points->x"
syntax (which its users probably wouldn't want anyway, since they are
using Fusion syntax already). Obviously sequence_mapper would share as
much as possible of its implementation with class_mapper (the thing that
QUINCE_MAP_CLASS etc. define), and with tuple_mapper, just as those two
already share as much as possible of their implementations with each other.
As it currently stands, a quince user has the choice to represent an
employee as a class or as a std::tuple. If you use a class then you get
inheritance and the "points->x" syntax for members. If you use a
std::tuple then you get compatibility with any other code you might have
that uses std::tuples already. The proposed addition of sequence_mapper
would provide compatibility with other code that uses Fusion mappers
already. But the reasons for allowing *classes* are still valid imo.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk