A tutorial on I/O Streams

A tutorial on I/O Streams

PROLOGUE ——–

This tutorial started out as a “small” example of how to interface an I/O object into the AT&T iostream classes currently provided with almost every C++ compiler. When I say “small”, I mean just that – but the scope of the information I wanted to present really didn’t fit well into that little hole, so it turned out a little larger than I had initially hoped. However, I think the effort was worth it – I know it was for me, since although I’ve done code which deals with ostream, I hadn’t fooled at all with istream derived facilities, and learned some new things in the process.I can’t really cite any single reference on iostreams that might prove useful for those wanting to go further other than the AT&T iostreams reference manual (my copy is out on loan at the moment so I can’t quote the ISBN number). I have never come across one which is more complete than this reference, and most other references (including documentation from MSC/C++C, Borland, IBM etc.) tend to quote from it fairly liberally, but lack any of the important information needed to put it all together. While Microsoft’s C++ tutorial reference has some great hints for getting started in iostream manipulators, it lacks in providing any information on interfacing to the iostream classes themselves.

Hopefully the information I’ve provided below will make some sense. It is as complete as I could make it without really going overboard. Most of the ostream related code is gleaned from my own library, but the rest is brand new.

The text of this tutorial and the accompanying source code are donated to the public domain.

Tutorial in iostreams ———————

This little project started out with the following aims:

A) To define a simple input/output object, one that consumes bytes sent to it and generates data for input into a sample program. It should therefore feature a “read” and “write” function. The object created is simply a loopback buffer – input is queued immediately for output in FIFO (first in first out) fashion.B) To create a streams interface for this object, so that existing facilities for I/O in the AT&T streams classes can be used directly in a polymorphic fashion (ie. make use of C++ inheritance & virtual dispatch).

Specifically, I wanted to demonstrate the following aspects of iostreams:- Use of buffered vs. unbuffered I/O

– Using the streams buffer for both input and output operations. (an interface to iostream, rather than just istream or ostream)

– How the put, get and putback buffers work

C) To write a trivial application which uses both components and provide a means of interactively demonstrating how it all works.

A – The I/O Object —————-

class Myio;This class is simply a front-end for a circular buffer. Input bytes are added at the head, and read from the tail. It is fixed in size, set by the constructor.

Two read/write functions are provided to access any contained data:

int Myio::read (char * buf, int max);
int Myio::write (char const * buf, int len);

These are both non-blocking calls which return the number of bytes read or written. They know nothing about line delineation – only about raw bytes, as
would be the case for almost any I/O device.

In addition, an internal flag is maintained to indicate when a write results in a buffer ‘overflow’ (an attempt to write more bytes than will fit in the buffer) and ‘underflow’ (an attempt to read an empty buffer). These flags reflect the last write and read calls respectively, and are reset or set on each write or read call. The members Myio::readok() and Myio::writeok() rturn the settings as a boolean value.

A Myio object can also optionally create a stream. It is created and comes into life when the member function Myio::stream() is called. If it was previously created, this function simply returns a reference to the existing stream. The stream, if it exists, is deleted by the destructor.

Myio’s stream is an iostream, which inherits all of the abilities of both ostream (for output) and istream (for input), including all operators. This, of course, is the primary benefit of using streams!

B – The Streams Interface ———————–

class Mystreambuf; class Mystreambase; class Mystream;Three classes as above are used. Mystreambuf derives from streambuf, and is responsible for the input output operations and buffering on behalf of a Myio
object. Mystreambase is used as a base class for Mystream to assist in the initialisation of the (My)streambuf passed to the iostream constructor.

The iostream side is in fact very simple. Nothing really needs to be overridden, and all of the work is done in Mystreambuf, where all the action really takes place.

The relationship between the ios/stream classes and the streambuf family is one of delegation rather than inheritance. The user/application accesses
streambuf I/O via the stream object, not directly. A class diagram showing the basic iostream classes and our classes would look like:
_ istream _ / ios — ostream — iostream Mystream _____Mystreambase _/ | | (owns) | streambuf — Mystreambuf
All relationships, except the one marked “(owns)”, indicate inheritance. The ‘owns’ relationship is where the delegation occurs. ios is inherited virtually, so that there is only one combined ‘ios’ object at the root of the streams inheritence tree.

Within Mystreambuf, we need to override the functions responsible for actual input and output. But first, let’s discuss how this streambuf works.

Mystreambuf uses a single buffer, using the default buffer size allocated for any streambuf (under most operating systems, this will be 1024 bytes). Since we are dealing with both input and output operations, and these operations are independent so far as the streambuf is concerned (as is the case with, for example, serial I/O, but *not* the case with files), the buffer is split into two; the first half is used for writing, the second for reading.

