Project 3 Corrections and Clarifications

Updated 10/15/2019

Most recent items appear first

Page numbers refer to the pdf document


NOTICE:

This document is part of the project specifications.

Your solution must follow these corrections and clarifications.


Correction to specifications for detecting invalid input. See Project 1 document, section "
Save File Format and Load Input Rules" P. 6, bulleted list near top of page.

Add  to the bulleted list the same specification as in Project 0:


Explanation:

This specification was added to Project 0, but I failed to add it to Project 1, and also Project 2 and 3, which rely on the Project 1 specification. My goal was to keep the tedious input validity checks to a minimum. Many students implemented it anyway in Project 1, but not everybody. Given the ambiguity in the situation, both approaches were accepted in evaluating Project 1 code quality, and it was not checked for in the Project 2 spot-checks. In most scenarios, omitting this check will not have any effect because some other failure will occur. However, it turns out that there is a scenario in which a negative number of items can be present in an input file, but if not checked, results in a bogus restore with no "invalid data" error message.  Thus this trivial check is reinstated for Project 3. Note also that the Project 1 document in this section calls for not doing additional validity checks beyond those specified -- this continues to apply to Project 3.


Some students who applied the check in Project 1 did so with a "read non-negative integer from file" helper function which tended to obfuscate rather than clarify the code. So for Project 3, implement this check in place when the input is read (no helper function). In fact with C++ file input, the code involved can be so minimal and so transparent that a helper function hurts rather than helps the code clarity. If your code for this looks complex, ask for help.


Clarification of Utility.h specifications - #includes in Utility.h must be limited to headers that are required for Utility.h to compile.

Utility.h should not #include headers that other components need to include, even if more than one other component needs to include them.


The concept of the Utility module is that it has declarations or definitions that are needed in more than one other component; but this concept does not apply to header files included in Utility.h. Instead, the principle is that header files should include the minimum number of other header files, as stated in the the header file guidelines.

So, the headers or implementation files for these other components should #include the headers that they need. Utility.h should #include only the headers needed for Utility.h to compile by itself, as described in the Header File Guidelines.


Remember that the same principle applies to all header files in the project. Check the C++ Header File Guidelines.