Quote Originally Posted by MutantJohn View Post
Wait, doesn't C have enumerations too? Wouldn't this be a small example in C?
Code:
typedef enum {x, o, empty} tile;
tile exampleTile = x;
So enumerations are cool but what happens if the user tries to set the tile value to something not defined in the enumeration? Do I use a throw and exception or something?
Yes C has enumerations aswell, but if you look at my post again you will notice that i used an enum class, which is a new C++11 feature which makes enums strongly typed, unlike C-style enumerations.

Anyways dealing with user input is another can of worms, do not get board representation mixed up with user input.

I'm just having trouble understanding what your global picture of how the game should work.
Well since i only made suggestions on how you should represent the board, and never offered any comments on how other parts of the game should be designed i don't find that strange at all ;-)

What you seem to be suggesting is, we need 9 tiles (obviously, the game is played on a 3x3 board). We use enumerations to represent each tile which I like a lot. But this isn't unique to C++ so I don't know what point you were trying to make.
Just because a design is not exclusive to C++, does not make it a bad design.

Also, if I include the 'class' keyword, it tells me I need the c++11 standard which I'm trying to eschew at this stage of my C++ development. But I can use it if you really want. Yeah, even the use of std::array requires c++11 so I guess I'll get with the times and use it.
enum classes and std::array are very simple to use, and you can use them without concerning yourself with any other C++11 features if you so wish.

Okay, so, we have a tile class with allowed values of x, o or empty as defined by your example,
Code:
enum class tile {x, o, empty};
Note that I prefer undercase, is all.

Why do I need each tile to be a class? Do I define the behavior of a tile this way?
An enum class is not actually a class, see my above explanation about strongly typed enumerations.

So, here's what I have so far,
Code:
#include <iostream>
#include <array>


using std::array;


enum class tile {x, o, empty};


int main(void) {


   array<array<tile, 3>, 3> gameBoard;


   return 0;
}
I know the syntax is confusing when using std::array but just trying to conform to your wishes makes it look like that. I'm imagining a simple
Code:
tile gameBoard[3][3];
would work equally the same.
No it wouldn't, you need to use the template syntax when declaring a std::array. Anyways as i recommended earlier i would hide all this in a class representing the board somehow. Do not let other parts of the program have to deal with your 2D array directly.

Edit: Ho boy. You can't use cin for enumerated types. Instead, I found something like
Code:
std::istream& operator>>( std::istream& is, object& i )
{
    int tmp ;
    if ( is >> tmp )
        i = static_cast<object>( tmp ) ;
    return is ;
}
which looks super confusing O_o
Forget about that, you need to separate the user input from the backend logic of the game. Write a function that polls the user for a move and returns this input in a way that matches with your board representation. This function could feasibly read the input into a string or char, and if the input is not valid (ie. the user input has a value which cannot logically be mapped to a move on the board) then keep polling the user for input or return with an error or whatever else you'd like to do. With this approach, you can have all the error checking and defensive programming isolated in one part of your program, and then you can be less strict about error checking when dealing with the actual logic of the game, all the values should fit because you already filtered out bad input from the user.

Another advantage to this approach is if you want to change the frontend to a GUI with a 2D TTT board being rendered properly, you can simply swap out your user input function for one that accepts mouse clicks. The backend does not need to change at all. Separation of concerns is everything in OO design. Do not design your board representation to make user input easy, design it to properly represent a TTT board and then make user input with separate objects/functions.

Ofcourse this might be a case of overengineering, we are talking about tic-tac-toe after all. But this is what i'd suggest if you want to do it right.