The buffer used for writing is called the “put” buffer. Nothing mysterious there – when full, streambuf::overflow() function is called, and via virtual dispatch calls our Mystreambuf::overflow() which takes the contents of the buffer and writes it to the output device.

The read – or “get” – buffer is slightly more complex. There are occasions in dealing with an input stream where it is convenient to know what’s next without actually removing it from the stream. That way, you can use the next character as an indication of what to do next. For example, if you’re parsing a number, you want to know whether or not the next character is a valid digit, and stop parsing if it isn’t. The read side therefore incorporates the idea of a “putback” buffer – after being read, the character can be placed back into the input stream.

The putback buffer is entirely the responsibility of any streambuf derived class. It most you need to support a one character putback buffer – it is not valid to remove, and then restore, more than one character from the stream. It is also not valid put ‘putback’ any character but the one that was the result of the last ‘get’. It really must be “put back”, not any old character “pushed” (you could actually support ‘pushing’ data into the stream if you wanted to, but you shouldn’t use putback to do it).

The get buffer is set up as:

Offset 0 1 2 3 …. n | | | | to end of buffer |
+—+—+—+———————+ ^ ^ | +- Start of get buffer (where data is read in) | +- Where data is putback

Each time streambuf runs out of characters to give to its client, the underflow() function is called. This fills the get buffer (get buffer size – 1, starting at offset 1) and reserves the first byte in case the previously read character needs to be put back.

streambuf provides internal pointers into the put, get and putback areas. All of the I/O functions it provides handle these automatically. In our underflow() and overflow() functions, we need to set these pointers according to where and how much data is read in.

I mentioned above that in our case, the input & output streams are independant. That’s not entirely the case – it may happen that when reading from the Myio buffer we run out of data and need additional data in the output stream buffer not yet written to Myio. We therefore flush the output stream before retrieving any data by calling overflow() directly from within underflow().

The sync() function is also overridden. This simply empties all buffers by flushing the output buffer and discarding any buffered input.

C – The Application —————–

The application itself is a simple menu, offering choice to send a line of output to the IO object (via its stream), read one in, and dump/display information both about the stream and Myio object.This added two other classes to the project:

– myApplication: the actual application, implemented as a class. The only way to go in C++. 🙂

– myList: a simple line input class, whose sole purpose in life is to extract a linefeed delimited line from any istream object and return it as a char const *. (I posted this code last week, but have since fixed one minor bug I found in the process of developing Myio).

A couple of subtle points – class myApplication uses a pointer to member function it its menu selection. This is not the only way of doing this of course, but I thought it was a good way of demonstrating a very C++ specific concept, operator ->*, which does not exist at all in C.

Additional notes are included in the source comments.

Making the application ———————-

Hopefully this is a fairly simple thing to do – just compile the modules:Myiodemo.cpp Myio.cpp Mystream.cpp myLine.cpp

and link them together. A simple makefile is provided – take a look at the definitions at the top, adjust as desired, and type “make” (or nmake). If you use any of Borland’s compilers, just add the above files to a new project called “Myiodemo.PRJ”, set it to produce a .EXE (*not* Windows or PM based) and press F9.

Assuming a C++ compiler compatibile with cfront 2.1 and the presence of an iostreans 1.2 library, the only non-portable part of this app is the use of
getch() from conio.h. This isn’t easily provided under a UNIX system. You can either fudge it by writing a getch() which switches into/out of ‘raw’ mode,
or use getchar() and clear everything up to and including a CR or NL after the first character (the user still has to hit CR for input to get to the program).

EPILOGUE ——–

Just some notes as to use of this code. If you need an output or input only class, then you use ostream or istream wherever iostream is mentioned in this
example. Also, if you use buffered mode (you can support it or not – you can even ignore the streambuf setting at your discretion), then you can use the
entire buffer rather than just half each for input output.If you interface to an input only object, you only need to override streambuf::underflow(). Conversely, you override streambuf::overflow() for an output only object. I have noticed that *some* implementations of iostreams define the overflow() and underflow() methods as pure virtual functions, whereas the AT&T default defines each as simply returning EOF.

If portability is any concern, you may need to override the function you aren’t using in this fashion. The default sync() simply returns 0 (success), but again, this is sometimes defined as a pure virtual, so you may need to define it in your implementation.

In some cases, you may wish to “switch” between unbuffered and buffered modes. This is easily done by defining a function in Mystream which does it,
and this object is of course accessible in your I/O object (in this case Myio). The only thing you need to remember is to flush all the buffers by calling sync() when switching from buffered to unbuffered mode.

Note also that some streambuf constructors take an existing buffer. This means that you can use buffers already provided in your I/O object directly rather than being forced to “double buffer” anything. Your buffer can also be any size you like, subject to memory and other architecture constraints.

Enjoy!David Nugent – 3:632/348@fidonet.org
Moderor (’93-’94) of the FidoNet international C++ EchoMail conference

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.