Labs

PR1EN15: Files

Lab materials

Lab tasks

This lab has two tasks, both of which have an extra task extending the base features.

Task 1 [W15-1]: Odd or even

The purpose of this task is to practice using multiple files at the same time while getting all the technical nuances correct. It will also reiterate over the command line argument topic from last week

Requirements
  • The name of the input file is given as a command line argument
    • The name is always the first argument passed
    • If there is no input file, the program must close itself gracefully
  • Read an unknown number of integers from a file. Numbers are separated either by a space or a newline. There can be infinitely many numbers.
    • Example: 5 3 -6 0 25 955 -1024
  • The numbers will be written into output files based on the following principles:
    • 0 or lower numbers are ignored
    • Positive odd numbers are written to the file odd.txt
    • Positive even numbers are written to the file even.txt
  • Follow the basic best practices for working with files
    • Check if the file opened
    • Notify the user if the file doesn’t open that includes the name of the file which failed to open
    • Close all files before exiting
  • If the input file is corrupted, the program must halt upon detecting it
    • E.g. 9 -5 hey 14
Warnings and hints!
  • Be very careful with infinite loops when writing to files. You can fill up the drive space in just a few seconds. This also causes physical wear on SSDs and can kill your operating system.
  • Write the output on the screen during testing so you can follow along what’s happening and to which file data is written to. This way it is easier to detect if something goes wrong and terminate the program ( ctrl+c ) .
  • If the first file opened successfully, but the second one didn’t, you must close the first one before exiting!
Extra task 1 [W15-3]: Statistics

Add the following statistical features to the base task

  • Find and print
    • Sum and arithmetic mean
    • Smallest and greatest number
  • The results must cover all the values from the input file regardless of the value (this includes negative numbers)
  • You’re not allowed to read the file more than once
  • Program must still work with infinitely many numbers

Extend support for command line arguments by adding support for verbose mode (“chatty”)

  • All features from the base task must remain functioning
  • Your program must detect if the argument -v  (verbose) was passed to it
  • Program must display when a file is opened, which file it was and in which mode it was opened in.
  • Program must display all numbers read from the input
  • Program must display if the value was written to an output file, including which file, or discarded
  • Program will display closure of each file
  • If verbose is not active, the program should not print any lines in the output

Verbose is a widely used practice to simplify both debugging programs and help with using the programs to figure out what is going wrong when using them (e.g. operator error). This is more widely used in command line based programs, but also available in many graphical programs.

Examples of how the program should be executed:

  • ./parity input_nums.txt
  • ./parity input_nums.txt -v

Task 2 [W15-2]: Processing penalty notices

Your task is to create a program that can compose penalty notices from speed camera measurement data.

Additional references

The task is composed based on the following public information

Principles of composing penalty notices
  • The measurement uncertainty is 4 km/h (50 – 90 km/h speed limit area)
  • The processing of the penalty is started if the vehicle exceeded the speed limit by at least 3 km/h.
  • Every km/h that is exceeded from the limit is fined by 7€.
  • Maximum penalty is 420€.
  • If the speed limit was exceeded by more than 50 km/h, a general procedure is started.
  • E.g. If a vehicle is driving 99 km/h and the speed limit is set at 90 km/h, the fine is going to be 35€.
Input file

Download your input file from here: 14_2_speeds.txt

Input file contains one measurement per line. The structure of the input file is: <registration number> <measured speed> <speed limit>

  • Car registration number – up to 9 characters
  • Measured speed – positive integer
  • Speed limit – positive integer
Output files

Your program must create two output files – one with processed fines and another for general procedure notices.

First file will contain fines. This file will only contain  fine notices that the owners of the respective vehicles need to pay. Each fine notice will be written on a separate line. Every line has three data fields:

  • Car registration number
  • Exceeded speed without the measurement uncertainty (how many km/h in excess was measured)
  • Penalty (amount to be paid)

Expected output:

The contents of the second file are notices for general procedure. You can only write those entries against whom the general procedure will be started. The format for those notices is as follows:

Expected output:

Extra task [W15-4]: Settings

Due to regulations and laws changing, it must be possible to easily adjust the settings that the application is using. Figure out a way to implement it so that the following requirements would be satisfied.

1. settings for processing of notices must be configurable:

  • Fine size for every exceeded km/h (e.g. 3€, 5€, 10€)
  • Maximum fine size (e.g. 100€, 190€, 300€)
  • Speed excess to start the general procedure (E.g. 40 km/h, 61 km/h, 100 km/h)

2. adjusting settings must be simple, but stay invisible during day-to-day operations

  • Adding the ability to adjust settings must not add extra time to use the program normally.
    Thought: The officials working with the application on a daily basis don’t want to waste time on adjusting settings or even confirming current settings each time they use it.
  • Changes must persistent
    Thought: Values will typically be updated when the laws are changed. It is done quite seldom, so the operator doesn’t want to (re)configure it on a daily basis.
  • Changing the setting must not require recompilation of the program.
    Thought: You wouldn’t expect officials to know how to edit source code or recompile a program. Even if done by the IT department, they are just support, not developers.

After this class, you should

  • know how to open and close files.
  • know how to check if a file opened.
  • know the difference between file modes and how they behave if the file exists and if it does not.
  • know in which situations files may fail to open when opened for reading or for writing.
  • know different ways of addressing files.
  • know why buffering files is important and what problems it may cause.
  • know how to read and write files.

Additional content