Hey guys, haven't been on in a bit. I'm trying to make a game of Tic-Tac-Toe using SDL and C++, and I'm using an array to store the "board". It's a nine-slot array, a 0 means unoccupied, 1 means user-occupied, and 2 means AI-occupied. The problem is that the array doesn't get modified correctly when I call something like

board is passed to the function update(int* board), which is also in main.cppWhich in turn passes it to the method move of the class user (declaration in TicTacToe.h and implementation in TicTacToe.cpp) like so:

So I tried out an idea based on what you're doing. I know it's not exactly the same code as you, but this code does what you expect it to and places the pieces in the correct slots in the array. So maybe you can give some more details on what you're doing and it'll help us help you.

Thanks for the quick reply I tried your example, and you're right, it does do what I originally intended to do!If you'd like to check all of my code out it's here: (only about 350 lines of total code )http://dl.dropbox.com/u/3701354/TicTacToe.zip

I just don't know if I'm passing my array properly to my instance methods and function. I noticed that you're using board as a class containing an array, but mine is just a global array variable... Also, yours is all in one file (technically), and mine is split into 3, and that is why I originally thought there was a problem... Do you think that I should go and create a Board class like you did and see if it would work, instead of keeping it a global variable?

You're welcome. And to answer your question. std::fill_n is a function defined in <algorithm>. What it does is fill a collection, in this case a simple array of int. It probably is not required to fill an array of int with zeros, because the default value for an int on most systems is zero, but it could also be undefined. This is probably a little superstitious, but that's what it does. The definition for it is

Yes, basically std::fill_n is like a for loop. It can be used with any collection that is iterable, which if it's a C++ collection it is. The definition requires something that falls into the type "OutputIterator". OutputIterator is more specialized than just an array or collection, like vector<&T>. Collections usually have iterators or can be wrapped in an iterator in order to iterate over the collection.

On that page I linked you to for the definition of std::fill_n it states that the following is the defined behavior for the function:

I was working on a more complete version of the text-mode TicTacToe based on your idea. You mentioned that I had just used one file, which does simplify the program significantly. Once you start using header files then the whole solution becomes more complex, but it is also easier to maintain. Here is a link to my version of TicTacToe so far, which is closer to what you're looking for. The only thing missing right now is the function that determines a winner: http://dl.dropbox.com/u/10646479/TicTacToe.zip

I'm still looking at your code, because everything I've read says it should work. I haven't tried to run it yet though.

-- Wed Jan 05, 2011 10:15 am --

Alright I just wrote a simple program to test passing an array of ints around and manipulating it.

The this-> is not a requirement in C++. It can make semantics more obvious when you look back at your code. I use syntactic hinting in my code a lot so that I immediately understand the scope, which in turn makes the program easier to follow and maintain. If you download the program again, you will see that I took out the this-> in all of the files.

In your case I don't think that creating a Board class will necessarily solve all of your problems. I started and finished my program in text mode because it simplifies all of the overhead and complexity that SDL adds. If I wanted to I could relatively enhance the program now by adding SDL. In general separating control, models, and display (or view) makes all programs much easier to maintain and debug. Perhaps a rewrite would do you some good. Take some time and see what I did -- you definitely DON'T need to copy or even use my code -- and form a plan based on what objects you want and how you want them to interact. If you want your board to be global and utilize C++ OOP (classes) then I think you should probably put the board into a singleton class. This is how OOP handles "global variables". In my code I thought that allowing the board to control all changes to itself made sense: a player may ask the board to place a marker, but the board can decline the request if another marker is already in the spot in question. That's my Object-Oriented mind thinking.

In general OOP takes a lot of practice, more practice than simply programming. Try a few different things, use what works best. Over a year ago I wrote an article about this called Two or Three Ways to Do Things.

What a silly mistake, I really should have realized that... Ran it, works perfectly!

I see what you mean about this-> That seems like a good idea to distinguish variables, I just did it and it makes the code much more readable than I thought it would! Plus it'll keep me close to Python's self

I'm using SDL because I want it as a beginning introduction to game design, but maybe I should make a text-based Tic-Tac-Toe, that would give me a really good idea of the design for the graphical version!

After that, I think I'll do a complete rewrite from scratch, definitely redesigning my OOP structure, maybe learning some more SDL and C++ on the way. I think I'll try a few different strategies, no OOP, some OOP, and full OOP and see how each one goes. I may be back within a week with a remade design!

By the way, I really like your blog! I've already read a few articles and realized that I'm not the only one who can't get it on the first try

Anyway, thanks a ton for your help! At first I thought it was just a silly mistake that I had made, but I guess my entire design was flawed, oh well, not bad for a first try

Thanks again!

"Knowledge is knowing that a tomato is a fruit, but Wisdom is knowing not to put it in a fruit salad."

Nah don't worry about it. Anyway I'm glad I could help you out somewhat, even though I still can't find the problem of what's going wrong exactly. Thanks about my blog. I don't have much on there, because I don't have much time. But the things I write are things that are important to me, and that I feel would be helpful to some other people.

As far as using SDL goes, I didn't mean to sound like that was a bad thing to use it. My intent (which I realize was not clear at all) was to say that in my code I tried to reduce the coupling between my user interface and all of the other functionality. In general this should be a goal no matter if your program is functional or object-oriented in nature. In my code Board contains most of the game's functionality, WinningMoves contains some important data (to determine if there is a winner), and Game is where I house my game loop and input control. In my case [I meant] all that I would need to do to make the game use SDL is swap out Game.h and Game.cpp for one that uses SDL instead of the CLI. Keeping data structures and behavior separate from the user interface is what makes a better program that is easier to maintain and extend, and this takes practice. I talk more about practice and some other things in a couple of other posts on this forum in Programming called "Who Wants to Learn How to Program?" (one is sticky at the top, and the other is somewhere in the middle, but most of it is in the sticky one): sticky Who Wants to Learn How to Program and other Who Wants to Learn How to Program (extension).