CS253: Software Development with C++

Spring 2020

IO

I/O Lab                

Description                

In this lab, we’ll do some exercises with I/O streams. The files for this lab are available in ~cs253/Lab/IO. You will modify code in these files. Create a file called recit10.txt, and check it in for credit.                 

Robust input operators                

Consider number.cc. It creates a class called Number that’s a wrapper around an int.                 

  1. How is it that << works for Number, even though operator<< wasn’t defined for this class?
  2. Consider operator>>. It doesn’t check for failure. And, yet, it works properly for:
    • valid numeric input
    • end of input
    • incorrect input
    How can this be?
  3. Now, improve operator>> so that it works properly for input such as “one”, “two”, “three”, “four”, and “five”, as well as working for all traditional numeric input that worked before.
  4. Show your result at this stage.

Using fstream to modify a file in place.                

Consider modify.cc. It copies its input file to its output file, replacing all instances of “Trump” with “Biden”.                 

Note the use of getline(). There are two versions of this function:

Change modify.cc to modify a single file in place. That is, the program should only take a single filename argument.                 

Hints:

  1. If you read the entire file into one giant string, you’re doing it wrong. Your code should work for colossal files that don’t fit into memory.
  2. Just open the file once, in read/write mode.
  3. You can still read the file with getline().
  4. Use the istream::tellg() and ostream::seekp() methods to ask “what’s my current read offset” and to say “where I want to write to”.
  5. This approach only works if the replacement string is the same length as the original string. However, it sure is efficient.
  6. Also show the result at this stage.

For extra fame & glory                

Improve operator>> in number.cc even more:
If it encounters invalid input such as “zork”, it shouldn’t consume the bogus input. It should fail, and leave things such that the next read (assuming that the stream is put back into a good state) would see “zork” again.