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:
- If the Inventory is empty, store the ItemStack, and
return true.
- 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.
- 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.
- A report listing items that were stored or discarded.
- A report listing all valid items.
- 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:
- Copy Constructor
- Destructor
- 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.
- Logical Equivalence (i.e.,
operator==).
- Less-Than (i.e.,
operator<).
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.
