1

The C++ standard library provides the following headers related to iostreams:

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

What is the simplest, most sensible rule for when to #include which of these headers? (If the answer is different in different versions of C++, I'm most interested in C++17. And I'm most interested in what is guaranteed to work, not which headers happen to include other headers in libstdc++ or whatever.)

I would like to believe that I can always get by with <iostream>, <fstream> (only if I use fstreams), and/or <sstream> (only if I use stringstreams). This seems to work for simple programs like

#include <iostream>

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

But if I add std::setw(42) to that program, then it stops compiling; I need to include <iomanip> as well in that case.

So the rule seems to be "include <iostream>, <fstream>, and/or <sstream>; and additionally include <iomanip> if you're using any of these manipulators."

If I follow this rule religiously, will I ever run into a case where I need to include <ios>, <iosfwd>, <istream>, <ostream>, and/or <streambuf> in my application code?

Quuxplusone
  • 23,928
  • 8
  • 94
  • 159
  • 1
    Not quite sure I understand the question. There is a pretty clear list of what stuff each header provides, and then you include some header that provides the foo for every foo you use, just like you do with any header. There is nothing special about the IO headers. – Baum mit Augen Aug 10 '17 at 22:41
  • I too am not sure I follow-through completely. Use what you need only when it comes to includes. If it's needed, you should include it, and if it's not being used, remove it. You can't use Foo if you don't #include right? – Yoshi_64 Aug 10 '17 at 22:42
  • 2
    When you need them. If the compiler says it's missing definitions for stuff in IOS, include IOS. – user4581301 Aug 10 '17 at 22:51
  • @user4581301 "If the compiler says it's missing definitions for stuff in IOS, include IOS": That doesn't sound portable. I'm looking for a standard, portable answer if possible. – Quuxplusone Aug 10 '17 at 23:07
  • I apologize. It took a couple reads through, but I think I understand what your question is. And you're right. You can't count on the compiler. – user4581301 Aug 10 '17 at 23:51
  • I'm somewhat tempted to close this as a dup of https://stackoverflow.com/questions/26614983/which-headers-in-the-c-standard-library-are-guaranteed-to-include-another-head – T.C. Aug 11 '17 at 02:20

2 Answers2

2

If I follow this rule religiously, will I ever run into a case where I need to include <ios>, <iosfwd>, <istream>, <ostream>, and/or <streambuf> in my application code?

Well, <iostream> includes <ios>, <streambuf>, <istream>, and <ostream>. And <iosfwd> are just forward declarations, so you don't really need that one either. So... I suppose, yes.

<fstream> gives you all the file-related stuff: filebuf, ifstream, ofstream, and fstream (and their wide counterparts).

<sstream> similarly gives you all the stringstream types and stringbuf.

All that leaves you with is remembering what's in <iomanip>, which isn't that much, but you could always just look it up.

Barry
  • 286,269
  • 29
  • 621
  • 977
0

Will I ever run into a case where I need to include <ios>, <iosfwd>, <istream>, <ostream>, and/or <streambuf> in my application code?

Yes, you might:

<iosfwd> to save compilation time when you have a header which declares, but does not define, stream output operators for your types:

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

<istream> and <ostream> in the cpp file which then defines such operators, again to save compilation time and keeping the scope clean over including <iostream>.

<ios> and <streambuf> probably only if you write a library which defines custom stream classes. Or maybe if you want to call sync_with_stdio() from some central settings class which does not actually do IO.

Felix Dombek
  • 13,664
  • 17
  • 79
  • 131