ICS212: Assignments

Assignment 09

Details

A09.pdf (Due: 8am, 04 May)

Clarifications and Suggestions

As discussed in 10B lecture, inline functions and template code can be placed in header files. You may want to forgo the .cpp file for your FruitPlant and just put the function definitions in the header file.
As long as you don't use pointers, you should not need to explicitly delete any Fruit or FruitPlants.
For those using Visual Studio: Remember that the destructors won't get called on your automatic variables in main until the program ends. However, if you are using the cin.get() (or, if you must, getchar()) trick to hold the output window open, main has not ended yet. To force your destructors to run where you can see them, you can wrap the contents of main before the call to cin.get() in an anonymous {block}. This way, your destructors will get called when execution leaves that block but before reaching cin.get(). See the lecture slides for examples of this.

Grading (10 points)

Submitted code compiles. (Required for additional points.)
Three Fruit classes, each with constructor, destructor, and print function, each of which print a line to the screen (4.5 points)
A FruitPlant template class, which contains an array (not vector) of a random size.
FruitPlant's internal array is allocated with new[] (not malloc) and deleted in destructor.
FruitPlant's print function calls print on each of the contained fruit.
main function that creates 3 FruitPlants (one for each fruit).
Code adheres to course coding standards (0.5 point).

FAQs

What is the output supposed to look like for this?

The assignment asks you to create 3 fruit plants. Each time you do this, the fruit plant constructor will create a random number of new fruits, and those new fruits will each print a line from their constructors as they are created.

Once you're created the the fruit plants, you can call print on each of them. Each plant will then call print on all of their contained fruit.

Finally, you'll see everything getting destroyed.

Adding some print statement to the fruit plant constructor, print function, and destructor is optional. I did that, as well as printing a blank line at the end of each. So, with no printing done in main, my output looks like this:

new FruitPlant (size: 4)
new Apple(112 grams)
new Apple(147 grams)
new Apple(167 grams)
new Apple(102 grams)

new FruitPlant (size: 5)
new Banana(63 grams)
new Banana(103 grams)
new Banana(131 grams)
new Banana(63 grams)
new Banana(61 grams)

new FruitPlant (size: 3)
new Cherry(4 grams)
new Cherry(5 grams)
new Cherry(4 grams)

printing FruitPlant (size: 4)
an Apple(112 grams)
an Apple(147 grams)
an Apple(167 grams)
an Apple(102 grams)

printing FruitPlant (size: 5)
a Banana(63 grams)
a Banana(103 grams)
a Banana(131 grams)
a Banana(63 grams)
a Banana(61 grams)

printing FruitPlant (size: 3)
a Cherry(4 grams)
a Cherry(5 grams)
a Cherry(4 grams)

destroying FruitPlant (size: 3)
destroy Cherry(4 grams)
destroy Cherry(5 grams)
destroy Cherry(4 grams)

destroying FruitPlant (size: 5)
destroy Banana(61 grams)
destroy Banana(63 grams)
destroy Banana(131 grams)
destroy Banana(103 grams)
destroy Banana(63 grams)

destroying FruitPlant (size: 4)
destroy Apple(102 grams)
destroy Apple(167 grams)
destroy Apple(147 grams)
destroy Apple(112 grams)

If Fruitplant is templated, doesn't that mean we should be able to make an instance of it with any type, even ints or strings?

Theoretically, yes. However, if you try it, you'll find that you get a compile error because an int or string doesn't have a print() function, which your Fruitplant should be calling on each of its contents. C++ templates are sort of an example of compile-time duck typing in this way: they don't require you give it a certain type, but the given type must still have all the behaviors required by the template.

For this assignment, this is fine. You can assume that whatever goes into your Fruitplant will have the necessary print() behaviors of a fruit.

However, for the curious, there is a way to make your template more robust: The standard way to print in C++ is to use the << operator. You can override this behavior for each of your fruits. Most C++ classes do this. It's a lot like overriding toString() in Java.

The first step is to change your fruit's print() method to take the stream to print to as a parameter:

void print(std::ostream& out = std::cout);

In the definition of this new print function, write to out rather than to std::cout. Note that I'm using a default argument here. This way, you can still simply call print() to print to the screen, but you could also pass a file stream instead to print to a file if you wanted to.

Then declare the following function, renaming Apple to your particular fruit:

std::ostream& operator<<(std::ostream& out, const Apple& f);

The definition of this function:

std::ostream& operator<<(std::ostream& out, const Apple& f) {
  f.print(out);
  return out;
}

Finally, use cout << fruits[i]; instead of fruits[i].print(); in your template class. Now your template class will work with anything that can be printed using the << operator, and your fruits will also work with the << operation in other situations.

Again, this is all optional.

Assignment 08

Details

A08.pdf (Due: 8am, 27 Apr)

