我什么时候应该#include <ios>`,`#include <iomanip>`等?

时间:2017-08-10 22:36:57

标签: c++ header-files iostream

C ++标准库提供以下与iostream相关的标题:

<ios>
<iosfwd>
<istream>
<ostream>
<streambuf>
<iostream>
<fstream>
<sstream>
<strstream> [deprecated]
<iomanip>

什么是最简单,最明智的规则,何时#include哪些标题? (如果答案在不同版本的C ++中有所不同,我对C ++ 17最感兴趣。而且我最感兴趣的是保证可以工作,而不是哪个标题恰好包含其他libstdc ++中的标题或其他。)

我想相信我可以随时使用<iostream><fstream>(仅当我使用fstream)和/或<sstream>(仅当我使用字符串流时)。对于像

这样的简单程序,此似乎可以正常工作
#include <iostream>

int main() {
    std::cout << std::hex << 42 << std::endl << std::flush;
}

但是如果我将std::setw(42)添加到该程序,那么它就会停止编译;在这种情况下,我还需要包含<iomanip>

因此规则似乎是“包括<iostream><fstream>和/或<sstream>;如果您使用{{3}中的任何一个,还需要包含<iomanip>操纵者。“

如果我虔诚地遵循这条规则,我是否会遇到需要包括<ios><iosfwd><istream>,{{1}的情况我的应用程序代码中有/和{或<ostream>

2 个答案:

答案 0 :(得分:1)

  

如果我虔诚地遵循这条规则,我是否会遇到需要加入<ios><iosfwd><istream><ostream>和/或{ {1}}在我的应用程序代码中?

好吧,<iostream>包括<streambuf><ios><streambuf><istream><ostream>只是前向声明,所以你也不需要那个。所以......我想,是的。

<fstream>为您提供了所有与文件相关的内容:<iosfwd>filebufifstreamofstream(及其广泛的对应方)。

<sstream>同样为您提供了所有fstream类型和stringstream

所有让你失望的是记住<iomanip>中的内容,这不是那么多,但你总是能够查找它。

答案 1 :(得分:0)

  

我会遇到需要在我的应用程序中包含<ios><iosfwd><istream><ostream>和/或<streambuf>的情况代码?

是的,您可能会:

<iosfwd>可在您有一个标题声明但未定义类型的流输出运算符时节省编译时间:

#include <iosfwd>
std::ostream& operator<<(std::ostream& os, const MyType& my);

<istream><ostream>在cpp文件中,该文件随后定义了此类运算符,以再次节省编译时间并在包括<iostream>的情况下保持作用域整洁。

<ios><streambuf>仅在编写定义自定义流类的库时才可能。或者,也许您想从某个实际上不做IO的中央设置类中调用sync_with_stdio()