Boost logo

Boost Users :

Subject: Re: [Boost-users] fusion struct adapt macro, construct the struct from a fusion vector
From: Joel de Guzman (joel_at_[hidden])
Date: 2010-01-20 06:09:32


On 1/20/2010 6:31 PM, Hicham Mouline wrote:
>
> ----- Original Message ----- From: "Joel de Guzman"
> <joel_at_[hidden]>
> To: <boost-users_at_[hidden]>
> Sent: Wednesday, January 20, 2010 10:55 AM
> Subject: Re: [Boost-users] fusion struct adapt macro, construct the
> struct from a fusion vector
>
>
>> On 1/20/2010 11:43 AM, Hicham Mouline wrote:
>>> Yes, something in that order. We are testing systems and we don't know
>>> which will give the best results.
>>>
>>> With your and Hartmut's help, I wrote a constructor for my struct
>>> pararms that takes a fusion sequence as an argument:
>>>
>>> template<typename Seq>
>>> params( const Seq& seq, ... )
>>> {
>>> for_each( zip(*this, seq), assignelt() );
>>> }
>>>
>>> params is adapted to be a fusion sequence.
>>> assignelt() is the functor that assigns from seq to params with the help
>>> of the zipped sequence
>>>
>>> Now, my question was whether the ctor could be refactored because it is
>>> identical for all the 100 params structs.
>>
>> So you have 100 similar structs that all want to to have this
>> constructor? But why? Why not simply work on fusion::vectors
>> instead of adapting structs?
>>
>> Regards,
>
> Because I wish to leave the machinery of fusion and spirit not very
> visible to the user.
> The user only works with the structs, aggregates of parameters.
> Parsing into those structs from input streams is what drove me to use
> those spirit and fusion.
>
> Ideally, the user would define the struct, and hop, I would generate the
> parser for them at compile time(the questions for this are in spirit
> users mailing list), fill up the struct for them at runtime (I do the
> parsing for them), then in the rest of their code, they would use just
> the struct directly.
>
> But maybe I am going about this in a wrong way?
>
> The user's direct is defined in a header file, some translation units
> would deal just with the struct raw.
> Other translation units would deal with the fusion/spirit parsing
> machinery.
> Maybe some adapt macro a la FUSION_ADAPT could add the ctor and its
> definition, or something like deriving from a common base class?
>
> I'd love to explain more fully my application but I find it hard to do
> with an email and easier in an realtime medium...

Ok, understood. Well, then I suggest that you don't mess with the structs
and leave them alone. The goal of FUSION_ADAPT is non-intrusive adaptation.
Instead, if you control the assignment to your structs from fusion vectors
anyway (which I imagine is the case because as you said, your users do
not have to deal with fusion vectors), then I suggest a generic free function
assign instead of decorating all your structs:

     template<typename Struct, typename Seq>
     void assign( Struct& v, const Seq& seq )
     {
         ...
     }

Or, if you can wait a bit, I do intend to write an intrusive version of
the FUSION_ADAPT_STRUCT which also generates the struct along with
the constructors and assignment to/from fusion sequences. I dunno,
perhaps you can persuade a fusion guru to write the code (Christopher)? :-)

Regards,

-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net
http://www.facebook.com/djowel
Meet me at BoostCon
http://www.boostcon.com/home
http://www.facebook.com/boostcon

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net