允许C++和C流独立缓冲有什么潜在的好处?

Pra*_*tic 5 c++ standards iostream buffering c++-standard-library

C++ iostreams控制C++流是否必须与C流同步std::ios_base::sync_with_stdio().关闭流同步允许标准库实现为C++流和C流使用独立的非同步缓冲区,以潜在地提高性能.

为实施者使用单独的独立io缓冲区用于C和C++流,为什么要打开一扇门是重要的?与一组io缓冲区相比,我没有看到这可能如何提高性能.在程序级别允许标准库一组io缓冲区可以减少通常昂贵的对底层OS io工具的调用次数,但是两组io缓冲区的优势是什么呢?

是否存在技术原因,C和C++流的单独缓冲区可以使性能受益,或者设计只是一个历史工件?

它是否与委员会有什么关系,希望C++实现者能够通过构建现有的C标准库实现来实现C++标准库?


我正在寻找的不仅仅是"标准这么说".

如果需要操作系统特性来解释基本原理,欢迎使用答案作为实际操作系统提供的io工具的示例,或者解释假设但合理的操作系统.


编辑:为了澄清,问题不是同步流可能会损害性能的原因.问题是为什么C++标准的设计假设可能有两组io缓冲区,为什么保持开放这种可能性对实现者有用.std::ios_base::sync_with_stdio()恰好是这种假设的结果.

sup*_*cat 4

与某些为规定尚未构建的事物的行为而编写的标准不同,C++ 标准与 C 标准一样,是为描述已经存在的事物的行为而编写的。该标准的作者希望避免任何会导致难以为平台设计一致的 C++ 实现的情况,该实现与该平台的早期标准前实现一样有效。

如果某些实现的 C++ 流支持标准未强制要求的一些附加平台特定函数,则符合标准的 C++ 实现可能无法同时支持这些函数,同时还使用与 C 包中相同的缓冲结构<stdio.h>。标准的作者可能无法避免要么要求实现不能支持这种增强的语义,要么允许它们独立于<stdio.h>. 鉴于没有什么可以阻止特定实现保证两个库的流将使用相同的缓冲区,无论标准是否要求,如果有可能对任何有用的实现功能提出更强的要求,则后一种选择将是有意义的。