- You will write an unsorted Linked List class (LLC) with the general data and methods we have discussed in class - and shown in your book (note that the requirements here do not exactly match what is in your book). The list that your LLC will maintain is a list of Nodes which, in turn, will contain the item data we are maintaining. The real data is integer values, but it will be wrapped in an ItemType class that will hold the data and have the ability to provide comparisons between its own data and other data provided along with setting and returning its data. 1. The LLC will be named "USLList" and will contain a linked list of "Nodes" and sevral standard public functions appropriate to operate a linked list. 2. The Node class will be named "Node" and contain member data "ItemType" and a 'next' pointer to another Node. It will provide getters and setters for the member items. 3. The "ItemType" class will hold the single integer member data. It will provide methods to set the member data, retrieve the member data, and to compare other data to its own. - You will be delivering 3 classes named "USLList", "Node" and "ItemType", with .h and .cpp files for each. Your file names will be identical to that of the classes. You will submit the following files: 1. USLList.h 2. USLList.cpp 3. Node.h 4. Node.cpp 5. ItemType.h 6. ItemType.cpp - Testing code - You will write your own test driver, but not submit it to me (nothing you submit to me will have a main() function). I will have my own. A small sample of mine is show. Output is shown below (the output is created by the Putitem(), Printlist() and MakeEmpty[). Deleteltem() and GetLength classes) Sample output (from more test code than shown above) Grade Priority Order: 1. Compiles: for example: Has ALL the functions specified, correctly spelled with the correct interfaces (return types, argument types and order). Has no syntax errors or under/over specified functions. Has no Hinclude of cpp fliles, headers have "Hpragma once" at the top. 2. Operates correctly with the neat cases (no tester malfeasance) 3. Handles nasty input and tough cases 4. Style guidelines (see end of this document) followed and general instructions followed, file names, header comments and.. 5. This falls in the 5% heading for "following instructions": Outputs to the screen in a neat fashion (as suggested in the light blue sections of Specific requirements function descriptions). This will serve as a help to you for development (why do you think I came up with it??). Specific Requirements 1. ItemType Class This class is named "ItemType" and will hold the actual data being managed, which is an integer (all this effort for an integer! (.)) Member data: int data Functions Default Constructor Constructor - that takes in one int value and sets member variable data to it. Destructor Other public functions to provide: 2. Node class This class is named "Node" and will hold a member variable of type "ItemType" and a pointer of type "Node". Member data: ItemType* item // A pointer to our ItemType Node* next //A pointer to the next node (or NULL) Functions Default Constructor Constructor (ItemType newitem) // Takes ItemType argument and sets the member pointer to it. Destructor Other public functions to provide: 3. USLlist Class This class is named "UsLtist" and will hold and maintain a list of "Nodes", instantiating deletine. traversing and finding them as needed. Member data: Node* head Node* curPos Functions Default Constructor // only the default constructor for this class Destructor Other public functions to provide: - Style Guidelines: - Style (It's about readability and quality) - Matching curly braces in the same column - Indent inside curly braces - Whitespace - use enough to help readability, but no more - Use curly braces for code blocks, even if only one line/ - NEVER use single letter variable names (except maaaybe as a loop index-even then avoid) - Use meaningful variable names, but not too long - Comments are good, but often meaningful variable names reduce the need. Use enough comments to clarify, but not clutter - Clean code (clutter creates errors) - Delete unused variables, includes, using statements, etc. - Avoid misspelling a meaningful variable name - Avoid unnecessary use of global variables - MOSTLY - have only one return statement in a function. - Always initialize variables