The program reads data from two files, itemsList-0x.txt and inventoryList-0x.txt. File extensions on Linux may be arbitrary–i.e., these files could have been named with .dat as the extensions.

The first file, itemsList-0x.txt, lists all possible items. Each line represents one item in the form id name.

Example 1: Sample itemsList-0x.txt0 Air 1 HP Potion 2 MP Potion 5 Iron Ore 3 Bow Tie 4 Dirt 6 Diamond Ore 7 Iron Ingot 8 Diamond 9 Diamond Block 

The second file, inventoryList-0x.txt, lists each individual inventory–or storage chest–followed by a list of items.

Example 2: Sample inventoryList-0x.txt# 5 - 1 10 - 2  5 - 3  2 # 6 - 4  3 - 5 27 - 6 44 - 7 55 - 8  1 - 9  4 - 4  3 # 2 - 2  5 - 9  4 - 8  1 - 5  2 - 10 5 

Each line preceded by # denotes the start of a new inventory. Each line preceded by – denotes an item. The program creates a new inventory each time a # is encountered.

When a – is encountered, a stack of items, ItemStack, is created. The ItemStack is placed in the Inventory based on the following rules:

1. If the Inventory is empty, store the ItemStack, and return true.
2. If the Inventory is not empty, examine the Inventory.
   • If a matching ItemStack is found, merge the two ItemStacks and return true.
   • If no matching ItemStack is found, store the new ItemStack and return true.
3. If the Inventory is full, return false.

Through the magic of abstraction, this is not one function, but four (4) functions in total. Yes, it does seem unnecessary at first. However, each function does one thing and only one thing. This is an exercise in understanding the thought process behind abstraction, interfaces, and the S/O in S.O.L.I.D (with some C++ code) in a multi-ADT program.

Most of your time will be spent on understanding the abstractions (and interfaces) as opposed to spamming cobblestone blocks… I mean C++ code.

3.2 Output

The output consists of three reports written to standard output, one after the other.

1. A report listing items that were stored or discarded.
2. A report listing all valid items.
3. Finally, a detailed report is printed. listing data for each inventory:
   • Maximum Capacity–i.e., total slots.
   • Utilized Capacity–i.e., occupied slots
   • Listing of all items.

If the program is run with the provided input files, the following output should be generated…

Example 3: Sample OutputProcessing Log:  Stored (10) HP Potion  Stored ( 5) MP Potion  Stored ( 2) Bow Tie  Stored ( 3) Dirt  Stored (27) Iron Ore  Stored (44) Diamond Ore  Stored (55) Iron Ingot  Stored ( 1) Diamond  Stored ( 4) Diamond Block  Stored ( 3) Dirt  Stored ( 5) MP Potion  Stored ( 4) Diamond Block  Discarded ( 1) Diamond  Discarded ( 2) Iron Ore  Item List:    0 Air    1 HP Potion    2 MP Potion    3 Bow Tie    4 Dirt    5 Iron Ore    6 Diamond Ore    7 Iron Ingot    8 Diamond    9 Diamond Block  Storage Summary:  -Used 3 of 5 slots   (10) HP Potion   ( 5) MP Potion   ( 2) Bow Tie   -Used 6 of 6 slots   ( 6) Dirt   (27) Iron Ore   (44) Diamond Ore   (55) Iron Ingot   ( 1) Diamond   ( 4) Diamond Block   -Used 2 of 2 slots   ( 5) MP Potion   ( 4) Diamond Block  

3.3 Running the Program

The easiest way to see generate the expected output is to run the sample executable solution I have provided. These two files are named as command-line parameters when the program is executed.

For example, if the sample data above is kept in files itemList-01.txt and inventoryList-01.txt, then to run this program, do:

./storage itemList-01.txt inventoryList-01.txt

(On a Windows system, you would omit the “./”. If you are running from Code::Blocks or a similar development environment, you may need to review how to supply command-line parameters to a running program.)

4 Your Tasks

One of the most important skills in our craft is interpreting error messages. Remember the ones you receive when you attempt to compile and run the unmodified code.

The key abstractions employed in this program are Item, ItemStack, and Inventory. Complete ADT implementations have been provided for Item and Inventory.

A partial implementation has been provided for the ItemStack. Your task is to finish the update ItemStack ADT.

This assignment is smaller than the previous two (in terms of code and number of new concepts). Most of your time will be spent reviewing the basics of pointers. Spend the time reviewing. Practice with pointers. You will need to use pointers (in one form or another) for the reminder of the semester.

You must implement the:

