Which container to do what I need?

[raptor88]

The issue is that GetBets and PayBets are also global functions. Why go that route when you can create an entire class that encapsulates this whole thing? Then there is no need for global variables, global functions, or global definitions.
... snip ...

If you want another example, look at the "map" class you're using now. Do you see globals being used in the map class denoting the number of items in the map, the internal tree-like structure used in the map, etc.? You don't -- so how does std::map accomplish keeping track of the map internals without using global variables? The entire map internals are encapsulated in a class -- something your game does not do.
So what happens when you want 6 players, 8 players, etc? You now have to go and change your program, recompile, relink to get it to work for 6 players, and then create another program to have 8 players, etc. You can see how that won't work too well.

First, you should have a struct defining a single player. The road you're going down now seems to suggest you'll have information for a single player strewn about in different and disjoint structs, functions, variables, etc. in your code. Instead you should be consolidating all of this information into a single entity that describes a single player. You now create a vector of this "player information"
... snip ...

The above is a sample of what could be done.
Yes, the map will destroy itself correctly. No different than the std::string class.
Think about the question you asked. What good would a class such as map be if the user of the class has to clean up the remnants? The purpose of the map and other classes is to ensure that the objects will get properly destroyed once the object goes out of scope, and for any reason whatsoever. That's what destructor functions are for.

Let's say that the user did have to clean up the memory. Would you like to code something like this?
... snip ...

The "CleanUpMap" is the code that the user would need to invoke to clean up the map. Do you see how convoluted code like this would be? Everywhere you have a potential return point, including exceptions that you may or may not know about, you have to clean the map up, else you get a memory leak, a resource not properly destroyed or closed, etc.

Of course, this is not the way that well written classes such as map behave. You declare a map, and if the map goes out of scope for any reason whatsoever (a return from a function, an exception being thrown taking the code out of the current block, an exit from a block of code denoted by { ... }, etc.) the map is cleaned up automatically. Google the term "RAII". The string classes work the same way.

Regards,

Paul McKenzie

My bad Paul. In hindsight I can see why you think my plan is to code most everything using globals and not using classes. The code I posted was just extending your example to verify whether my approach to using an array for the 4 players was valid and was not meant as an example of how I intend to code my program.

I actually plan to use classes for every module and main will just be a very simple loop similar to this:

int _tmain(int argc, _TCHAR* argv[])
{
    sf::RenderWindow App;

    //Applications variables
    std::vector<cScreen*> Screens;
    
    int screen = 1;   //Keeps track of the screen routine currently in use.

    //Screens preparations
    DummyScreen s0;
    Screens.push_back (&s0);

    PrimaryMenu s1;
    Screens.push_back (&s1);

    RTPlay s2;
    Screens.push_back (&s2);

    // Main loop
    // Return zero = exit.  Return value greater than zero goes to that screen (routine) number.
    while (screen > 0)
    {
        screen = Screens[screen]->Run(App);
    }

    return EXIT;
}

There will be a lot more screen routines for different things like SETUP, DISPLAY STATISTICS, HELP, etc.

My plan is to have the one global array (or vector) of map/structs (like you showed me) called BetInformation.

The GetBets class will get mouse clicks and determine which bet the player wants to make. The betTotal for that particular bet will be updated for the active player in BetInformation.

The player will click the "Roll Dice" button which will call the RollDice class. This will produce die1, die2 and diceSum randomly.

The PayBets class will scan the betTotal in the global BetInformation looking for bets made (betTotal > 0). If a betTotal > 0 is found, the bet will be paid, collected or ignored as appropriate for the diceSum rolled. This will continue until the entire BetInformation is scanned.

The DisplayTable class is constantly being called during all of the above to reflect changes on the crap table. DisplayTable will use the betTotal, coordX and coordY to draw the proper amount of chips for every bet made, for each of the 1 to 4 players. IOW, DisplayTable draws everything on the crap table using information in BetInformation.

There's major classes for ComeoutRoll (which contains all of the above) and PointRoll (which also contains all of the above).

In summary, everything will be in classes except the BetInformation array of map/struts which every class needs to access.

Thanks so much for explaining things so well, including the destructors. I really appreciate all of your help and you don't know how much it's helping me structure my program. I'll look into the struct defining a single player you suggested as to how it can fit into my plans.

I always welcome your or other comments. I'm open to changing my plans. Thanks,
Raptor