more spirit madness - parser-types (rules vs int_parser<>) and meta-programming techniques

Question

The question is in bold at the bottom, the problem is also summarized by the distillation code fragment towards the end.

I am trying to unify my type system (the type system does to and from from type to string) into a single component(as defined by Lakos). I am using boost::array, boost::variant, and boost::mpl, in order to achieve this. I want to have the parser and generator rules for my types unified in a variant. there is a undefined type, a int4(see below) type and a int8 type. The variant reads as variant<undefined, int4,int8>.

int4 traits:

    struct rbl_int4_parser_rule_definition
    {
      typedef boost::spirit::qi::rule<std::string::iterator, rbl_int4()> rule_type;
      
      boost::spirit::qi::int_parser<rbl_int4> parser_int32_t;
      
      rule_type rule;
      
      rbl_int4_parser_rule_definition()
      {
        rule.name("rbl int4 rule");
        rule = parser_int32_t;  
      }
    };
    
    template<>
    struct rbl_type_parser_rule<rbl_int4>
    {
      typedef rbl_int4_parser_rule_definition string_parser;
    };

the variant above starts out as undefined, and then I initialize the rules. I had a problem, which caused 50 pages of errors, and I have finally managed to track it down, Variant uses operator= during assignment and a boost::spirit::qi::int_parser<> cannot be assigned to another (operator=).

To contrast, I don't have a problem with my undefined type:

    struct rbl_undefined_parser_rule_definition
    {
      typedef boost::spirit::qi::rule<std::string::iterator, void()> rule_type;
      rule_type rule;
      
      rbl_undefined_parser_rule_definition()
      {
        rule.name("undefined parse rule");
        rule = boost::spirit::qi::eps;
      }
    };
    
    template<>
    struct rbl_type_parser_rule<rbl_undefined>
    {
      typedef rbl_undefined_parser_rule_definition string_parser;
    };

Distillation of the problem:

    #include <string>
    #include <boost/spirit/include/qi.hpp>
    #include <boost/variant.hpp>
    #include <boost/cstdint.hpp>
    
    typedef boost::spirit::qi::rule<std::string::iterator,void()> r1;
    typedef boost::spirit::qi::rule<std::string::iterator,int()> r2;
    
    typedef boost::variant<r1,r2> v;
    
    int main()
    {
      /*
      problematic
      boost::spirit::qi::int_parser<int32_t> t2;
      boost::spirit::qi::int_parser<int32_t> t1;
      
      
      t1 = t2;
      */
    
      //unproblematic
      r1 r1_;
      r2 r2_;
      r1_ = r2_;
    
      v v_;
      // THIS is what I need to do.
      v_ = r2();
    }

There is a semantic gap between concrete parsers and rules. My brain is smoking at the moment so I am not going to think about pramatism, My question is, how do I solve this problem ? I can think of three approaches to solve the problem.

one: Static function members:

    struct rbl_int4_parser_rule_definition
    {
      typedef boost::spirit::qi::rule<std::string::iterator, rbl_int4()> rule_type;
      
      //boost::spirit::qi::int_parser<rbl_int4> parser_int32_t;
      
      rule_type rule;
      
      rbl_int4_parser_rule_definition()
      {
        static boost::spirit::qi::int_parser<rbl_int4> parser_int32_t;
    
        rule.name("rbl int4 rule");
        rule = parser_int32_t;  
      }
    };

I guess approach one prevents thread safe code ? ?

two: The integral parser is wrapped in a shared_ptr. There are two reasons I'm bothering with TMP for the typing system: 1 efficiency, 2 centralizing concerns into components. using pointers defeats the first reason.

three: operator= is defined as a no-op. variant guarantees that the lhs is default constructed before assignment.

Edit: I am thinking option 3 makes the most sense (operator= is a no-op). Once the rule container is created it will not change, and I am only assigning to force a type's rule trait into its offset.

Answer 1

I'm not so sure I get the full extent of the question, but here are a few hints

• The line commented with // THIS is what I need to do. compiles fine with me (problem solved? I'm guessing you actually meant assigning a parser, not a rule?)

• Initialization of function-local static has been defined to be thread safe in the latest standard (C++11). Check your compiler support for C++0x threading. (If the initializer throws, a pass of the initialization statement will try to initialize again, by the way).

• rules alias()

  As described in http://boost-spirit.com/home/articles/doc-addendum/faq/#aliases

  You can create 'logical copies' of rules without having to actually value-copy the proto expression. As the FAQ says, this is mainly to allow lazy-binding

• The Nabialek Trick might be precisely what you need, basically it lazily selects a parser for subsequent parsing

  one = id;
  two = id >> ',' >> id;
  
  keyword.add
      ("one", &one)
      ("two", &two)
      ;
  
  start = *(keyword[_a = _1] >> lazy(*_a));
  

  In your context, I could see keyword defined as

  qi::symbols<char, qi::rule<Iterator>*> keyword;
  

  doing all the work with attributes from semantic actions. Alternatively,

  qi::symbols<char, qi::rule<Iterator, std::variant<std::string,int>() >*> keyword;
  

• Bring the rules under the same type (like shown in the previous line, basically)

  This is the part where I'm getting confused: You say you want to unify your type system. There might not be a need for strongtyped parsers (distinct attribute signatures).

  typedef boost::variant<std::string,int> unified_type;
  typedef qi::rule<std::string::iterator, unified_type() > unified_rule;
  
  unified_rule rstring = +(qi::char_ - '.');
  unified_rule rint    = qi::int_;
  
  unified_rule combine = rstring | rint;