1. Copy Constructor
2. Destructor
3. Assignment Operator
   • Note this is already provided and complete. Refer to our discussions of the copy-and-swap method.
   • Once you have completed the Copy Constructor, Destructor, and swap you are done with the Big-3.
4. Logical Equivalence (i.e., operator==).
5. Less-Than (i.e., operator<).
6. swap

Refer to the comments in each function for additional detail.

Employ your Head-to-Head Testing Skills from CS 250.

4.1 Three Main Functions?

As you look through the provided code, you will find three main functions: one in storage.cpp (as expected), one in TestInventory.cpp, and one in TestItemStack.cpp. If you are creating a project in your IDE do not include both in your project settings. You will need to either create multiple targets in your project settings, or rely on the makefile.

You should probably run the tests on a Linux machine… You can compile the main program (storage) and test drivers (testInventory and testItemStack) with

make

Take note of the semicolon (;) after testInventory. This is a standard Linux trick to run two commands back-to-back.

You can then run storage as described above. You can run the Inventory and ItemStack test drivers with:

./testInventory; ./testItemStack 

If you implemented everything correctly you will see:

Inventory:
 PASSED -> testDefaultConstructor
 PASSED -> testConstructorSizeN
 PASSED -> testAddItemStackNoCheck
 PASSED -> testAddItemWithDuplicateItems
 PASSED -> testAddItemAfterFull
 PASSED -> testCopyConstructorForEmpty
 PASSED -> testCopyConstructor
 PASSED -> testAssignmentOperator
 PASSED -> testDisplay
ItemStack:
 PASSED -> testDefaultConstructor
 PASSED -> testSecondConstructor
 PASSED -> testCopyConstructor
 PASSED -> testAssignment
 PASSED -> testAddItems
 PASSED -> testAddItemsFrom
 PASSED -> testLogicalEquivalence
 PASSED -> testLessThan
 PASSED -> testDisplay
 PASSED -> testSwap

If you see FAILED you must revisit revisit the corresponding function(s). There is a mistake somewhere in your code. Where should you look? Pay close attention to the line immediately before FAILED… use that as a starting point.

Remember to ask questions if you get stuck.

4.1.1 Segmentation Faults & Getting Started

Since ItemStack’s item data member is a pointer

Item* item;

segmentation faults are a consideration. If you download, compile and run the tests, without implementing anything, you will receive test output similar to:

Inventory:
 PASSED -> testDefaultConstructor
 PASSED -> testConstructorSizeN
[1]    21524 segmentation fault (core dumped)  ./testInventory
ItemStack:
[1]    21526 segmentation fault (core dumped)  ./testItemStack

Here is a free hint. Go to the Copy Constructor and add

   this->item = src.item->clone();

This line will create a deep copy of src.item. Once you have made that one-line addition, recompile everything and run

./testInventory; ./testItemStack

again. You should see:

Inventory:
 PASSED -> testDefaultConstructor
 PASSED -> testConstructorSizeN
FAILURE: testAddItemStackNoCheck:89 -> (*(it++) == stacksToAdd[0])
 FAILED -> testAddItemStackNoCheck
FAILURE: testAddItemWithDuplicateItems:126 -> (*(it++) == stacksToAdd[0])
 FAILED -> testAddItemWithDuplicateItems
FAILURE: testAddItemAfterFull:172 -> (*(it++) == stacksToAdd[0])
 FAILED -> testAddItemAfterFull
 PASSED -> testCopyConstructorForEmpty
FAILURE: testCopyConstructor:268 -> (aCopy == source)
 FAILED -> testCopyConstructor
FAILURE: testAssignmentOperator:305 -> (aCopy == source)
 FAILED -> testAssignmentOperator
FAILURE: testDisplay:204 -> (bagString.find(stacksAsStrings[0]) != std::string::npos)
 FAILED -> testDisplay
ItemStack:
 PASSED -> testDefaultConstructor
 PASSED -> testSecondConstructor
FAILURE: testCopyConstructor:70 -> (aCopy.size() == 9002)
 FAILED -> testCopyConstructor
FAILURE: testAssignment:91 -> (aCopy.size() == 9002)
 FAILED -> testAssignment
 PASSED -> testAddItems
 PASSED -> testAddItemsFrom
FAILURE: testLogicalEquivalence:142 -> (stack1 == stack2)
 FAILED -> testLogicalEquivalence
FAILURE: testLessThan:164 -> (stack3 < stack1)
 FAILED -> testLessThan
 PASSED -> testDisplay
FAILURE: testSwap:198 -> (stack1.getItem().getName() == "Ice")
 FAILED -> testSwap

There is nothing wrong with Inventory. Inventory is dependent on ItemStack. Until ItemStack is complete you will see failures in testInventory.