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.txt
0 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 Output
Processing 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.
Presentation by Andreas Schleicher Tackling the School Absenteeism Crisis 30 ...
The program reads data from two files, itemsList-0x.txt and .docx
1. 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.txt
0 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
2. 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
.
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.
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.
4. 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 Output
Processing 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:
5. ./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.
6. 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.
7. 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-
8. 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
9. 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.
10. 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
11. 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
13. 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
.