问题描述
首先，似乎我要求主观意见，但这不是我后悔的。我很想听到关于这个话题的一些有根据的理由。希望获得一些深入了解一个现代流/序列化框架应该如何设计，我最近得到了一本这本书的副本。我认为如果IOStreams设计不好，首先就不会将它放到C ++标准库中。
这本书，我开始怀疑如果IOStreams可以比较例如STL从整体架构角度来看。阅读例如了解一些设计决策，进入STL。
令我惊喜的是：
-
似乎不知道谁负责IOStreams的整体设计（我很想读一些关于这个的背景信息，有没有人知道很好的资源？）;
-
一旦你深入IOStreams的直接表面，例如如果你想使用自己的类来扩展IOStreams，你可以得到一个相当隐蔽和混乱的成员函数名称的界面，例如
getloc/imbue，uflow/下溢，snextc/sbumpc/sgetc/sgetn，pbase/pptrepptr（可能更糟糕的例子）。这使得了解整体设计以及单个零件如何合作变得更加困难。即使是我上面提到的这本书也没有帮助那个（IMHO）。
因此我的问题：
如果你必须通过今天的软件工程标准来判断（如果有实际上是否有任何关于这些的一般协议），C ++的IOStreams仍然被认为是精心设计的？ （我不想提高我的软件设计技能，通常被认为是过时的）。
几个不合理的想法发现他们的方式进入标准： auto_ptr ， vector< bool> ， valarray 和 export ，仅举几例。所以我不会把IOStreams的存在作为质量设计的标志。
IOStreams有一个方格的历史。他们实际上是一个早期的流图书馆的修复，但是在当今的许多C ++习语不存在的时候创作，所以设计师没有后见之明的好处。随着时间的推移，一个问题是变得越来越明显，因为几乎不可能像C的stdio一样有效地实现IOStream，这是因为虚拟功能的丰富使用，甚至以最细粒度转发到内部缓冲对象，并且还得益于一些不可思议的奇怪方法是定义和实现语言环境。我对此的记忆相当模糊，我承认，我记得这是几年前的comp.lang.c ++主持人，主持人。
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>, valarray and export, 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.
这篇关于谁设计/设计C ++的IOStreams，它仍然被认为是按照今天的标准设计的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！