----- Original Message -----
From: "Joel de Guzman"
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... rds,