Stream Buffers

Stream Buffers
Prev	Chapter 13. + Input and Output + +	Next

Derived streambuf Classes

Creating your own stream buffers for I/O can be remarkably easy. + If you are interested in doing so, we highly recommend two very + excellent books: + Standard C++ + IOStreams and Locales by Langer and Kreft, ISBN 0-201-18395-1, and + The C++ Standard Library + by Nicolai Josuttis, ISBN 0-201-37926-0. Both are published by + Addison-Wesley, who isn't paying us a cent for saying that, honest. +

Here is a simple example, io/outbuf1, from the Josuttis text. It + transforms everything sent through it to uppercase. This version + assumes many things about the nature of the character type being + used (for more information, read the books or the newsgroups): +

+    #include <iostream>
+    #include <streambuf>
+    #include <locale>
+    #include <cstdio>
+
+    class outbuf : public std::streambuf
+    {
+      protected:
+	/* central output function
+	 * - print characters in uppercase mode
+	 */
+	virtual int_type overflow (int_type c) {
+	    if (c != EOF) {
+		// convert lowercase to uppercase
+		c = std::toupper(static_cast<char>(c),getloc());
+
+		// and write the character to the standard output
+		if (putchar(c) == EOF) {
+		    return EOF;
+		}
+	    }
+	    return c;
+	}
+    };
+
+    int main()
+    {
+	// create special output buffer
+	outbuf ob;
+	// initialize output stream with that output buffer
+	std::ostream out(&ob);
+
+	out << "31 hexadecimal: "
+	    << std::hex << 31 << std::endl;
+	return 0;
+    }
+

Try it yourself! More examples can be found in 3.1.x code, in + include/ext/*_filebuf.h, and in this article by James Kanze: + Filtering + Streambufs. +

Buffering

First, are you sure that you understand buffering? Particularly + the fact that C++ may not, in fact, have anything to do with it? +

The rules for buffering can be a little odd, but they aren't any + different from those of C. (Maybe that's why they can be a bit + odd.) Many people think that writing a newline to an output + stream automatically flushes the output buffer. This is true only + when the output stream is, in fact, a terminal and not a file + or some other device -- and that may not even be true + since C++ says nothing about files nor terminals. All of that is + system-dependent. (The "newline-buffer-flushing only occurring + on terminals" thing is mostly true on Unix systems, though.) +

+   output << "a line of text" << endl;
+   output << some_data_variable << endl;
+   output << "another line of text" << endl;

The proper thing to do in this case to just write the data out + and let the libraries and the system worry about the buffering. + If you need a newline, just write a newline: +

+   output << "a line of text\n"
+	  << some_data_variable << '\n'
+	  << "another line of text\n";

I have also joined the output statements into a single statement. + You could make the code prettier by moving the single newline to + the start of the quoted text on the last line, for example. +

If you do need to flush the buffer above, you can send an + endl if you also need a newline, or just flush the buffer + yourself: +

+   output << ...... << flush;    // can use std::flush manipulator
+   output.flush();               // or call a member fn

On the other hand, there are times when writing to a file should + be like writing to standard error; no buffering should be done + because the data needs to appear quickly (a prime example is a + log file for security-related information). The way to do this is + just to turn off the buffering before any I/O operations at + all have been done (note that opening counts as an I/O operation): +

+   std::ofstream    os;
+   std::ifstream    is;
+   int   i;
+
+   os.rdbuf()->pubsetbuf(0,0);
+   is.rdbuf()->pubsetbuf(0,0);
+
+   os.open("/foo/bar/baz");
+   is.open("/qux/quux/quuux");
+   ...
+   os << "this data is written immediately\n";
+   is >> i;   // and this will probably cause a disk read

Since all aspects of buffering are handled by a streambuf-derived + member, it is necessary to get at that member with rdbuf(). + Then the public version of setbuf can be called. The + arguments are the same as those for the Standard C I/O Library + function (a buffer area followed by its size). +

A great deal of this is implementation-dependent. For example, + streambuf does not specify any actions for its own + setbuf()-ish functions; the classes derived from + streambuf each define behavior that "makes + sense" for that class: an argument of (0,0) turns off buffering + for filebuf but does nothing at all for its siblings + stringbuf and strstreambuf, and specifying + anything other than (0,0) has varying effects. + User-defined classes derived from streambuf can + do whatever they want. (For filebuf and arguments for + (p,s) other than zeros, libstdc++ does what you'd expect: + the first s bytes of p are used as a buffer, + which you must allocate and deallocate.) +

A last reminder: there are usually more buffers involved than + just those at the language/library level. Kernel buffers, disk + buffers, and the like will also have an effect. Inspecting and + changing those are system-dependent. +