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.
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 ;-)I'm just having trouble understanding what your global picture of how the game should work.
Just because a design is not exclusive to C++, does not make it a bad design.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.
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.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.
An enum class is not actually a class, see my above explanation about strongly typed enumerations.Okay, so, we have a tile class with allowed values of x, o or empty as defined by your example,
Note that I prefer undercase, is all.Code:enum class tile {x, o, empty};
Why do I need each tile to be a class? Do I define the behavior of a tile this way?
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.So, here's what I have so far,
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 simpleCode:#include <iostream> #include <array> using std::array; enum class tile {x, o, empty}; int main(void) { array<array<tile, 3>, 3> gameBoard; return 0; }
would work equally the same.Code:tile gameBoard[3][3];
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.Edit: Ho boy. You can't use cin for enumerated types. Instead, I found something like
which looks super confusing O_oCode:std::istream& operator>>( std::istream& is, object& i ) { int tmp ; if ( is >> tmp ) i = static_cast<object>( tmp ) ; return is ; }
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.