Simulating craps games

There are a number of things you want to ask yourself. The first is, "in the real world, do these requirements make sense?". In this case, the answer is an emphatic "No".

other than main(), use only one function -- dice_roll(). all calculations are inline.

This is a terrible requirement, and whoever wrote this assignment needs to be whacked with the common sense bat. It is teaching really bad practice right from the get go. It is never desirable to have a giant main function.

The second question to ask is, "Am I using C++ or am I using C with std::cout instead of printf?". Likely this is not your fault - any teacher who decides to make a student bundle all their code into the main function is doing a dubious job at best.

Let's tackle both of these. If you want to learn, I'm going to say throw away some of these requirements. The real requirement of the program is:

simulate 5,500 craps games and print out the results.

Here, the requirement itself leads to a relatively easy breakup of the program structure. We'll keep it simple, and say we want 4 functions in total:

• A function to simulate dice rolls - roll_dice() (which already exists)
• A function to simulate the games and store the results in some kind of data structure - let's call it run_simulation. This will take as a parameter the number of games to play.
• A function to calculate and print statistics based on games. This will take the data structure from the previous function.
• main, which will co-ordinate the above functions.

One of the nice things about C++ is the rich set of data structures available in the standard library. These generally perform memory management for you. It isn't listed in the requirements, but from your code, you want something that will store the number of wins/losses for a given number of rolls in sorted order.

Again, I'm not sure how much experience you have with data structures, however, the standard library has a good fit for this requirement: a std::map. A map stores key/value pairs in an efficient way, so that key lookup is fast.

Ok, so we'll start as before: defining our enum and something to store our game data - call it (unimaginatively) game_data:

#include <iostream> #include <iomanip> #include <cstdlib> #include <ctime> #include <map> // <--- Additional include so we can use `std::map` enum game_outcome { CONTINUE, WIN, LOSE }; struct game_data { int win; int loss; game_data() : win(0), loss(0) { } game_data(int w, int l) : win(w), loss(l) { } }; 

Above, we've defined some constructors for our game_data type. Now, we'll define our map type:

typedef std::map<int, game_data> result_list; 

This says the type result_list is a map from integers to keys. Here, the int key will be the number of rolls. A nice thing about map is that it stores things in sorted order - so our sorting comes for free.

int roll_dice() { return (rand() % 6) + (rand() % 6) + 2; } result_list run_simulation(int num_games) { result_list results; static game_outcome outcome[] = {CONTINUE, CONTINUE, LOSE, LOSE, CONTINUE, CONTINUE, CONTINUE, WIN, CONTINUE, CONTINUE, CONTINUE, WIN, LOSE}; for(int i = 0; i < num_games; ++i) { int roll = 1; int sum = roll_dice(); game_outcome out = outcome[sum]; while (out == CONTINUE) { int point = sum; sum = roll_dice(); ++roll; if(sum == point) { out = WIN; } else if(sum == 7) { out = LOSE; } } game_data& d = results[roll]; (out == WIN) ? ++d.win : ++d.loss; } return results; } 

Firstly, we've replaced the switch statement with an array lookup, which makes the code a bit more concise and arguably less error prone (it's easy to forget break at the end of switch statements). The while loop is mostly unchanged, other than some reordering. What has mostly changed is the replacement of a lot of code with the two lines:

game_data& d = results[roll]; (out == WIN) ? ++d.win : ++d.loss; 

Lookup in a map can be done using [] syntax (much like arrays). If the key doesn't exist in this case, it is inserted. Thus, we lookup the data by rolls. For example, if rolls was 3, this would find the game_data class that sits in the map with the previous results for 3. Then, we simply increment the correct win or loss based on the outcome.

Now, we need to write a function that will take what is in the map and print out some information from what is in it: let's call it result_statistics.

void result_statistics(const result_list& results, int num_games) { int wins = 0; int losses = 0; double avg_length = 0; for(auto const & p : results) { std::cout << std::setw(4) << p.second.win << " games won and " << std::setw(3) << p.second.loss << " games lost on roll " << p.first << "\n"; wins += p.second.win; losses += p.second.loss; avg_length += (p.second.win + p.second.loss) * p.first; } int total_games = wins + losses; std::cout << std::setiosflags(std::ios::fixed | std::ios::showpoint) << "\nodds of winning are " << wins << " / " << total_games << " = " << std::setprecision(2) << 100.0 * wins / total_games << "%." << "\n"; std::cout << "avg num rolls/game is " << std::setprecision(2) << avg_length / num_games << " rolls." << "\n"; } 

The print code is mostly the same.

Finally, our new main function:

int main() { const int kGames = 5500; srand(time(nullptr)); result_list r = run_simulation(kGames); result_statistics(r, kGames); } 

Note how we can now follow (at least at a high level) the flow of the code. We define the total number of games, seed our random generator, run the simulations, and calculate the statistics from those runs. Breaking things up in this way makes things much easier to reason about and follow in the code.

Even if some (or most) of this doesn't make sense to you yet, I think the main things to take away from this are that if you get told to shove everything into a main function, do it for your assignment if that is what is required. Afterwards, go back and split it up into smaller functions, each one having a specific, well defined, singular purpose. Compare the code from the two. Which one is easier to understand? Investigate the standard library, teach yourself as much as you can about it (basic containers are probably the most important thing for now). Finally, look at the assignment specs. Do they all make sense? Do they lead to more or less readable code? What would you do differently if you had free-reign?