Clarifications and Suggestions

If you want, you may print the leaves at the top of the screen and the root at the bottom. The user then shoots the balls up into the tree.
When translating the given C printing code to C++, you can make any modifications you want. For example you don't need to retain the Tree typedef. You can just change this back to char so that you'll have char* instead of Tree*).
For user input, I recommend you use single digits as leaf node identifiers. For larger trees, you can then use 'a' - 'z' for 10 to 36 values.

Grading (10 points)

Submitted code compiles. (Required for additional points.)
Prints a complete binary tree with leaves labeled (0.5 point)
Generates a random colored ball at root (0.5 point)
Asks user which leaf to direct new ball towards
Correctly moves ball down through the tree towards the user-selected leaf, stopping early if the path is blocked (2.5 points)
Game ends in a win when user forms a path of a single color from root to at least one leaf (1.5 points) or in a loss when they cannot direct a ball away from the root (0.5 point).
Code follows C++ conventions (no #define constants, printf, puts, stdio.h, malloc, etc)
Game still works correctly when changing a single size (# of levels) constant to any value between 2 and 6 (0.5 point).
Submission includes requested output transcripts (0.5 point).
Code adheres to course coding standards (0.5 point).

Assignment 07

Details

A07.pdf (Due: 8am, 13 Apr)

Grading (10 points)

Submitted code compiles. (Required for additional points.)
Prompts user for input filename and tabstop to use.
Reads in text from the given input file (without changing the file). (2 points)
Replaces each tab ('\t') with the correct number of spaces for the given tabstop (2 points)
Writes out the changes to a file with the same name as the input file plus an .untab extension. (2 points)
Does not crash or lock up, regardless of input or file states.
Code adheres to course coding standards.
If given 1 or 2 command line arguments, allows user to skip prompts for input. (+1 point EC)

Assignment 06

Details

A06.pdf (Due: 8am, 23 Mar)

Grading (10 points)

Submitted code compiles. (Required for additional points.)
Creates a shuffled deck of 52 unique cards.
Models a hand of cards, with the hand size specified at runtime.
Hands are loaded with cards drawn from the shuffled deck.
Four card comparison functions, as requested (1/2 point each = 2 points)
Uses a sort function that you wrote that sorts cards using a given comparison function
Prints the requested output: 4 pairs of hands sorted in different ways (2 points)
Code adheres to course coding standards.

Assignment 05

Details

A05.pdf (Due: 8am, 14 Mar)

Grading (10 points)

Submitted code compiles. (Required for additional points.)
TorpedoTube: a dynamically-allocated struct with constructor and destructor functions.
Torpedo: a struct with constructor and destructor functions.
Ship: a dynamically-allocated struct with constructor and destructor functions; includes a pointer to a valid TorpedoTube.
Coordinate: A struct representing a point in space. May contain an asteroid, ships, and torpedoes. Also: a 2D array of these coordinates.
Presentation of space/gameboard (2 points).
(I should be able to easily tell that your board is the correct size, where the ships are in relation to each other, how the ships move each turn, when one of the ships fires a torpedo, and where the torpedos are each turn. The easiest and clearest way to do this is to print a 2D map each turn (whatever you define a "turn" to be). If I can't easily perceive these details, you may not get points for the following.)
Ships move, scan, and shoot torpedoes when appropriate.
Torpedoes move, blowing up any enemy ships that they encounter.
Code adheres to course coding standards.

Names of typedefs, structs, functions, and modules/files are up to you.

Clarifications and Suggestions

You may extend the struct definitions if you find a need to do so. For example, you might want to record the (x,y) or (row, col) location of either a Coordinate or an object (spaceship or torpedo tube).
You can decide how to split your code up into files. (You should have at least 2, though!) See the FAQs for more.
There are a number of issues that you will encounter that have not been specified. You should make your best design decision and document what you did in the appropriate module header or function documentation. Here are just some of the issues that you will likely need to consider:
- How best to print the board to see where everything at once? What are the max number of items that will need to be displayed in at a given coordinate at one time? How best to represent this?
- What's the simplest code that will let you "look" in a straight line across the 2D array in any direction?
- If a ship either fires OR moves, then won't two ships that see each other just sit still and blast at each other? If might be better if a ship moves every turn, even after firing.
- A ship should only fire up to 1 torpedo a turn. However, it might speed the game along if you check for enemies both before and after the ship moves.
- How do you equitably determine which ship gets to shoot (and/or move) first? It seems that each ship should have an equal chance of winning, but if you always let ship1 move before ship2, that won't happen.
- What about targeting a ship in the same square as an asteroid? Can the shooting ship see the targeting ship? Yes, no, or maybe (50% chance)? (Remember that torpedoes normally fly right past asteroids.) Does the asteroid obstruct a ship's own view of the board at all?
- If two ships are in the same square, and one fires at the other, is it always the other ship that gets blown up? Should perhaps both ships die? What if there's also an asteroid at that coordinate?
- If a ship can "wrap around" the edges of the map, it is possible for a ship to shoot a torpedo east, warp around to the west, and get killed by its own torpedo. Is this okay with you? If not, how will you prevent it? (If your ships can't warp around the edge--which solves this problem--how will you keep them on the field?)

FAQs

How many .h header files should I create?

It's up to you. What do you think would be clearer in the long run? You've got a range of options:

Create one .h and one .c for each struct and associated functions (constructor, destructor, etc.) This is sort of mirrors Java: each class should be in its own file.
Advantage: Each component is very easy to find later; each file is small and easy to navigate; easier to reuse any single component in another project later.
Disadvantage: Lots of files to create, document, and compile together.
Create some smaller set of .h and .c files by grouping related structs together. For example, you may decide that a torpedo tube is intimately related to a ship, so those two things should go together; and a coordinate in space might go in the same file as the game board code; but the torpedo definition should go by itself in a third file.
Advantage: Smaller number of files, but code is still logically grouped.
Disadvantage: What seems like a logical grouping to you now may not be clear to someone else or to yourself later. You may end up hunting through multiple different files later trying to find the torpedo tube definition--why is it with ship and not in torpedo.c?
Create one .h header for the whole project, but still separate out the .c files one per "object".
Create one .h and .c file for all of the game simulations stuff, and then just have a small main.c for main.
Advantage: Fewest number of files.
Disadvantage: As the project continues, it will get harder to quickly find code that you need to revisit; can't reuse portions separately later.

So weigh your options and see what seems like the best choice. (See also this FAQ, and the four links from there.)

I'm getting compiler errors when I #include one header file from another.

Then don't do that. :) If you do, it's very easy to have a header included more than once, so that some struct gets defined twice when you compile.

Many people argue you should never include one header file from another. #includes should only go in a .c file. Remember that all the code in a .h file will be copied into a .c file by the preprocessor before the .c file gets compiled. If you order your #includes in the .c file correctly, this will work out fine, even if code in one .h requires a definition from another .h.

Other people use a neat preprocessor trick called an include guard. These 3 lines go in the .h file around its contents and prevents it from being copied twice into the same .c file.

See here for more info on all of this. (I'll talk more about this in lab.)

Assignment 04

Details

A04.pdf (Due: 8am, 29 Feb)

Grading (10 points)

Submitted code compiles. [*]
Claw machine modelled using a struct containing at 3D array.
A constructor function that returns a new machine (preferably by pointer).
A refill function that inserts random toys in random locations but respects the laws of gravity (no toys with a space in the stack beneath them).
A destructor function
A print function that shows the claw-accessible toys (top toy of each stack). (Should also be possible to print the complete machine contents, with either same print function as above or a different function.) [*]
Asks the user which stack or top-level toy to attempt to grab.
Removes the grabbed item with some random chance of missing the toy or dropping it into a nearby column instead.
Program includes an option to use A03's gumball machines. Claw machine and gumball machine should be in different modules, except for any shared functions you might have, which should also be in their own modules.
Code adheres to course coding standards.

Each item listed here is worth 1 point. However, failures on some items (particularly those marked with a [*]) may cost you more points on other dependent items. For example, you will likely also lose points on gameplay if you have no print function.

Clarifications and Suggestions

The random drop chance is up to you, but try to make it make sense. Maybe the drop rate is affected by what is around the target toy in terms of other toys at the same or higher level. Or maybe each toy has its own drop chance based on its shape. You may want to split the "failed to grab" behavior from the "dropped later" behavior. (Note that these are the sort of details you'll want to document somewhere in your code.)

Assignment 03

Details

A03.pdf (Due: 8am, 22 Feb)

Grading (10 points)

Submitted code compiles (1 point, required for additional points)
constructor function (3 points, 1 each)
- randomly chooses different colors for the new gumbal machine
- mallocs the required space and initializes all fields
- prints (or causes to be printed) the state of the new gumball machine
OperateGumballMachine (2 points, 1 each)
- Now constructs 3 gumball machines and asks user to select which one to use
- takes money and delivers gumball (as per A02)
DeliverGumball (2 points, 1 each)
- Takes a gumball machine pointer as parameter
- Uses rand (which is seeded once, elswhere) to pick and correctly deliver a gumball (as per A02)
RefillGumballMachine (0.5 point)
- Takes a gumball machine pointer as parameter
A01 functions (0.5 point)
- Still exist and work as originally specified (changes likely required due to changes in underlying struct)
Coding standards (1 point)

Clarifications and Suggestions

Very little will now be in main besides the call to OperateGumballMachine(). (You still need to seed rand somewhere.)
Three gumball machines? If it's three today, there's a good chance it could be a different number tomorrow. To keep your code flexible, this would be a good chance to practice arrays.
You'll have to ask the user to select a machine first. To keep it simple, I recommend asking for an int (such as 1 to 3). You can either use getchar() for this (though that will return their choice as a digit/character) or else try scanf().
Remember that you still have your PrintGumBallMachineStatus function lying around. If you dust this off a bit, it can still be useful!
Remember not to repeat code. For example, are you reloading/setting the colors or number of the gumball's in a machine in more than once place? If so, don't do that. Call one function from another to reuse code. Same goes for printing.
Try not to repeat the same colors in your color selection. For example, it's rather lame to have a gumball machine with 3 colors containing yellow, green, and green.

Assignment 02

Details

A02.pdf (Due: 8am, 15 Feb)

Grading (10 points)

Submitted code compiles (1 point, required for additional points)
global GumBallMachineType variable, properly initialized (preferably in OperateGumballMachine) (1 point)
OperateGumballMachine (3 points, 1 each)
- Asks user to enter input until 25+ cents or chooses to quit
- Input is n, d, q, or x; error message on bad input
- Returns excess change
DeliverGumball (3 points, 1 each)
- Uses rand (which is seeded once, elswhere) to pick a gumball
- Decrements appropriately and prints the delivered gumball
- Won't crash or misbehave if machine runs out of gumballs of one or more colors.
RefillGumballMachine (1 point)
Coding standards (1 point)

Clarifications and Suggestions

When extending A01, please remove the old contents of main so that your program prints only A02 content. (You will still be extending A01 because your GumBallMachine.c file will still contain the two functions you wrote in A01. Although you won't use them in your finished A02, the functions may come in handy when testing your A02 program.)
The parameters and return type for OperateGumballMachine() are not explictly stated. I recommend that it take no parameters (but you can vary this if you really want to).
OperateGumballMachine() only needs to sell the user one gumball and then end. (So 'x' is just so they can quit early without putting in enough to buy a gumball.) However, your functions should still work correctly if main is later changed to keep using the gumball machine until it's empty.
Although you have to make a global gumball machine variable, you could at least "hide" it in GumBallMachine.c by making the variable static. But if you make it static, how can you initialize it from main? (Hint: Use a function... preferably one of the functions that you already have to write anyway...)
I don't mind if you don't use a switch in DeliverGumBall() if a different control structure makes more sense for your algorithm--for example, if you're picking a random gumball across all colors rather than picking a random color.
When your gumball machine is empty, what does it do with the coins that the user just put in?

Assignment 01

Details

A01.pdf (Due: 8am, 08 Feb)

Grading (10 points)

Design document: 3 levels of decomposition (1 point); clear, logical, and comprehensive (2 point)
Submitted code compiles (1 point, required for additional points)
GumBallMachine.h: contains requested struct, function declarations (1 point)
GumBallMachine.c: 2 requested functions (3 points)
main.c: Working main function (1 point)
Coding standards: formatting, documentation blocks, meaningful names, etc. (1 point)

Tips, Hints, and FAQs

How to create a ZIP file on uhunix

This is for those of you who work on uhunix or who don't have a zip program on their home machine. Here is an example of how to create a zip file:

zip usernameA01.zip GumBallMachine.h GumBallMachine.c main.c PartyDesign.jpg

zip is the name of the program. The first argument is the name of the zip file you want to create or add to; the other arguments are a list of files to add to the zip. All the files you are trying to zip need to be in your current uhunix working directory. (That is, type ls first to make sure they are all there.)

You don't have to create your zip file on uhunix if you can create one on your home machine. Note that Tamarin does require a .ZIP file though--no RARs, GZs, TARs, etc.

I'm trying to compile on uhunix using gcc, but I'm getting a linker error.

You can recognize a linker error because it looks something like this:

  Undefined                       first referenced
   symbol                             in file
  main                       /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/crt1.o
  ld: fatal: Symbol referencing errors. No output written to a.out
  collect2: ld returned 1 exit status

You can recognize a linker error because 1) it's complaining about a .o file and 2) it doesn't give you a code line number.

Here, its complaining that the symbol main is not defined. That means it can't find the definition of your main function. (Your error message might be about a different function name.)

Generally, the reason the linker can't find a function definition is because you forgot to include the appropriate .c file when you compiled. You would get the error above if you forgot to mention your main.c file when compiling. Remember that you have to specify all the .c files you are compiling to produce the single executable. (You don't need to mention any .h files when compiling because those should already be #included from the .c files.)

So your compile command should look something like this:

  gcc main.c GumBallMachine.c

Or, if you want to specify the name of the output file (rather than the a.out default):

  gcc -o gum.exe  main.c GumBallMachine.c