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
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.