Alberto Ganesh Barbati wrote:

Jonathan Turkanis wrote:

...

My recollection is that all the is_open() functions should be const, so I'm inclined to change [in]direct_streambuf. Could you give me an example of something that won't currently compile, but should?

For example this:

----- test.cpp #include <boost/iostreams/stream.hpp>

namespace io = boost::iostreams;

class empty_source { public: typedef char char_type; typedef io::source_tag category;

empty_source(int) {} std::streamsize read(char* s, std::streamsize n) { return -1; } };

int main() { io::stream<empty_source> s(0); s.is_open();

Yeah, you're right. It looks like the regression tests only cover is_open() for filtering_stream[buf]. I'll fix this, but I'm not sure if it can go into 1.33.1.

Ganesh

-- Jonathan Turkanis www.kangaroologic.com

Hendra Hidayat wrote:

Hi, I have a problem when using stream class from iostreams library. I have created a device class say GDevice using ios::device_tag and ios::input_seekable tag. In GDevice I 've declared and implemented read function inside GDevice class. I also create a stream class let's say GStream which derived from ios::stream<GDevice>. The problem was occured when I created object from GStream and call GStream's read method directly to read say n bytes data. The read method invoked GDevice read method not in n bytes data but always in 4096 bits. I dont understand where this number came from. I'm using boost 1.33, gcc compiler version 4.0.2 under x86-64 bit suse linux. Can somebody help me?

Instances of stream<> are buffered by default. This means that they read ahead in increments of the buffer size, so that subsequent read operations will be more efficient. You can change this behavior by passing a buffer size to the constructor or open() function. (This doesn't work for the forwarding constructors and open() overloads, which are provided as a convenience.) For example, stream<GDevice> str; str.open(GDevice(), 200); // buffer size of 200 str.close(); ... str.open(GDevice(), 0); // (Almost) unbuffered In the second commented example, the stream may still have a small input buffer to allow a character to be put back. I may give the user more explicit control of buffering in the next release, perhaps using the parameters library to keep the interface simple.

Faithfully yours

Hendra Hidayat

-- Jonathan Turkanis www.kangaroologic.com