Even if we like the "x", it's still misspelled, given that "transferred" has two "r"s.

I'm also unhappy about the use of "O/S" for (presumably) "operating (divided by) system".

Also... the arrows in this diagram don't all represent the same thing. And what are the labels on the arrows? Are those... subclause labels? Oh no, that's a maintenance nightmare.

Finally, this diagram is in the overall summary of Clause 29, indicating relationships between some types defined in that Clause. But these types are not even close to being the most important types described in Clause 29; in fact, I would expect that most users of the more common Clause 29 facilities have never even heard of them and don't care about them at all.

Maybe we should delete paragraph 3 entirely, along with its figure.

@jwakely Would that be OK with you? Do you think that note adds value?

Two more reasons to dislike this figure:

• it's wickedly wide with teeny tiny fonts
• it has code in non-code font

Let's delete it all, I've always found it unnecessarily difficult to find the definitions of streampos etc and this figure doesn't help at all. It's also woefully out of date because it doesn't cover char32_t etc.

I think adding hyperlink cross-references to [iosfwd.syn] would provide far more value than that figure. We could also add cross-references from [iostreams.limits.pos] to [iosfwd.syn] and [stream.types] for streampos and streamoff respectively.

[ios.syn] has a completely redundant redeclaration of fpos (<ios> is required to include <iosfwd> which already declares fpos). It also redeclares basic_ios (also in <iosfwd>) and redeclares its default template argument, which is ill-formed (Edit: but [iosfwd.syn] p1 makes it OK). [ios.syn] would also benefit from cross-references (to the definitions of at least fpos, ios_base and basic_ios)

Why is [stream.types] tucked away under "Iostreams base classes" [iostreams.base] when it's not part of any class, base or not. Why is fpos also in "Iostreams base classes"? Not the worst problem, but it doesn't help to find them.

Just to add some historical context: this figure was added for C++11, despite addressing a design installed in C++98, by paper http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2926.pdf at the Frankfurt 2009 meeting. At first glance there is a lot of circularity in the definition of the type aliases used by iostreams, and this diagram is intended to make it clear where the roots that others are defined in terms of can be found.

I know that I have found this diagram helpful in the past, but the standard has had 10 years evolving the wording so maybe it is not as important as it used to be? I suggest we might want to review the original paper and the confusion it is intended to clear up, before deciding on the removal. I am not in a good place to evaluate, as my own understanding of this clause it tied strongly to the introduction of the diagram now, rather than the text alone.

My understanding of those types is not improved by the diagram in the slightest. As Richard said above, the arrows don't always mean the same thing ... except that actually they do, the note before the diagram is a lie (the arrows always mean A is a typedef denoting the same type as B).

The rightmost part adds absolutely nothing that isn't said in [stream.types]. It's an impl-defined signed integer type. Fine. We don't need a diagram to say that. Moving [stream.types] earlier in the Clause might help though.

For the rest of the diagram, maybe we could add a paragraph to [iostreams.limits.pos] saying that for each of the specializations of char_traits defined in [char.traits.specializations], state_type denotes mbstate_t, pos_type denotes fpos<mbstate_t>, and off_type denotes streamoff. Then add a cross-reference to [stream.types] for streamoff.

The types streampos and wstreampos (and u8streampos, u16streampos, and u32streampos) are not used anywhere in the standard. Why do we need to use a diagram to clarify them? They are aliases defined in <iosfwd> and are completely defined by that synopsis.

Edit: sorry, they're used once each in [char.traits.specializations]. They don't need to be though, arguably it would be simpler if char_traits just defined pos_type as fpos<state_type> since that's what it's required to be. Then we wouldn't need Note 2 in [iostreams.forward.overview] p9 mentioning the circularity.

ISO have issued new guidelines for drawings, which would require us to provide them with the source for this figure. Although a .dot file does meet their stated requirements, it's not one of the formats they list as acceptable.

We have a few more .dot drawings in the standard.
Regardless, the guidelines probably don't really apply to us, because we provide PDF, not Word-to-be-transformed-to-XML plus separate drawings files.

According to https://tex.stackexchange.com/a/2106, the tikz package allows the use of SVG path data. So if we could transform the images into SVG, would that be suitable for ISO?

SVG is fine for ISO, according to "DRG working instructions and directives".

Hm, an alternative, according to the TikZ manual, is to use TikZ-in-LaTeX as the primary source, and TikZ has an output driver that generates SVG. So we could ship the exported images to ISO as SVGs.

That would of course mean redrawing all the images in TikZ.