Boost logo

Boost :

From: BRIDGES Dick (Dick.Bridges_at_[hidden])
Date: 2005-10-24 17:16:47

I am trying to use Xpressive for parsing string-based message buffers.
The messages start with a fixed string and end with an "empty" line
(similar in form to HTTP). Here is code that illustrates my problem:

main(int argc, char **argv) {
        std::string buffer_ =
                "Volume = 3\r\n"
                "Other1= 0\r\n"
                "Other =2\r\n"
                "Volume = 4\r\n"
                "Other1= 8\r\n"
                "Other =3\r\n"
                "Volume = 4\r\n"
                "Other1= 8\r\n"

// mark_tag name_(1), value_(2); To be used in the name_value_pair

        sregex name_value_pair_ = +alnum >> *_s >> "=" >> *_s >> +_d >>
*_s >> _ln;

        sregex re_ = "FROGGIE" >> _ln >> name_value_pair_ >> _ln;
// sregex re_ = "FROGGIE" >> _ln >> repeat<1,5>(name_value_pair_)
>> _ln;
// sregex re_ = "FROGGIE" >> _ln >> +(name_value_pair_) >> _ln;

The only examples of repeating an embedded regex I could find in the
.pdf or the examples subdirectory used predefined regexes like alnum but
still, it looked to me that the lines that are commented out should have
worked. I am clearly wrong. Both of these forms create very long error
messages that end with "internal compiler error". One of those error
messages is included as an attachment. The uncommented line compiles

Since I'm not very accomplished at regular expressions, maybe I should
point out that, besides being able to extract the name/value pairs from
each message in turn, I want to use what.suffix() to identify the
partial message at the end of the buffer.

OS is Linux Core 3 2.6.9-1.667. Compiler is gcc 3.4.2 20041017 (Red Hat
3.4.2-6fc5). Xpressive README (in the .zip) says "Last Modified:
October 9, 2005".

If someone could point me in the right direction, I'd surely appreciate

If this query is not appropriate for this group, should I post it to
boost-users_at_[hidden] or mail the author directly or..?

Dick Bridges

Boost list run by bdawes at, gregod at, cpdaniel at, john at