I have a stream class that I'm writing in C++ that is based on my stream hierarchy in C. I had decided that I would opt for a better design, and instead of having it be an error condition at runtime when you do something that the stream doesn't support, I would divide the functionality up through an inheritance tree, so that an output stream would not have the functionality to perform input, and vice-versa. This way, the compiler would immediately report an error, since the functionality does not exist within the class. But, that's old news. I presume that multiple-inheritance is the best way to accomplish combining read and write functionality, since they both operate upon a common state, so composition would be out, since having two separate states would break the functionality. I could write a separate InputOutputStream class and manually splice together their behaviors, but that seems like a foolish way to avoid multiple-inheritance through code duplication.
Now, the problem, where things get interesting, is that there were some stream types that could not be rewound. It was a one-way, forward stream, and the "file pointer" could not be moved backward. My idea to allow this was to have the BasicStream class not have any functionality that would allow it to be rewound, and have all constants related to seeking backward removed. I would then have a RewindableStream class, that would derive from BasicStream, and would in turn allow RewindableInputStream, RewindableOutputStream, and others. This drastically complicates things, and requires at least twice as many derived classes.
I previously implemented this through a flag that defined whether or not rewinding was possible. This seemed fragile to me, because I feel it shouldn't be a run-time error if you do something that you to be impossible before you ever run the code, like trying to rewind a non-rewindable stream. I had no better way of doing it then, but I feel that it should be on the same level of severity like attempting to read from an output stream. For an example of an unrewindable stream, consider special output devices like a printer or printing bitmap fonts to a framebuffer. You can't very well rewind a printer, and when printing to a frame buffer, once it's printed, it's pixels on an image. There's no information available on how to move backward, and even if there ways, there's no information on how to remove its previous contents.
It would seem that allowing one to attempt to rewind unrewindable streams and have it report an error that doesn't always get checked is kind of backward, and results in confusion (there have been topics here on why rewinding stdout doesn't work).
So, my question, is how should I implement functionality that isn't always present and I would like to remove from streams that don't use it, while maintaining the relatively simple diamond that exists from BasicStream to InputStream and OutputStream, to InputOutputStream?