C++ストリームとCストリームを独立してバッファできるようにするメリットはありますか？

Question

C++ iostreamsは、C++ストリームをstd::ios_base::sync_with_stdio()経由でCストリームと同期させる必要があるかどうかを制御します。ストリーム同期をオフにすると、標準ライブラリの実装で、C++ストリームとCストリームに独立した非同期バッファを使用してパフォーマンスを向上させることができます。

CおよびC++ストリーム用に別々の独立したioバッファセットを使用するためにドアを開いたままにしておくことが重要だと考えられたのはなぜですか？私はこれがどのようにIOバッファの1つのセットと比較してパフォーマンスを潜在的に改善するのか見ていない。標準ライブラリにプログラム・レベルで1組のIOバッファを許可すると、基礎となるOSIO機能に対する通常は高価な呼び出しの数を減らすことができますが、2組のioバッファの利点は何ですか？

CストリームとC++ストリームのバッファが別々になってパフォーマンスに役立つという技術的な理由があるのでしょうか、それとも単なる歴史的なアーティファクトなのでしょうか？

C++実装者が既存のC標準ライブラリ実装を構築してC++標準ライブラリを実装できるようにするために、何らかの形で委員会と関係がありますか？

---

「標準がそう言っている」以上のものを探しています。

理論的根拠を説明するためにOS特性が必要な場合は、実際のOSが提供する機能を例として使用したり、仮想的ではあるが合理的なOSを説明することはできます。

---

編集：は明確にするために、質問はなぜ同期ストリームは、パフォーマンスに悪影響を与えることができていません。問題は、なぜC++標準が、2組のioバッファがあり、その可能性を開いたままにしておくのが実装者にとって有益であるという前提で設計された理由です。 std::ios_base::sync_with_stdio()はこの仮定の結果であるに過ぎません。

Answer 1

まだビルドされていなかったものの動作を規定するために書かれたいくつかの標準とは異なり、C++標準は、が既に存在するものの動作を記述するために書かれたものです。この標準の作成者は、そのプラットフォームの以前のプレ・スタンダードの実装と同様に動作するプラットフォームに対して、適合するC++実装を設計することを困難にするものを避けたかったのです。

標準に準拠していない追加のプラットフォーム固有の機能をC++ストリームでサポートしていた実装がいくつかあった場合、準拠しているC++実装ではこれらの機能を同時にサポートすることはできません。 Cの<stdio.h>パッケージ。標準の作成者が、そのような拡張されたセマンティクスをサポートできないようにすること、またはストリームを<stdio.h>のストリームから独立してバッファできるようにすることを避けることは不可能かもしれません。特定の実装が、標準がそれを必要とするか否かにかかわらず、両方のライブラリのストリームが同じバッファを使用することを保証することを排除するものがないなら、後者の選択は、より強い要求が有用な実装フィーチャになる可能性があれば意味をなさない。