|The stream classes are facades, not abstract interfaces. Repeat, the stream classes are facades, not abstract interfaces. And any competent programmer would be able to provide a custom facade of their own.|
The facades themselves form the interface, whether or not it's truly abstract:
void function(ostream& s)
s << "something";
Here, you're not necessarily expected to pass an actual
ostream, but rather are expected to pass one of its derived types (ofstream, ostringstream, etc). Whether or not ostream is strictly abstract isn't necessarily my primary point.
|I had then provided a working example of how to write a custom stream (an output tee-stream, IIRC), and Cubbi had given another working example (customization of the codecvt facet, IIRC).|
I vaguely remember trying Cubbi's and it didn't work, but I might be remembering incorrectly (this was a long time ago). I also distinctly remember trying out a lib I got on line that was a wrapper for Physics_FS that provided an iostream interface... but that also didn't work.
Whether or not it was a problem with the libs or not, I didn't really care, as I didn't put that much (read: any) effort into exploring it further.
|If you keep trying to create custom stream classes, without first having a basic understanding of the architecture, the roles that the stream classes play, and the roles that the associated streambuf and the facet classes play, |
You are kind of making my point.
The concept here is very simple. ostream for example: There's a stream of data that goes somewhere. There's also some seek/tell functionality thrown in for good measure.
Whatever other complications are involved are unimportant. That's the core functionality, and that is what would need to be overridden in a custom implementation. We're talking 3 or 4 very simple functions. At most.
You're going on about the differences between the stream classes, facet classes, streambufs, and all this other intertwined BS. It's needlessly complicated. Those are implementation specific details that the user (me) should not have to care about.
I mean seriously. Just give me a "write" function to overload. You're going to have to write this data somewhere eventually -- let me hook into wherever in the complex chain that is done, and do it my own way. It really could be that simple (and in fact it is that simple in every other lib I've used
that abstracts this process).
That it isn't done that way.... that not only are you exposed to all this complex detail but are also required to study and understand it is an extremely poor
design. It makes the classes unreasonable to use.
|you are going to remain frustrated for ever. |
I'm not frustrated. I just don't use it anymore. I use one of the dozen available alternatives, written by all the other people who share my sentiment.
You don't really have to look far to find people who have complaints about iostream.
Reviewing that thread you linked, I did not try Cubbi's or your example. Reviewing them again now.
Though in that thread I seem to be making all the same points I'm making now. Heh.
Yeah I started looking at your tee classes here:
And I started reading up on streambuf again to see how they work, and I just have a really hard time caring. Maybe some day I'll revisit iostream but I doubt it will be any time soon. There are enough things about it besides this particular point that I don't like which make me not want to really bother.
No, a simple convenience constructor is fine. I was mostly referring to creating your own streambuf implementation.