OSDev.org

I'm trying to mess around with my usermode module system again, and I've noticed these classes istream and ostream, that pretty sound like doing what my InStream and OutStream are doing right now. After trying to mess around to get my testing class inheriting from istream it completely folded and required a streambuf in its constructor. Believing it to be some sort of GCC thing, I looked it up in the standard, but even that says you have to use a streambuf. Inheriting from streambuf is not quite clear, and even with the standard I have no idea how it fits together or what I have to do.

Does anybody have a clear explanation or something about this?

from http://docs.freebsd.org/info/iostream/i ... ambuf.html

Using the `streambuf' Layer
***************************

The `istream' and `ostream' classes are meant to handle conversion
between objects in your program and their textual representation.

By contrast, the underlying `streambuf' class is for transferring
raw bytes between your program, and input sources or output sinks.
Different `streambuf' subclasses connect to different kinds of sources
and sinks.

The GNU implementation of `streambuf' is still evolving; we describe
only some of the highlights.

does this mean that streambuf is ancestor to istream and ostream? Seems like that's responsible for raw data handling and istream/ostream is responsible for structuring the data coming out of a streambuf. sorry ... this propably doesn't sound very elucidating.

<solarbotII>calls for solar ... solar ... solar ... </solarbotII>

beyond infinity wrote: does this mean that streambuf is ancestor to istream and ostream? Seems like that's responsible for raw data handling and istream/ostream is responsible for structuring the data coming out of a streambuf. sorry ... this propably doesn't sound very elucidating.

In a way yes. Each istream/ostream is only a frontend for a streambuf (no overrides in subclasses!). Each streambuf contains a single data stream and "requires" you to buffer your stream. It can be a writable stream, readable or both, and it always has both pointers. I haven't been able to find a document describing how to derive from it, but it is possible.

In a way, deriving from streambuf is very awkward and defines a stream. Deriving from [io]stream defines an interface to a stream and is also quite awkward.

How do I get a sane interface for it, if not by defining my own tree of streams and then making a streambuf plug-in class that allows me to load any of my own classes as stream for a streambuf. In short, how am I supposed to do it?

Hmmm... what are you actually trying to do?

Are you trying to implement your own userspace C++ library, or are you trying to make kernelspace I/O "feel" more standard-like, or...? I'm a bit confused about the ulterior motive.

Solar wrote: Hmmm... what are you actually trying to do?

Are you trying to implement your own userspace C++ library, or are you trying to make kernelspace I/O "feel" more standard-like, or...? I'm a bit confused about the ulterior motive.

The ulterior motive is to make my own ideas about streams and using streams work together with the real standard. The real standard is confusing and overly complex, plus nonusable in some aspects, for what I intend to do. I'm not going to explain what I intend to do here, I think it's something that hasn't been done and I want a head start in my development. I just don't understand the design choices as made in the STL and I was wondering whether I was the only one. I mostly wonder about the streambuf design and the [io]stream design, the streambuf always has functions for input and output, but needn't make them function. The [io]stream mostly do formatting, not streaming.

Perhaps one of these two links can help you:

Some slides on C++ streams

ML posting on streams history