Re: [boost] [Review] xpressive

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-09-15 00:45:47

Hi Eric, Scott,

Sorry if this is getting a bit off-topic for the xpressive review...

--- Eric Niebler <eric_at_[hidden]> wrote:
> Scott Woods wrote:
> > 5. There didnt appear to be much specific thought given to file
> > processing. Is this another "not yet implemented"? In particular
> > elegant integration with any async I/O facillity arising from
> > sockets and file I/O initiatives.
> 
> xpressive works generically with iterators. Spirit has a file
> iterator. That would be the way to go, IMO.

I'm not totally familiar with the xpressive API, but as far as I
understand the regex APIs (even with iterators) are not sufficient for
clean integration with async I/O.

What you need is a stateful decoder that you can feed data to as you
receive it off the wire, and it tells you when it is done, or when it
needs you to feed it more data.

For example, a Decoder concept might look like:

class Decoder
{
public:
  template <typename InputIterator>
  tuple<tribool, InputIterator> decode(
      InputIterator begin, InputIterator end);
};

The begin and end parameters specify the range of input.

The tribool return value is true when a complete "message" has been
received, false when the data is known to be invalid, indeterminate
when more data is required.

The InputIterator return value is used to indicate how much of the
input has been consumed.

It would be used something like this:

class server
{
//...
  handle_read(const error& e, size_t bytes_read)
  {
    tribool ok;
    tie(ok, tuples::ignore) = decoder_.decode(buf_, buf_ + bytes_read);
    if (ok)
    {
      // Successfully decoded message.
    }
    else if (!ok)
    {
      // Error in message.
    }
    else
    {
      // Need more data.
      sock_.async_read(buf_, 1024,
          bind(&server::handle_read, this, _1, _2));
    } 
  }
//...

private:
  stream_socket sock_;
  char buf_[1024];
  Decoder decoder_;
};

I have used hand-crafted implementations of this concept with great
success. I would be *very* keen to see it supported in a generic regex
mechanism, as it would make it so easy to implement text-based
protocols efficiently and safely.

Cheers,
Chris