First off, it may seem that I’m asking for subjective opinions, but that’s not what I’m after. I’d love to hear some well-grounded arguments on this topic.
In the hope of getting some insight into how a modern streams / serialization framework ought to be designed, I recently got myself a copy of the book Standard C++ IOStreams and Locales by Angelika Langer and Klaus Kreft. I figured that if IOStreams wasn’t well-designed, it wouldn’t have made it into the C++ standard library in the first place.
After having read various parts of this book, I am starting to have doubts if IOStreams can compare to e.g. the STL from an overall architectural point-of-view. Read e.g. this interview with Alexander Stepanov (the STL’s “inventor”) to learn about some design decisions that went into the STL.
What surprises me in particular:
-
It seems to be unknown who was responsible for IOStreams’ overall design (I’d love to read some background information about this — does anyone know good resources?);
-
Once you delve beneath the immediate surface of IOStreams, e.g. if you want to extend IOStreams with your own classes, you get to an interface with fairly cryptic and confusing member function names, e.g.
getloc/imbue,uflow/underflow,snextc/sbumpc/sgetc/sgetn,pbase/pptr/epptr(and there’s probably even worse examples). This makes it so much harder to understand the overall design and how the single parts co-operate. Even the book I mentioned above doesn’t help that much (IMHO).
Thus my question:
If you had to judge by today’s software engineering standards (if there actually is any general agreement on these), would C++’s IOStreams still be considered well-designed? (I wouldn’t want to improve my software design skills from something that’s generally considered outdated.)
Several ill-conceived ideas found their way into the standard:
auto_ptr,vector<bool>,valarrayandexport, just to name a few. So I wouldn’t take the presence of IOStreams necessarily as a sign of quality design.IOStreams have a checkered history. They are actually a reworking of an earlier streams library, but were authored at a time when many of today’s C++ idioms didn’t exist, so the designers didn’t have the benefit of hindsight. One issue that only became apparent over time was that it is almost impossible to implement IOStreams as efficiently as C’s stdio, due to the copious use of virtual functions and forwarding to internal buffer objects at even the finest granularity, and also thanks to some inscrutable strangeness in the way locales are defined and implemented. My memory of this is quite fuzzy, I’ll admit; I remember it being the subject of intense debate some years ago, on comp.lang.c++.moderated.