In this episode, we will present the different alternative versions of the "joue" (TN: means "plays") function that we have written in the previous episode. Please be reminded that this function's goal is to place a disk in the grid, given the number of the column where we intend to drop our disk. Also given is the player's color. By the way, do not forget that this function also verifies the validity of our move. Namely, if the column is full, we will declare that the move is not valid. No matter the implementing we choose for our alternate version of the "joue" function, the prototype is not going to change. Therefore, we will still have here a grid passed by reference, a column passed as argument and a color passed as argument aswell. Nothing has changed here. However, the idea is to come up with a rather different algorithm. We will thus start by saying that, if the column is full, we will not play. The idea is to start by run the test here instead of doing it later. This is written like this: We are testing if the column is full, Be reminded that a column is full if and only if the uppermost level, the level 0 is occupied. Here, we will thus test if the square in the row 0, this row here, and in the column received as argument is not empty. If this square is not empty, that means that the column is full and we will immediately return the fact that this move was invalid, that is, the value "false", We are now released from this condition. Since at this point we know the column is not empty, we can calmly search the place where the disk will be placed. We can freely seek the place where we will play. To that end, we will run through the column, like we did in the previous version, starting from the bottom. In C++, this is written like this. We are declaring a variable which will allow us to climb up the rows, just like we did in the previous version of the "joue" function. We initialize this variable to the size of the grid - 1 then to the current position. That means that, if the square on the position "grille[ligne][colonne]" is not empty, we will decrement the row by 1. Finally, the last step is to fill the square we have found (indeed, thanks to our previous test, we know that such a square exists) and finally to return "true" since we have been able to play our move. Now, we should test our brand new "joue" function; we let you do this as an exercise. Also, feel free to appreciate the differences between the two codes, independently of the number of lines and the comments, by the way. Now, let us see a third version of this "joue" function, restarting with the beginning of the first version, which we presented in the previous episode. We will start by helping you recall the first version. The idea is to focus on the troubles we initially encountered, and brought us so many lines with "pleine" (TN: means "full") here, also revised here aswell. Those precisely pertained on this critical point of decrementing "ligne" here when "ligne" was 0. What happens then? Also, is there a way to rewrite the code in a slightly different way? The idea is to do without this boolean "pleine" and to replace it with another test. Let us keep going from the intial problem. and with a question that we had left unanswered, that was: what happened when we were at the line 0. Since we had not written all this text here, we still executed the instruction " ligne --" Therefore, there was a risk, in this case, to exit the array. So, let us go back to the type of "ligne", which is of "size_t" type. As we told you before, this type, the "size_t" type is always a positive integer. Here, we thus have a problem regarding the number representation. Practically, what wil happen in the memory is that we will have a very big number. No matter the technical aspects though; this is not our focus here. However, this very big number will certainly not be a row number of our array. And so, what should we do here? Well, the systematic reflex we should learn here -another critique regarding our code here will thus arise- is that we should systematically test if the accesses to our array are correct. We garantee this either by a demonstration of our algorithm or by a true test. So, the conditions here are that "ligne" should always be less than "grille.size()". Secondly, an array index cannot be greater than the array size. And, lastly, we should be able to verify that "colonne" (TN: means "column") should always be less than "grille[ligne.size()]" Therefore, this value here "-1" which is the "size_t"-type 0 on which we execute the instruction " -- " will be represented one way or another, for example "impossible", or a very big number, no matter what, this number, " 0 -- ", that is, -1 cannot be represented as a "size_t". Therefore, condition grid here, "less than grille.size() " is not verified. We will use precisely this condition as the overflowing condition of our array. We will thus write, along with a comment here, that if the test "ligne" less than grille.size() is false, that means that the column is full. We thus need to stop since the move is invalid. Now that we have understood and explained what we wish to accomplish, we can correct our code and supress the variable "pleine". We supress here the test which involved it and replace it by this test : "ligne" less than the size of the grid. Please note the protection of the access index, according to the size of the accessed array, before we access it. This is an advice you should systematically abide by. Of course, if such a condition is garanteed by "for loop", or some other constraint, you will not add such a test at every step. However, every time you have to access an array through an index, you should at least ask yourself whether the condition that it is less than the array size is fulfilled. So, we now see that we have explicitly written this useful test, tasked to test if the column is full. Now, we can keep suppressing everything involving "pleine" and finally correct our program wherever the variable "pleine" is no longer needed. Here, still the same test : if the row is less than the grid size, then we can play. Otherwise, that means we could not play. We thus modify our code accordingly. Our third version of "joue" function is now finished. That being said, if you have followed our discourse so far, then you should realize that an error remains in all our "joue" functions. Do you have any idea what we should add to our three "joue" functions in order to render them correct? We will let you implement it yourself as an exercise in the variant of the "joue" function you have choosen to keep for your Connect Four. So, at this point, you should have a correct "joue" function. In the previous episodes, we have presented the data structures necessary to build a Connect Four game, simple functions such as "initialize" and "affiche". Also, in these last two episodes, we have implement the "joue" function, letting us a drop a disk down the indicated column (if this column is valid). Now, we still have to ask the players where they intend to play. We then validate their move -we have just done that. Then, we just just need to iterate, alternating between players. Asking the red player to play, the yellow player and so on. Finally, we will terminate the program once a player wins or once the grid is full. This will occupy us for the next episodes.
