3

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?

Improve this question
6
  • 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. Commented Aug 10, 2017 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 <Foo> right? Commented Aug 10, 2017 at 22:42
  • 2
    When you need them. If the compiler says it's missing definitions for stuff in IOS, include IOS. Commented Aug 10, 2017 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. Commented Aug 10, 2017 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. Commented Aug 10, 2017 at 23:51

2 Answers 2

Reset to default
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.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

<ios> includes <iosfwd> anyway.
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.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.