CSCI-541: Programming Skills C++
Lab 2 - Destler Doubloons

Part One Due: Wednesday April 3 @ 11:59pm
Part Two Due: Wednesday April 10 @ 11:59pm


Introduction

The Finance and Administration department in Building 1 is ready to unveil their new crypto currency coin. Initially they were going to go with the name Destler Dollar.

Because of fear of intervention by the US Government, they eventually settled on Destler Doubloon (thanks to Megan Detwiler's Paw Prints petition). It is your job to make sure the doubloon is secure, cannot be illegally duplicated, and can be quickly transferred between the central vault and student's wallets. Meanwhile, President Destler has prepared four new melodies that when played on his banjo affect the currency.

Goals

This lab covers the following C++ concepts:

General Requirements


Part 1: Move Semantics

Documentation

The main documentation is here.


Implementation

Provided Source Code

The starter code is in a zip file here.

Here is a quick description of the provided src directory.

If you are using CLion, you should maintain the src directory with all the files inside, except for CMakeLists.txt which should be at the top level. Right click on the src directory and select Mark Directory As -> Project Sources and Headers.

Implementation Details

Destler Doubloons

Read over the documentation for this class and implement it accordingly. Pay attention to how the debugging works with this class as it will be used to verify you are implementing things correctly.

Building One

Read over the documentation for this class and implement it accordingly. You must use the vault as efficiently as possible. For example, when adding, removing or looking up an entry, it must be done in O(1) time.

The Loop

The main loop is partially implemented for you. The quit and help commands are already implemented for you. You must use the map of commands with lambda expressions in order to execute the commands.

The wallet is implemented as a double ended queue. When a doubloon is successfully withdrawn from the vault, it is put at the end of the queue. When a doubloon is deposited back, the doubloon should come from the front of the queue.

President Destler can play four songs on his banjo:

Here are the full list of commands that the main loop must support:

    debug: toggle debugging of the doubloons
    deposit: deposit doubloon into building 1 vault (from front of wallet)
    doubloon id: list a doubloon in the building 1 vault by id
    fedora #: fedoras song: decrease value of all coins in vault by #
    gun id: prelude to gunbrella: destroy a coin in vault by id
    help: this help message
    quit: end program
    ritchie #: ritchie's lullaby: increase value of all coins in vault by #
    sos #: song of storms: mint # coins
    vault: display all doubloons in building 1 vault
    wallet: display all doubloons in wallet
    withdraw id: withdraw a doubloon from building 1 vault (into back of wallet)

Errors

Your program should be able to handle the following errors by producing an output message.

You can assume for commands that have an extra argument, that the argument is present and will be a valid type.

Sample Runs

Here are some sample runs for you to help verify things. In UNIX you can pass the input file as standard input and then compare the output using diff:

    $ ./dd_main input.txt > output.txt
    $ diff output.txt output1.txt

These files are provided to you in the zip for for the starter code in the output directory.

Valgrind

You should use valgrind to verify your program is properly managing memory. It is ok if bytes are still reachable in the heap when the program exits - this is expected. You should have no memory errors and your leak summary should look like this:

    $ valgrind --leak-check=full ./dd_main
    ...
    ==31158== LEAK SUMMARY:
    ==31158==    definitely lost: 0 bytes in 0 blocks
    ==31158==    indirectly lost: 0 bytes in 0 blocks
    ==31158==      possibly lost: 0 bytes in 0 blocks
    ...

Part One Submission

Submit your source code and Git log to try using the command:

    try grd-541cpp lab2-1 building_one.cpp destler_doubloon.cpp the_loop.cpp log.txt

You can verify the contents of your submission by doing:

    try -q grd-541cpp lab2-1

The try system only accepts code with exact file names that compiles, and only saves the last successful submission. The target closes at midnight on the due date.


Part Two: Smart Pointers

Now you will change your implementation so that it removes the need for move semantics in DestlerDoubloon. You will be storing the doubloons in a smart pointer, unique_ptr, in both BuildingOne's vault, and TheLoop's wallet. All doubloons will now be dynamically generated on the heap and automatically free'd when the simulation ends and the vault destructs.

Documentation

The main documentation is here.

Starter Code

No starter code is provided. You should make a complete copy of your code from the first activity and put it into a separate directory, e.g src2. You need to modify the following files based on the documentation changes:

Implementation Details

Change your implementation of BuildingOne, DestlerDoubloon and TheLoop so that it conforms to the new smart pointer design. When you run with debugging enabled, you should notice that only the DestlerDoubloon's constructor and destructor is called.

    $ debug
    $ sos 4
    DD: 0x28E837C5CB41DC3E, value: 1 being created!
    DD: 0xFDFD3A7C3E40F98B, value: 1 being created!
    DD: 0x0A213217F032E8B9, value: 1 being created!
    DD: 0x98F56903CEE3FCEE, value: 1 being created!
    $ withdraw 0xFDFD3A7C3E40F98B
    $ wallet
    DD: 0xFDFD3A7C3E40F98B, value: 1
    $ gun 0x28E837C5CB41DC3E
    DD: 0x28E837C5CB41DC3E, value: 1 being destroyed!
    $ ritchie 5
    $ deposit
    $ fedora 1
    $ sos 1
    DD: 0x8AD330133B0725AC, value: 1 being created!
    $ vault
    DD: 0x8AD330133B0725AC, value: 1
    DD: 0x98F56903CEE3FCEE, value: 5
    DD: 0xFDFD3A7C3E40F98B, value: 0
    DD: 0x0A213217F032E8B9, value: 5
    $ quit
    doubloons in vault: 4
    total worth: 11
    DD: 0x8AD330133B0725AC, value: 1 being destroyed!
    DD: 0x98F56903CEE3FCEE, value: 5 being destroyed!
    DD: 0xFDFD3A7C3E40F98B, value: 0 being destroyed!
    DD: 0x0A213217F032E8B9, value: 5 being destroyed!

Before you submit make sure you run the program through valgrind and there are no memory leaks.

Part Two Submission

Submit your source code and Git log to try using the command:

    try grd-541cpp lab2-2 building_one.cpp the_loop.cpp log.txt

Grading

  • Functionality: 80%
  • Error Handling: 5%
  • Memory Management: 10%
  • Code Style & Version Control: 5%

  • updated:
    Fri March 22 2019