Great questions! Let's break them down one by one to clear things up:

1. Why does C++ provide iostream when istream and ostream already exist? #

The core motivation here is bidirectional stream support. istream is built for input-only operations, while ostream handles output-only tasks—but many real-world stream resources (like files, or in-memory string buffers) need to support both reading and writing.

Instead of forcing you to create and manage two separate istream and ostream objects (which would need to share the same underlying buffer and stay synchronized), iostream inherits from both base classes (using virtual inheritance to avoid the diamond inheritance problem) to offer a single, unified interface for bidirectional I/O. This makes code cleaner—you don’t have to juggle two distinct objects for one stream source/destination—and eliminates potential inconsistencies that could arise from managing two independent streams pointing to the same resource.

2. In VS2019, ostream is 72 bytes, istream 80 bytes, iostream 88 bytes—so the "resource saving" argument doesn't hold? #

First, let’s clarify: the "resource saving" claim isn’t about the raw size of the stream objects themselves. It’s about the overhead of managing two separate stream instances versus one.

The reason the sizes are so close is due to how the C++ standard library implements these classes. Both istream and ostream share most of their underlying state—things like a pointer to the streambuf that handles actual data transfer, formatting flags, error state indicators, etc. When iostream inherits from both, it doesn’t simply add up the sizes of the two base classes (thanks to virtual inheritance and shared member data in the implementation).

The real efficiency gain comes when working with bidirectional streams: using a single iostream-derived object (like fstream) means you don’t have to maintain two separate stream objects with duplicate state (or worry about syncing their views of the underlying buffer). That’s where the resource savings and practical value lie, not in the object’s byte count.

3. Why does istringstream allow construction with std::ios::out? #

istringstream inherits from iostream, which means it has both input and output capabilities under the hood—even though its primary intended use is reading from a string buffer.

Allowing std::ios::out in the constructor serves two key purposes:

• Interface consistency: Stream classes follow a common API pattern where you can specify open modes, even if some modes are less commonly used for that specific stream type. This keeps the library predictable and easy to learn across all stream classes.
• Practical flexibility: There are scenarios where you might want to write to the underlying stringbuf first, then read from it. For example:

  std::istringstream iss("initial content", std::ios::in | std::ios::out);
  iss << "updated content"; // Write to the buffer
  iss.seekg(0); // Reset the read position to the start
  std::string result;
  iss >> result; // Now read the modified data
  

  Without allowing std::ios::out, you’d have to use a separate ostringstream, write to it, then copy its content to an istringstream—a more verbose and less efficient approach.

内容的提问来源于stack exchange，提问作者Kamichanw