C++ File Handling: Read and Write Text Files

A file keeps bytes beyond one variable's lifetime

A vector stores values while your program is running. A file can keep data after the process ends, so another run can read it later. A text file contains a sequence of characters and line endings, not a ready-made vector of integers. Your program chooses how to write the text and how to interpret it when reading. Saving data and understanding its format are two separate responsibilities.

A path tells the operating system where to look. A relative path starts from the process's current working directory, which is not necessarily the directory containing main.cpp. An absolute path names a location from the file system's root. std::filesystem::path helps compose path components using the platform's path rules. It does not promise that a file exists, that you can access it, or that arbitrary user-supplied paths are safe.

Use a disposable folder for practice. These examples supply a Workspace helper that creates a fresh temporary directory exclusively and removes only that owned directory afterward. It never reuses an existing folder. The helper is longer than the file operations because safe setup deserves care. Read its purpose first, then focus on the small ofstream and ifstream steps in main. Do not replace its path with an important document just to try the example.

Opening a stream is only the first check

ofstream is an output file stream. It connects writing operations to a file. The first example opens a new readings.txt in the run's own folder, checks the open, writes two lines, then explicitly closes and checks the stream again. That last check matters because buffered data can fail to reach the file during closing. A successful open does not guarantee that every later write will succeed.

The normal ofstream opening mode can replace an existing file's contents. Here that is safe only because the directory was just created and belongs to this run. In an application, overwriting a document requires a clear policy and appropriate user intent. ios::app requests appending instead, but appending is not automatically safer for every format. Do not assume writing is atomic or that a catch block can reverse a partially completed external write.

ifstream is an input file stream. We open it after the output stream is closed, then check that opening and extracting two integers succeeded. The known fixture contains exactly the text we wrote, so the arithmetic is small and predictable. For unknown input, parsing must also check syntax and allowed values; the next lesson studies that in detail. Merely obtaining some integer does not prove the whole record was valid.

• Create a fresh workspace that this run owns.
• Open the output file, write, close and check.
• Open the input file and check the reads.
• Print a result only after the required operations succeed.

End-of-file is a result of reading, not a prediction

Use while(getline(in, line)), not while(!in.eof()). The first form asks the read operation whether it obtained a line. The second asks about an earlier stream state and can cause an extra failed read to be treated as data. In the example, the last line has no newline after it, but it is still a valid line. The successful read must be processed before a later attempt discovers there is nothing more.

After a line loop, check why reading stopped. Reaching the end is normal when the task reads the whole file. A bad stream or a stop without end-of-file can indicate a read problem. Do not silently report a complete file after a genuine I/O error. Also do not call clear and continue blindly; clearing flags does not repair a disconnected device, restore missing bytes or explain a malformed data format.

Our simple counter uses a tiny file created by the program. For an untrusted large file, add practical limits to the number and size of records you accept. A file extension does not enforce a format or a size. A path with .txt can refer to unsuitable data or something your program cannot open. Handle each boundary in the operation that actually knows its requirement, rather than trusting the filename alone.

Streams own handles; your format still needs checks

A file stream closes its handle when destroyed. That is RAII. We explicitly close output when the program needs to check whether saving finished before announcing success. The Workspace destructor then attempts to remove its own temporary folder using an error-code operation that does not throw. Cleanup failure is not silently claimed to be impossible; it can leave a practice folder behind. The helper never targets the home directory or an existing project folder.

The clock-based name is only a candidate name, not a promise of uniqueness. create_directory is the step that claims a new directory; a preexisting candidate is not reused. This protects ordinary practice runs from accidental collisions. It is not a complete defense against a hostile process altering directories under the same account. Production temporary-file and upload designs need stronger permissions, platform-specific protections and a threat model suited to their environment.

The browser sandbox has temporary writable storage but no host-folder mounts. If the compiler service is available, these examples use that temporary storage and the files disappear after execution. No example creates a downloadable file in the website. A native local run uses your operating system's temporary directory instead. Keep those environments distinct when explaining what you verified. Repair a missing-file error by checking the intended path and source, not by switching to random absolute paths.

Save bounded readings and verify the saved copy

Read count zero through five and that many whole integers from minus one hundred through one hundred. Validate all required input before creating the workspace. Save each reading on its own line in readings.txt, close and check the output, then reopen and read the saved values. The file is generated by this program, but the lab still checks that each read succeeds, stays in range, and that no extra non-whitespace data remains.

Only after a complete verified read should you print Count and Total. Zero readings create an empty file and produce a zero total. Invalid input prints Invalid input with status one. A workspace or file failure prints File operation failed with status two. Test negative values, both bounds, an empty set, missing required lines and a simulated wrong read path. Do not claim that a successful round trip proves crash-safe saving or permanent storage; this is a checked temporary-file exercise.