std::ifstream is the input file stream class from <fstream>. It plugs a file into the same stream interface as std::cin, so >> and getline work the same way they do on the console. This chapter covers opening a file, the two main read patterns (>> and getline), how to tell end-of-file apart from a real read failure, the issues that come with mixing the two, and how to load a CSV-shaped product catalog into a std::vector.

There are two ways to associate an ifstream with a file on disk. The constructor takes a filename and opens the file immediately. The open() method does the same thing on an already-constructed stream, which is useful when the filename isn't known until later.

is_open() returns true only if the file was opened successfully. If the file doesn't exist, the path is wrong, or the process doesn't have permission, is_open() returns false and the stream is set into a failure state. The constructor doesn't throw and the program keeps running, so the check is needed.

Skipping that check is a common file-I/O bug in C++. The stream behaves like an empty input, every read fails without warning, and the loop body never runs. The result is a program that "doesn't print anything" until someone notices the file path was wrong.

A short helper for the example files used throughout this chapter, so every program is self-contained:

The default of std::ifstream (open for text reading) is the right choice here.

There's no need to call close() at the end. The ifstream destructor closes the file automatically when the object goes out of scope. That's RAII at work, the same pattern that makes std::vector and std::unique_ptr free their memory automatically. Calling close() explicitly is fine to release the file early, but it's never required.

The cyan box is the constructor call. The orange diamond is the only branch that matters: did the OS hand back a valid file? Success (green) means subsequent reads work. Failure (red) puts the stream into a fail state where every read returns garbage and the flags stay set. Either path ends at the teal box, where the destructor releases the OS file handle.

The >> operator on a stream reads one whitespace-separated token at a time and parses it according to the type of the target variable. This is the same operator used with std::cin, so the rules carry over: leading whitespace is skipped, the read stops at the next whitespace, and the variable's type determines how the characters are interpreted.

For numbers, this is the right tool.

>> reads three doubles, one at a time. The spaces between them are ignored, as is the trailing newline. Each read advances the stream position past the token and any whitespace that follows.

For an unknown number of values, pair >> with a while loop. The stream itself evaluates to true while reads keep succeeding and false once a read fails (either because of an actual parse error or because the end of the file was reached).

The while (in >> price) loop is the standard pattern. It reads one value, checks the stream state in the same expression, and exits cleanly when the file is exhausted. There's no off-by-one bug to worry about, and no need to check eof() separately. The section on end-of-file detection explains why that matters.

>> works the same way for strings. It reads one whitespace-separated token into a std::string, which means a name like USB Cable (with a space) will be read as two tokens, not one. The example files in this chapter use underscores to keep names a single token; for real multi-word names, use getline or a separator like a tab or comma.

Two reads per iteration: one string, then one double. Both reads are checked at once in the while condition. If either fails, the loop exits.

When records aren't whitespace-separated, or when a value can contain spaces (such as a product name with a space in it), >> falls apart. The fix is std::getline, which reads everything up to the next newline into a string and discards the newline itself.

std::getline(in, line) is a free function from <string>, not a member of ifstream. It takes the stream and a string by reference, fills the string with the next line, and returns the stream itself. Like >>, the stream evaluates to true while reads succeed and false once the end of the file is reached.

The newline character is consumed by getline but not stored in line. If the file uses Windows-style line endings (\r\n), the \r will be left at the end of each line on Linux and macOS, which is a common source of "why does my string have a weird character at the end?" bugs when files are shared across operating systems.

getline has a three-argument form that accepts a different delimiter. The default is '\n', but any single character is valid. This is handy for reading CSV-like data where fields are separated by commas.

There's a trailing blank line in the output. That's the newline at the end of the file: getline with delimiter , treats \n as another character, so the last "field" is "featured\n". The fourth iteration's tag is the string featured\n, which prints with an extra newline. Real CSV parsing usually handles this by stripping \r and \n after the read, as the structured records section below shows.

getline reallocates the string's buffer if the line is longer than the string's current capacity. For very long lines (megabytes) this can be visible. The fix is to string.reserve(N) the string before the loop given a known upper bound on line length, though for most files this isn't measurable.

Streams carry four state flags describing the last operation: good, eof, fail, and bad. The matching member functions read them: file.good(), file.eof(), file.fail(), file.bad(). There's also file.rdstate() which returns the raw bitmask, though it's rarely needed.

The contextual conversion if (file) (or while (file >> x)) checks for failbit and badbit. EOF alone does not make the stream evaluate to false until a read past it actually fails. That distinction is the source of the most famous bug in C++ file I/O.

What's wrong with this code?

The last number prints twice. The reason: eof() only becomes true after a read tries to go past the end and fails. So the loop runs four times, not three. On the fourth iteration, in >> n fails (the stream is already at EOF), n keeps its previous value of 30, the stream's failbit gets set, and 30 is printed again. Only after that does the next eof() check finally return true and the loop exits.

Fix: check the read itself, not eof() in isolation.

The fixed version checks the result of the read itself. When >> reaches EOF and can't extract another integer, the expression in >> n evaluates to false and the loop exits cleanly. No duplicate value, no off-by-one. This is why every reference and style guide recommends while (stream >> x) or while (std::getline(stream, line)) instead of while (!stream.eof()).

The same pattern handles parse errors too. If nums.txt contained 10 20 banana 30, the read of banana into an int would set failbit, the loop would exit, and the program wouldn't try to use a garbage value of n.

After the loop exits, the stream can report why it stopped. eof() is true if the read hit the natural end; fail() is true if a read couldn't produce a valid value of the requested type. The distinction matters when distinguishing a clean read from a malformed file. fail() is also true when both have happened, so check eof() first when only parse errors matter.

To keep reading after a parse error (skip the bad token and continue), call in.clear() to reset the flags, then consume the offending characters with in.ignore(...).

Three possible outcomes for a read, three different post-mortems. The orange diamond is the read itself. Green means success, teal means the file ran out at a normal stopping point, red means the data didn't match the requested type. The two failure branches share failbit (which is why while (in >> x) exits in both cases), but eofbit is what tells them apart afterwards.

When a file has a mix of formats, combining >> and getline is sometimes necessary. This is where the leftover-newline trap shows up. >> reads up to (but not past) the next whitespace, leaving the newline character sitting in the stream. The next getline call then sees that leftover newline, reads zero characters, and returns an empty string.

What's wrong with this code?

The first getline returns an empty string, the program reads two real names instead of three, and the last name is dropped without notice. The issue: after in >> count consumes the 3, the newline that ended the line is still in the stream. The first getline reads up to that newline (which is right there), produces an empty string, and consumes the newline. Now the stream is positioned at the start of USB Cable, but one of the three iterations is already gone.

Fix: call in.ignore(...) after the formatted read to discard the leftover newline.

ignore(count, delim) discards up to count characters, stopping early if it sees delim. The idiom ignore(std::numeric_limits<std::streamsize>::max(), '\n') means "throw away everything up to and including the next newline". std::numeric_limits<std::streamsize>::max() is the largest count the function accepts, which effectively means "as much as needed". The constant lives in <limits>.

A shorter form, in.ignore(), throws away one character. That works for the common case where the leftover is exactly one newline, but it's fragile: if the formatted read left whitespace or trailing characters that aren't a single newline, the next read would be stuck. The numeric_limits form is the safe default.

The rule of thumb: every time the code switches from >> to getline on the same stream, call ignore in between. Switching the other way (from getline to >>) doesn't need it, because >> skips leading whitespace by default.

ignore reads characters from the stream one at a time until it hits the delimiter or the count, so it's O(n) in the number of characters skipped. For the typical "skip the rest of a short line" case this is a few bytes and is irrelevant. For files where lines could be megabytes long, prefer using getline everywhere and parsing each line manually.

A real-world file is rarely a flat list of values. It's usually records with multiple fields, often separated by commas or tabs. The pattern that works for almost every text file: read one line with getline, then parse the fields out of that line.

The cleanest way to split a line into fields is std::stringstream from <sstream>. A stringstream wraps a std::string and exposes it through the same >> and getline interface as a file. The usage is straightforward.

A complete example: read a CSV-like product catalog and build a std::vector<Product>.

A few details matter. The outer loop uses getline(in, line) to grab one record at a time. The inner work happens on a stringstream built from that line, so the parsing never touches the underlying file. getline with the delimiter ',' splits the line into three pieces. std::stod and std::stoi (from <string>) convert the price and stock strings into numbers; they throw on bad input, so a safe parser wraps them in try/catch.

The name is read with getline(ss, p.name, ',') rather than ss >> p.name. That's deliberate. The token-based >> would stop at the first space, splitting USB Cable into two fields. getline with comma as the delimiter respects spaces, which is the correct behaviour for product names.

A simpler version without <sstream> (using find and substr on the line) works too, and older code uses it. Stringstreams are more flexible and slightly easier to extend, so they're the modern default.

For binary data (an image file, a serialised struct), text-mode reads with >> and getline don't apply. The right tool is file.read(buffer, count), which copies raw bytes without any parsing or newline translation. The default open mode of ifstream is text mode, which on Windows performs some \r\n to \n translation; binary mode skips that.

The next chapter mirrors this one for output: std::ofstream, the << operator on file streams, and patterns for writing reports, logs, and CSV data. After that, the File Modes chapter covers the full set of flags that change what "open a file" actually does: appending instead of truncating, opening for both read and write, opening in binary mode, and so on. Once those three chapters click into place, reading and writing any text-format file becomes straightforward.