Subject: Re: [boost] C++ Networking Library Release 0.5
Date: 2010-02-02 04:43:51
On Tue, 02 Feb 2010 17:12:35 +0800, Joel de Guzman
> I'm not sure what you mean by "the straightforward way implies creating
> string". String for what? The attribute? The input? Spirit does not
> any memory. Also, AFAIK, you can avoid using strings. Perhaps be more
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]
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.
Then again I want to insist I'm new to Spirit and just wanted to give it a
shot and see if I could quickly leverage it. It is my current conclusion
that for my specific problem MSM might be best suited, but then again I
just wanted to allocate one day for this mini-benchmark and all I can say
is that it will take more than one day to tell, day I don't have.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk