CSCI 3342 Submission 09
Implementing a Simple Four-Function Calculator

Overview

This submission requires you to implement a simple, four-function calculator which reads its input from the command line. You are supplied with a shell file for your main() driver. This file also contains a DisplayUsage() function to save you the busy-work of creating it. [You might find it interesting to note the different syntax for the "raw string" in this function. See if you can figure out why this syntax needs to be used in this case.]

You are also provided with a doxygen-documented .hpp file containing the prototypes of four functions which your main() function can call to perform its task of reading and evaluating an arithmetic expression. You must implement these functions, at a minimum, to complete the program. You are also permitted,should you wish to do so, to implement additional "helper" functions that may be called by the four specified functions when and as appropriate.

You will find it very helpful to study the "Arithmetic expressions and binary expression trees" section of the Lecture Topic Outline page on the course web site before starting work on this submission. Look in particular at the last section entitled, "Additional notes on implementing a calculator for fully-parenthesized arithmetic expressions".

Steps to Perform

1. Copy the demo executable and run it, first with no command-line parameters, and note that it displays (in the usual way) an opening screen containing ID information, followed by a short program usage description, and then it terminates. Your program must behave in the same way, except of course that the ID information must be yours. [Note that there is a second demo executable that contains a "trace" feature showing the steps taken to build the binary expression tree in memory before the evaluation takes place. You do not have to implement this trace feature.]
2. Study the implementation notes referred to above until you understand what the input and output of this program look like, for input that is both nicely formatted and valid, and input that is badly formatted but still valid, as well as invalid input.
3. Next, run the program with lots of different sample input, both valid and invalid, to confirm your understanding of how the program works.
4. Write pseudocode for a solution of this problem and revise it until you are convinced that a program that implements your pseudocode will be the one you want. This essentially means writing pseudocode for the four functions whose prototypes are given, plus any additional helper functions you think you might need, since you are provided with pseudocode for the main driver.
5. Translate your pseudocode into C++ and continue testing your program until you are convinced it works correctly.
6. Make sure both of your source code files are identified, formatted, and documented properly, our current rules and guidelines,including doxygen-style documentation for any additional helper function that you implement.
7. Finally, copy the required files to the submissions/s09 subdirectory in your uxx account.

Additional Notes, Requirements, Specifications and/or Hints (if any)

1. A valid expression contains a valid arithmetic expression and nothing else, i.e. no other non-blank space characters. This means, for example, that a valid arithmetic expression followed by one or more garbage characters before the end-of-line would be interpreted as an invalid input line.
2. A valid arithmetic expression according to our definition can still cause problems (division by zero, for example) but your program (and demo_calculate) are not expected to deal with this kind of problem. It is assumed that a valid arithmetic expression also has a value which can in fact be calculated. Otherwise, the program is not responsible for what happens.
3. Note that no matter how badly the input is formatted, that same input is displayed in a consistent, nicely-formatted way, provided of course that it is in fact valid input.
4. When you are testing this program, some of the expressions you type in for it to evaluate may be quite complex. If you type such an expression in and there is a problem requiring a code revision the next time you test you will have to type that same expression in again. This can quickly become quite tedious, which is a really good reason for getting your testing script up and running early.
5. For simplicity, and since you are building a single small tree, you need not worry about destroying the tree at the end of the program. This means that you are technically not dealing properly with the memory leak that occurs. But there is no danger of "running out of memory" since the program itself actually ends after each expression is handled, so the operating system will reclaim any memory that was used by the program, in preparation for the next run. This would not be a good idea if the program remained running and asked for a second expression, then a third, and so on.
6. You may find it useful to note here that the peek() member function of an input stream can be used to see what the next character is in the input stream without actually reading and removing it. Also possibly helpful is the fact that the built-in constant EOF can be used to test for the end of any input stream (standard input, file input, or string stream input).