Difference between "internal" vs "associated" stream buffer

Question

From http://www.cplusplus.com/reference/ios/ios/rdbuf/:

Some derived stream classes (such as stringstream and fstream) maintain their own internal stream buffer, to which they are associated on construction. Calling this function to change the associated stream buffer shall have no effect on that internal stream buffer: the stream will have an associated stream buffer which is different from its internal stream buffer (although input/output operations on streams always use the associated stream buffer, as returned by this member function).

And on http://www.cplusplus.com/reference/fstream/ifstream/rdbuf/:

Returns a pointer to the internal filebuf object.

Notice however, that this is not necessarily the same as the currently associated stream buffer (returned by ios::rdbuf).

So what is the internal buffer for if it's not used for input and output operations? And if it means that these two lines could return two different objects, why could this be useful?

std::stringstream ss;
ss.rdbuf();                          // (1) returns "internal" stream buffer?
static_cast<std::ios&>(ss).rdbuf();  // (2) returns "associated" stream buffer?

Periscope

But then, isn't it really counter-intuitive that ifstream::rdbuf() returns not the buffer that the object currently uses? – Periscope

That's what ios::rdbuf is for. – Tremayne

@FelixDombek I haven't finished reading your question, but if you're asking if something about iostream is counter intuitive the answer is probably yes. If the next answer is whether a complete redesign from the ground up would make it better, the answer is a bigger yes. – Role

Answer 1

The internal buffer is used for input and output operations up until the point of calling rdbuf with some other argument. Then it just sits there.

You can always re-enable it by calling

stream.basic_ios::rdbuf(stream.rdbuf());

Note that the internal buffer for e.g. std::fstream is always an std::filebuf object owned and managed by the stream object, while the associated buffer can be any streambuf derived object. The stream only stores a base class pointer to it and doesn't manage its lifetime.

Also note that the term "internal buffer" is not used by the standard. The standard uses a bit different terminology:

The class basic_ifstream<charT, traits> supports reading from named files. It uses a basic_filebuf<charT, traits> object to control the associated sequence. For the sake of exposition, the maintained data is presented here as:

— sb, the filebuf object.

The "maintained data" above is what cplusplus.com calls "the internal stream buffer".

Spectacled

"internal stream buffer" is probably easier to understand and more intuitive than "maintained data" – Role

Thanks! Is the basic_ios:: part really needed? – Periscope

Yes, fstream::rdbuf() hides both basic_ios::rdbuf overloads, so you need to access them explicitly. – Spectacled

So if we do not change the associated stream buffer manually, is the internal stream buffer the same as associated stream buffer? – Chapman

@Chapman yes exactly – Spectacled