
I'm not sure what you mean by "the straightforward way implies creating a string". String for what? The attribute? The input? Spirit does not allocate any memory. Also, AFAIK, you can avoid using strings. Perhaps be more specific?
Let's say I have an input of const char *. My input consists of a command with up to two parameters. I used Spirit to parse this command and decompose it into chunks (which means that the result of the parsing will be one enum and two "strings").
Currently it's a simple loop which returns the pointers to the chunks. Very fast (obviously).
From what I understood of Spirit, I wrote a parser which created a string when it found my chunk. On top of my head it might have looked like this
lit("command1") >> +char_[ref(my_str) = _1] >> lit("separator") >> +char_[ref(my_str2) = _1] | lit("command2) >> +alnum_[ref(my_str) = _1]
typedef iterator_range<char const*> range_type; typedef std::pair<range_type, range_type> result_type; rule<char const*, result_type()> r = "command1" >> raw[+(!lit("separator") >> char_)] >> "separator" >> "command2" >> raw[+alnum]; Does exactly as the above except it returns two pairs of pointers to the arguments of your commands. Just call it as: char const* begin = ...; char const* end = ...; result_type rt; parse(begin, end, r, rt); allowing you to access your pairs of pointers from rt. Voila! No memory allocation at all!
This is really cool and much easier to understand than the current loop. Currently the memory allocation occurs when putting the input into the string. I now realize I can replace ref(my_str) = _1 with something that's going to build a pair of pointers based on the input which should reduce the gap between Spirit and the custom parser.
But then I encountered a different problem which is that the 'grammar' cannot be read from left to right. Basically the input may contain the separator, so what I currently do is read my command, start from the right, when I reach the separator I have my second token and the rest is the first token. That can be avoided as well in offloading this part off Spirit.
I think this is solved by the above rule. HTH Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com