The effect of `basic_streambuf::setbuf`

Question

My problem is as follows: Martin York claims in this, this, and this answers that one can make a stringstream read from some piece of memory by using basic_stringbuf::pubsetbuf like this:

char buffer[] = "123";
istringstream in;
in.rdbuf()->pubsetbuf(buffer, sizeof(buffer)); // calls basic_stringbuf::setbuf
int num;
in >> num; // reads 123

Unfortunately I dug through the whole standard and couldn't see where it's guaranteed to work. What I see is that's just implementation-defined. In fact on Microsoft's implementation (maybe on others too) this call has no effect.

Here are related quotes I found in the last C++0x draft. For the basic_streambuf::setbuf [streambuf.virt.buffer]:

1 Effects: Influences stream buffering in a way that is defined separately for each class derived from basic_streambuf in this Clause (27.8.1.4, 27.9.1.5).

2 Default behavior: Does nothing. Returns this.

However in the derived classes it seems to leave the behavior implementation-defined. For basic_stringbuf::setbuf it says [stringbuf.virtuals]:

1 Effects: implementation-defined, except that setbuf(0,0) has no effect.

For basic_filebuf::setbuf it says [filebuf.virtuals]:

12 Effects: If setbuf(0,0) [...], the stream becomes unbuffered. Otherwise the results are implementation-defined. “Unbuffered” [...]

And that's it. So as I see it, a valid implementation can ignore these calls completely (for non-null parameters).

Am I wrong? What is the correct interpretation of the standard? Do C++98/03/0x have the same guarantees? Do you have more statistics on which implementations the above code works and on which it does not? How basic_streambuf::setbuf is intended to be used?

Answer 1

I believe it is implementation defined and that you provided the relevant quotes.

For the record, this is what Standard C++ IOStreams and locales, not exactly a recent book I have to admit, has to say on the subject in a section titled "The almost semantic free function - setbuf()" :

The virtual member function setbuf() is a rather peculiar stream buffer member. Its semantics are basically undefined. For string stream buffers, the semantics of setbuf() are implementation-defined, except that setbuf(0, 0) are defined: if setbuf(0, 0) is called on a stream before and I/O has occured on that stream, the stream becomes unbuffered, meaning that characters are directly transported to and from the file system. Otherwise, the results are implementation-defined.

However, the specifications of setbuf() for basic_filebuf and basic_stringbuf hardly impose any requirements on the semantics of setbuf() in other stream buffer types. At best, the general semantics can be defined as device and, in the case of user-defined stream buffer types, implementation-specific.

The lack of any requirements frees you to redefine setbuf() for just about any purpose and in any way that fits into the predefined interface of setbuf().

Answer 2

OK. Retract.

After spending the last couple of days going through the documentation and the the proposals that have been made it now seems clear that this may not work (as it is implementation defined).

As you note in your description above:

27.5.2.4.2: 1 Effects: Influences stream buffering in a way that is defined separately for each class derived from basic_streambuf in this Clause (27.8.1.4, 27.9.1.5).

The effect of setbuf() is really defined by its interaction with 27.8.1.4 underflow();

Returns: If the input sequence has a read position available, returns traits::to_int_type(*gptr()). Otherwise, returns traits::eof(). Any character in the underlying buffer which has been initialized is considered to be part of the input sequence.

Also for getting more characters from the stream you need to check 27.9.1.5 showmanyc()

An implementation might well provide an overriding definition for this function signature if it can determine that more characters can be read from the input sequence.

Which for the stringstream buffer means it will not get anything as the buffer already holds the whole stream.

So though it is implementation defined how it does it.
It is still well defined how it does it.