> Rob Desbois, le 18 janvier 2008 08:02:
>
> >
> > After trying to compile I realised that a SeekableDevice
> > provides read, write and seek functions, nothing else.
> > Am I seriously misunderstanding the point of
> boost::iostreams?
> On Jan 18, 2008 6:46 PM, Eric MALENFANT
> <
Eric.Malenfant@sagem-interstar.com
> wrote:
> A file_descriptor only implements the Device concept,
> it not an std::iostream.
> If you want an std::iostream, you wrap the Device in a
> boost::iostreams::stream which, as stated in its
> documentation: "performs i/o by delegating to a contained
> Device", and "derives from a specialization of
> std::basic_istream, std::basic_ostream or
> std::basic_iostream, depending on whether the underlying
> Device models Source, Sink or both."
> Rob Desbois, le 18 janvier 2008 13:58:
>
> Are you able to comment on whether I 'should' be doing this
> as regards the non-blocking and non-seekable nature of a serial port?
The "seekability" should not be a problem. You could define a BidirectionalDevice as Jonathan suggests in another message. If you only need read (or write), you could even just define a Source (or Sink).
The "blocking" side of things may be more trouble, depending on your needs.
Boost.Iostreams offers minimal support for non-blocking strings: boost::iostreams::char_traits::would_block() can be used to indicate that a read or write attempt was interrupted but, unless I missed something, nothing allows the caller to wait for the blocking condition to be removed (like select() allows for non-blocking sockets, for example), so the caller has to poll the stream. As suggested by Bob Warren,
Boost.Asio may offer an interesting alternative.
Éric Malenfant
---------------------------------------------
Amateur programmers think there are 1000 bytes in a kilobyte;
Real Programmers think there are 1024 meters in a kilometer.