CSCI 3342 Submission 01
Displaying ASCII Characters and Codes, Part 1

Important Documents (for this and all subsequent submissions)

A summary of coding style rules and guidelines to which you should pay close attention is given in Style Rules, and the course policy on cheating (to which you should also pay close attention) is given in Policy on Cheating.

Overview

This first submission is Part 1 of a three-part submission, with each of the later parts building upon the earlier ones. This one is designed to get you "up and running" with basic C++ programming. By the time you submit your final version of the required program for Part 3 (Submission 03), you should be quite comfortable with our Linux development platform and the course submission procedure, and if you are not already a Vim user I hope you will be well on your way to becoming one by then as well. In addition, this first submission will jump-start the (necessarily ongoing) process of your familiarization with the details of the C++ programming language, and how it is similar to, and different from, the Java programming language.

We will discuss in class and/or lab everything that you need to know for this submission. We will likely discuss other things as well. Do not think that everything we discuss needs to be applied to this submission. Also, do not think that you will have to go cruising around the web to find something you need to know. More important will be to "tune in" to our Zoom sessions,pay close attention to the presentation, and do lots of follow-up practice.

This week's required program itself does something relatively simple. It just displays user-chosen ranges of ASCII characters, using a certain output format. Along with each character in the range, the decimal, octal and hexadecimal numerical codes for each character are also displayed. The thing requiring the most thought will be getting the output format in the required form.

You are provided with a "shell" program, which outlines the basic structure that your code must follow. It also contains some pseudocode which should be helpful, and thus this shell provides you with an excellent starting point for your program development. You are getting all of this because this is the first submission. In subsequent submissions you will not be given this kind of detail, but you will be expected to follow the pattern shown here for all later assignment submissions.

Steps to Perform

1. First copy to the working directory in your account all four of the supplied files.
2. Run the executable without any command-line parameters and study the output. Your opening screen, and the following screen, should have the same content with exactly the same format when your program is run without any command-line parameters, except (of course) for that line of the display that must contain your identification information. Study the program description until you have a good sense of how the program will behave when you give it some input.

   Note in particular the format and behavior of the pauses at the ends of the opening screen and the information screen. These will happen automatically when you use the instructor-supplied function and class to display these two screens. The line containing the date and time of the executable build is also produced automatically when you use the DisplayOpeningScreen() function.

3. After you have studied the program description, run the program enough times with a wide variety of inputs to get a good feel for just how the program displays its output. Note carefully where the pauses appear, the vertical and horizontal spacing, the fact that if there are fewer than four values only the required number of columns are labeled with headers (which also happens if there is a second screen of output), and the fact that the screen is cleared before the display of the table of values. Do not proceed until you are completely comfortable with the program behavior.
4. This next step is really important, both now, and for subsequent submissions. Examine the testing script my_tests_partial.sh in an editor and note how it is structured to do the testing. Then run the script, observe the output, and reconcile what you see when you do this with what you saw when you looked at the script. We have supplied you with this testing script, to which you are required to add some tests of your own. The takeaway here is that you should always have such a testing script and we will often require that such a testing script be a part of the submission for an assignment, as it is for this one. [It's important to note that the supplied testing script runs demo_display_ascii1, so to test your own executable, namely display_ascii1, you will have to change the name of the executable in the testing script.]
5. Design first, then (and only then) write a C++ program that will emulate as closely as possible the behavior of the sample executable. This is essentially an exercise in what is called reverse engineering, since you already have the end product before you start, in the form of the demo executable. Start with the supplied "shell" when you begin to code, but be sure to rename it properly and modify the opening comments appropriately as your first step.

   All comments that start with //-- are meant to be deleted after you do whatever the comment says to do.

6. When the program is working correctly, make a final check before submission to ensure your source code is identified, formatted, and documented properly. We will discuss what proper identification and documentation means, but see the link to style rules above, and there are also menu links on the course home page that provide guidelines for submission, program identification, source code documentation, C++ coding style and other good general programming practices.
7. Be sure as well that you have completed the self-assessment comment of your submission to inform the marker either that everything is complete and working according to the specifications, or to inform the marker what is still missing or not working properly in your submission.
8. This week, and from now on, you must make sure that each of your submissions follows the required rules and guidelines, which we will have discussed in lectures and lab/recitations. The supplied shell gives you a great deal of what you need to know this time around, and in the proper form, but typically you will not have such a shell. And you should get in the habit of using the fcc command that will be very helpful with your formatting.
9. Finally, submit the required files by copying them from your working directory to the appropriate submission subdirectory in your uxx account.

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

Because this is the first submission, this last section of the description contains more informational reminders than are likely to be present for any subsequent submission.

1. The first thing to note is that you do not have to make your program do any error checking other than what is explicitly required, and this will be the case for all subsequent submissions.
2. For this first submission, to keep things simple put all of your code in your main() function. So ... don't worry about creating any other functions, and spend your development time instead on getting the program to produce the right output in the correct format.
3. You must use the instructor-supplied DisplayOpeningScreen() function to display your first screen when your program runs with no command-line input. You must also use the instructor-supplied TextItems class and display_ascii1.txt textfile to display the second screen. And finally, you must use the supplied Pause() function to get your program to pause in the correct places.
4. Submit early, and submit often! In fact, you should submit after completing each logical stage in your program's development. That way, if something goes wrong toward the end you will have at least submitted a working program with at least some (and perhaps many) of its specifications already met. You can submit as many times as you like and let the latest version of a file overwrite any previously submitted version, which is presumably what you would want to happen.
5. Finally, what about testing? How do you, in fact, know if your program is working properly? The sad truth is that you never really know, but the proper amount of the proper kind of testing can certainly increase the level of confidence that you have in your software. Note that you are supplied with a partial testing script that shows you the syntax for such a script and contains a few sample tests, but you are required to add more suitable tests for your program and then submit a more complete testing script as one of the files to be submitted for this assignment. Here are some suggestions for the kind of testing that you should perform with the demo executable as well as with your own program:
   • No command-line input
   • Ranges containing 1, 2, 3, 4, 5, ..., 12 values
   • The range containing all printable values
   • A range containing enough printable values to exactly fill a screen, and no more
   • A range containing enough printable values to exactly fill a screen, plus 1, 2, 3 values and so on, until you have all values
   • Enough printable values to exactly fill a screen, less 1, 2, 3 values and so on, to make sure this is working too
   • Any other combinations you think may be "interesting", or may possibly cause a problem if the user should happen to make that choice
   • And last, but not least, make sure you test to make sure that your program does the required error-checking.