Bonjour! Après avoir longtemps perdu mon temps(du moins selon l'avis d'une grande partie de la communauté sur ce forum) à apprendre le C++ avec le cours d'OC, je me suis mis en tete d'apprendre le Python à la place, langage qui ne m'a malheureusement pas trop plus(allez savoir pourquoi, chui bizarre :^D)
J'ai donc décidé de reprendre l'apprentissage du c++!
Je crée ce topic pour partager les exercices que je ferai tout au long de mon apprentissage et recevoir des conseils...
Mon premier "vrai" programme, j'en ai eu l'idée après le chapitre sur les nombres pseudo-aléatoires.Il tire un nombre au hasard entre 0 et 100 et l'utilisateur doit le deviner:
#include <iostream>
#include <random>
#include <ctime>
int main(){
int userEntry, mysterNumber; bool select{};
auto const seed{std::time(nullptr)}; std::default_random_engine rd{seed}; std::uniform_int_distribution<>ran(0,10);
do{
mysterNumber= ran(rd);
std::cout<<"Un nombre compris entre 0 et 10 a ete tire au hasard par ce programme."<<std::endl<<"Essayez de deviner le nombre mystere!"<<std::endl;
std::cin>>userEntry;
while (userEntry<0 or userEntry>10){
std::cout<<"Le nombre mystere est compris entre 0 et 10!!"<<std::endl;
std::cin>>userEntry;
}
while (userEntry>mysterNumber){
std::cout<<"Plus petit!"<<std::endl;
std::cin>>userEntry;
}
while (userEntry<mysterNumber){
std::cout<<"Plus grand!"<<std::endl;
std::cin>>userEntry;
}
if (userEntry==mysterNumber){
std::cout<<"Exact! Bravo! Recommencer? (0/1)"<<std::endl;
}
std::cin>>select;
} while(select);
}
Je dois préciser qu'il ne marche pas tout à fait bien! Il a tendance à tirer la meme série de nombres à chaque partie (mais bizarrement, cela n'est pas systématique, la série de nombres tirés a déjà changé plus d'une fois, mais une meme série peut revenir 4 ou 5 fois) De plus, le programme "bug" parfois après avoir entré un nombre et affiche le message "Plus petit" ou "Plus grand" une infinité de fois!
Pour tirer un nombre au hasard entre 0 et 100 t'a qu'à faire rand()%101( inclut dans cstdlib)
Et pour éviter cette répétition systématique après un certain nombre de tirages, utilise stand, tu écris au début du main( une SEULE FOIS): srand(Time(NULL)), (dans time.h)
Pour tirer un nombre au hasard entre 0 et 100 t'a qu'à faire rand()%101( inclut dans cstdlib)
Non, pour l'aléatoire, son code est correct. srand et rand n'ont rien à faire dans un programme C++. Ce sont des reliques dépréciées du langage C.
@TheLittlePolo : ne déclare pas plusieurs variables sur la même ligne, et mis à part pour ton générateur aléatoire que tu peux laisser ici, déclare les autres au plus près de leur première utilisation. Effectivement, ton programme n'est pas fonctionnel. Pour ça, je te conseille de dérouler sur papier un exemple tel que :
l'ordinateur choisi 5,
je saisis 1, puis je saisis 4.
Tu vas voir que ça ne fait pas ce que tu veux en prenant méthodiquement les instructions une par une sur papier. En gros, les boucles internes que tu as écrites n'ont pas lieu d'être.
les random engine sont bien la bonne méthode pour générer de l'aléatoire en C++, tu peux l'initialiser avec un random_device plutôt, c'est mieux, mais avec le temps ce n'est pas faux non plus
évite de mettre plusieurs instructions sur la même ligne, ça dégrade la lisibilité
déclare les variables au plus proche de leur utilisation
Tu ne fait pas vraiment ce que tu penses avec tes boucles. Ne fait la saisie qu'une fois, avec les tests de saisies qui vont bien, au début de la boucle, puis test par rapport au nombre mystère avec des if dans la boucle
EDIT : grillé
- Edité par romantik 27 mars 2019 à 17:14:04
Dream on, Dream on, Dream until your dream comes true
@BrayanTiwa il me semble en effet qu'il s'agit d'une ancienne syntaxe issue de C. Je le sais justement car c'est celle que l'on apprend lorsqu'on suit le cours d'OC sur le c++ si c'est ton cas, je ne sais pas quel est ton niveau actuel mais je te conseille vivement(tout comme on me l'a conseillé) de changer rapidement de cours.
Avec les corrections:
#include <iostream>
#include <random>
#include <ctime>
int main(){
int userEntry, mysterNumber;
bool select{};
auto const seed{std::time(nullptr)};
std::default_random_engine rd{seed};
std::uniform_int_distribution<>ran(0,10);
do{
mysterNumber= ran(rd);
std::cout<<"Un nombre compris entre 0 et 10 a ete tire au hasard par ce programme."<<std::endl<<"Essayez de deviner le nombre mystere!"<<std::endl;
std::cin>>userEntry;
while(userEntry!=mysterNumber){
if(userEntry<0 or userEntry>10){
std::cout<<"Le nombre mystere est compris entre 0 et 10!!"<<std::endl;
std::cin>>userEntry;
}
if(userEntry>mysterNumber){
std::cout<<"Plus petit!"<<std::endl;
std::cin>>userEntry;
}
if(userEntry<mysterNumber){
std::cout<<"Plus grand!"<<std::endl;
std::cin>>userEntry;
}
}
if (userEntry==mysterNumber){
std::cout<<"Exact! Bravo! Recommencer? (0/1)"<<std::endl;
}
std::cin>>select;
} while(select);
}
Quand vous proposez de déclarer les variables au plus près de leur première utilisation, j'ai un doute.Dois-je les déclarer à l'intérieur du do....while?
Je me disais que cela entrainerait une re-déclaration de variable à chaque itération, ça ne pose aucun problème?
Personnellement je les mettrais dans le do...while (tu déclares directement mysterNumber avec la valeur aléatoire, et si tu fais une petite fonction pour récupérer l'entré utilisateur, tu peut faire de même avec userEntry) , ya re-déclaration de la variable a chaque tour de boucle, mais on en est pas a ces optimisations (du moins je pense)
Si on parle d'optimisation, déclarer et initialiser la variable au niveau du de la fonction, c'est mieux: on fait en une opération ce qui se fait en 2 (appels de constructeur par défaut puis opérateur= VS une construction de l'objet (qui est en fait optimisée par le compilo).
Si on ne parle pas d'optimisation... C'est mieux aussi: meilleure localité des variables, pas de construction en plusieurs étapes et en plus on peut mettre un const.
Même si srnad et rand dont des méthodes issues du C, le mieux pour un programmeur d'après moi est de faire son code le plus court et efficace possible.
@TheLitllePolo, j'ai fais ton programme depuis avec srand et rand, ça marche très bien et y'a pas cette répétition... j'ai même créer plusieurs modes de jeu avec
Je te dis que j'ai fait un jeu avec plusieurs modes même en C++. Mes amis et moi l'utilisons beaucoup même. J'ai fais mais test et c'est okay.
Dans le cours sur C++ que j'ai eu, c'était bel et bien random. J'ai pas de problème mais je suis convaincu que mon programme fais la même chose que pour lui mais en plus court
Prenons les choses dans l'ordre. Non srand et rand ne sont pas des fonctionnalités à utiliser en C++ depuis que l'on a le header random. Parmi les problèmes de cette fonctionnalité par ordre d'importance :
rand n'a pas le même comportement sur tous les compilos/bibliothèques,
il est facile mal utiliser srand et rand (on va en reparler un peu plus tard),
les générateurs aléatoire de C++ donnent accès à bien plus de fonctionnalités utiles.
Qu'est ce que j'entends par "pas le même comportement sur tous les compilos". Ce que nous dit la doc c'est que rand :
Returns a pseudo-random integer value between 0 and RAND_MAX (0 and RAND_MAX included).
Et c'est là qu'on a un problème : la seule garantie que l'on a à propos de RAND_MAX, c'est la suivante :
Expands to an integer constant expression equal to the maximum value returned by the function rand(). This value is implementation dependent. It's guaranteed that this value is at least 32767.
Donc en gros, selon la taille des nombres qu'on veut générer, on devra utiliser des tricks à la compilation pour avoir des nombres suffisamment grands pour ce qu'on a besoin. Ça nous demande plus de boulot, alors que les générateurs aléatoires de C++ ne souffrent pas de ces problèmes à la con.
Ensuite comme je l'ai dit il est facile de mal utiliser srand/rand, le coup classique c'est les appels multiples à srand, mais ce n'est pas tout, et pas le plus fourbe. Par exemple :
BrayanTiwa a écrit:
Pour tirer un nombre au hasard entre 0 et 100 t'a qu'à faire rand()%101( inclut dans cstdlib)
Ici tu fais une (très classique) mauvaise utilisation de rand(). En l'occurrence, ta distribution aléatoire n'est pas homogène et encore une fois dépendante de l'implémentation. Par exemple si on considère le RAND_MAX à 32767comme demandé par la norme, tu as plus de chances de générer un nombre entre 0 et 43 qu'entre 44 et 100 à cause du modulo. Si on avait eu un RAND_MAX à 32724, ç'aurait été une distribution homogène, mais on a 43 possibilités supplémentaires à ajouter pour arriver à RAND_MAX.
Les générateurs aléatoires de C++ permettent de se passer de ce calcul pas si simple en proposant directement des distributions aléatoire sur mesure. Ici par exemple :
std::uniform_int_distribution<>ran(0,10);
On sait qu'on a une distribution homogène entre 0 et 10. Mieux encore, le générateur peut être paramétré pour utiliser d'autres types, ce que ne permettent pas rand et srand pour lesquels on va encore devoir écrire du code subtil pour ne pas avoir de l'aléatoire tout pourri. Et puis on peut aussi avoir des générateurs différents partis de différentes graines, et on est bien sûr que le générateur n'est initialisé qu'une fois puisque c'est son constructeur qui fait ce job. Et c'est pas les seules fonctionnalités qui sont proposées par le header random en C++, il y a aussi des distributions pour différentes lois de probabilités, des générateurs différents pour des besoins particuliers (plus fortement aléatoire, plus rapide, etc ...).
Bref, non dans un code C++ on utilise pas cette saleté de rand/srand.
Je te conseile encore de ne faire ta saisie du jeu qu'à un seul endroit, et de séparer les vérifications de bonne saisie (la saisie correspond bien à un entier et est compris entre 0 et 10) et les tests du jeu ( plus petit, égal ou plus grand que le nombre mystère).
Je te conseile encore de ne faire ta saisie du jeu qu'à un seul endroit, et de séparer les vérifications de bonne saisie (la saisie correspond bien à un entier et est compris entre 0 et 10) et les tests du jeu ( plus petit, égal ou plus grand que le nombre mystère).
Les vérifications et mm les tirages au hasard sont dans d'autres fichiers reliés à main.cpp par certains headers. Si je pouvais vous montrer mon projet je le ferai
C'était un commentaire à l'attention du PO, par rapport à la correction qu'il a proposé, parce qu'il continue à mettre des std::cin>>userEntry dans chacun de ses cas.
Tant que j'y suis, 2 petites remarques qui ne sont pas grave
seed ne sert qu'à initialiser le random, pourquoi en faire une variable ? tu ne trouvais pas std::default_random_engine rd{std::time(nullptr)}; suffisement lisible ?
Lorsque tu sors de ta boucle, c'est que l'utilisateur a deviné le nombre mystère, ça ne sert donc à rien de le retester juste derrière
Dream on, Dream on, Dream until your dream comes true
Même si srnad et rand dont des méthodes issues du C, le mieux pour un programmeur d'après moi est de faire son code le plus court et efficace possible.
@TheLitllePolo, j'ai fais ton programme depuis avec srand et rand, ça marche très bien et y'a pas cette répétition... j'ai même créer plusieurs modes de jeu avec
J'espère que nous ne sommes pas face à un deuxième Yes, man, car je vais fini par craquer, moi (c'est inutilement méchant, je retire...)
La toute première priorité est d'avoir un code compréhensible! Cela ne sert à rien d'avoir un code compact (surtout s'il ne fait pas ce qu'on lui demande) si personne n'arrive à le comprendre! Et cela rend la deuxième priorité plus accessible.
La deuxième priorité est d'avoir un code qui fait ce qu'on attend de sa part! Cela ne sert à rien d'avoir un code qui fonce rapidement dans le premier mur qu'il rencontre, ou qui "quitte la route" au premier "gravillon" sur lequel il passe.
En tant que débutant en C++, tu peux déjà être très content si tu arrives à faire de ces deux priorité des priorités absolues
Enfin, quand tu as un code compréhensible et qui fait ce qu'on attend de sa part, tu peux commencer à t'inquiéter des problèmes de vitesse. Mais!!!
"Code court" n'est pas forcément synonyme de "code rapide" et encore moins de "code efficace". C'est vrai dans certains langages interprétés, mais certainement pas dans les langages compilés. Et encore moins en C++.
Le seul point sur lequel on peut promouvoir l'idée d'un "code aussi court que possible", c'est dans le respect du SRP (Single Responsability Principle). A savoir que chaque donnée, chaque type de donnée personnalisé, chaque fonction ne doit s'occuper que d'une seule et unique chose; ce qui nous incite -- de fait -- à préférer avoir deux ou trois fonctions (ou cinq ... ou dix, selon la complexité du problème) qui prennent chacune "un aspect bien particulier" du problème en charge, et qui -- de fait -- seront composée d'un "petit" nombre d'instructions, plutôt que de se retrouver avec une seule fonction "mégalithique" composée de la somme de toutes ces instructions.
Mais si la "répartition correcte des responsabilités" est une chose qui nous incite "naturellement" à créer des fonctions "aussi courte que possibles" (vu qu'elle ne s'occupent à chaque fois que d'un aspect bien particulier), il ne faut pas oublier ce que Einstein a dit en son temps :
Il faut rendre les choses aussi complexes que nécessaire, mais sans plus
Alors, oui, il ne sert sans doute à rien de faire en cinq instructions ce que l'on pourrait faire en trois. Cela ne ferait que rendre les choses "plus complexes que nécessaires".
Mais, à côté de cela, si on a besoin de cinq instructions pour obtenir un résultat (ou pour préparer le travail d'une procédure plus complexe), il ne sert à rien de vouloir essayer de le faire en deux!
Les fonctions srand et rand sont percluses de problèmes. Ksass ` Peuk en a cité le plus grave. Il se fait que les générateurs dont il est questions résolvent tous ces problèmes, tout en évitant bien des soucis ultérieures, et pourtant -- de par leur implémentation -- avec un coût à l'utilisation particulièrement intéressant (il me semble même avoir vu certains bench dans lesquels ils écrasaient littéralement srand + rand).
Pourquoi voudrais tu t'en passer ?
- Edité par koala01 29 mars 2019 à 13:44:45
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Ton message est hyper long avec des expressions vraiment du langage soutenu. Merci de tes remarques mais mon programme est rapide et efficace.
J'ai fais ce que je voulais et j'en suis ravi. Dans mes futures œuvres, je vais penser à des codes plus explicites parce que jusqu'à présent je bosse seul donc je fais des trucs court, juste pour moi.
@BrayanTiwa Je n'ai actuellement pas du tout le recul suffisant pour juger si une fonctionnalité ancienne est meilleure qu'une plus récente. De ce fait, je me contente de respecter le cours que je lis et qui promet de m'enseigner le c++ moderne mais aussi de suivre les conseils que je reçois de ceux qui ont plus d'expérience, en attendant d'avoir les capacités pour me forger mes propres avis.
Donc, encore une fois je ne sais pas quel est ton niveau mais tu sembles utiliser des fonctionnalités arriérées et je doute que cela t'aide.
@romantik
Merci beaucoup pour les conseils!
Comme je l'ai dit ça fait un peu plus de deux semaines que je lis ce cours (plutot lentement) donc je n'ai pas un grand nombre de fonctionnalités en tete!
Je ne compte plus modifier ce code, je passe à autre chose mais tes conseils me sont d'une aide précieuse :DD
Crois moi, tu n'a jamais vu un long message de ma part!!!
Il m'est arrivé, sur un autre forum, que le système refuse mon intervention car le nombre de ses caractères dépassait la limite autorisée (qui était pourtant de 65 000 et quelques)... Ca, ce sont de long messages de ma part
avec des expressions vraiment du langage soutenu.
Quelles expression de langage soutenu ?
priotiré (absolue)?
code court, code efficace ?
"foncer dans le mur", "quitter la route au moindre gravillon rencontré" ?
SRP ?
Non, j'ai trouvé: percluses : ca, c'est un terme que l'on n'a pas l'occasion d'utiliser souvent
Si il y a un seul terme, une seule expression que tu ne comprends pas, pose la question! Que ce soit moi ou quelqu'un d'autre, nous nous ferons un plaisir de te l'expliquer
Merci de tes remarques mais mon programme est rapide et efficace.
Je n'en doute pas un seul instant!!!
Jusqu'au jour où tu voudras le modifier, peut-être simplement pour lui ajouter une fonctionnalité, ou, plus vraisemblablement, pour corriger un bug (parce que tu auras dépassés les limites avec srand() / rand()...
Car, si tu te souviens encore très bien du code que tu as écrit il y a une heure, ou même de celui que tu as écrit hier (en fonction de tes activités) et des raisons pour lesquelles tu as décidé de faire "quelque chose" d'une certaine manière, à de très rares exception, un code, c'est fait pour durer :
Il n'y a rien qui t'empêche, dans deux ans, ou même, quand tu auras pris ta pension de ressortir le code que tu as écrit à tes tous débuts.
A ceci près que tu auras eu tout le temps d'oublier à quoi sert telle variable ou ce qu'est sensé faire telle partie du code. Et tu peux me croire, on oublie très vite lorsqu'on est actif. Ne serait-ce que parce que l'on a tous les jours l'occasion de se frotter à de nouveaux problèmes, qui nous obligent à nous concentrer dessus, et à prendre de nouvelles décisions.
Et, à ce moment là, ton code que tu croyais "clair comme de l'eau de roche" te paraîtra tout de suite beaucoup moins limpide si tu n'y fais pas attention.
Ou pire encore : jusqu'au jour où tu voudras faire lire ton code par un autre... Pour obtenir de l'aide sur un forum, peut-être?
Parce que ceux qui devront lire ton code, il n'étaient le plus souvent pas au dessus de ton épaule lorsque tu l'as écrit. Et, quand bien même ils y auraient été, tu n'auras sans doute pas pris la peine de leur expliquer chaque décision que tu prenais.
Du coup, la seule source d'informations sur laquelle ils pourront compter pour "se faire une vague idée" de tes intentions, ce sera ... le code... : le nom des données, des fonctions et des types de données que tu auras créés. L'ordre dans lequel les différents éléments s'emboîtent.
Le seul moyen pour obtenir une aide rapide et efficace (et, au passage, pour s'éviter bien des nuits blanches à se demander "pourquoi ca ne veut pas fonctionner"), c'est d'avoir un code compréhensible.
J'ai fais ce que je voulais et j'en suis ravi. Dans mes futures œuvres, je vais penser à des codes plus explicites parce que jusqu'à présent je bosse seul donc je fais des trucs court, juste pour moi.
Tu n'as pas encore compris? En informatique (surtout lorsqu'on est débutant), on ne bosse jamais seul...
Il y a toujours un moment où l'on a besoin d'aller demander de l'aide pour une raison ou une autre
Et tous les gens qui seront prêts à t'aider -- parce que la plupart des développeurs sont prèts à donner un coup de main -- feront (même "momentanément") partie ... de "ton équipe"...
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Et puis il y a la taille du code, plus un programme est "puissant", plus son code sera long... Là on retrouve ce qu'a dit Koala01 avec non plus le temps mais juste l'espace. Je "gère" des programmes qui font dans le demi million de lignes de code, c'est tellement gigantesque, qu'il est juste impossible d'avoir les idées claires sur un programme de ce genre. Et pourtant il faut gérer, et j'y arrive, pour une raison toute simple, chaque nom de fonction, chaque nom de variable a été choisi avec le plus grand soin, on a essayé (mais pas forcément réussi) de cloisonner au maximum,pour faciliter la maintenance du monstre. Le temps n'est pas la seule contrainte, l'espace l'est aussi, plus le programme est gros, moins tu le maîtrise. Ce qui vaut pour le temps vaut aussi pour l'espace: dans un programme de 100 lignes tu peux te permettre certaines bêtises, dans un programme d'un million de lignes, tu ne peux plus, c'est juste au delà des capacités de n'importe quel cerveau même le plus génial. Il y a un autre élément qui est très important, l'objet de ton programme: Si c'est un jeu, une défaillance ne causera que l'exaspération des joueurs, si c'est un programme de pilotage de réacteur nucléaire, les conséquences seront peut être un petit peu plus graves...
J'ai beaucoup de doutes ici, en commençant par l'utilisation de tableaux comme base. Je doute que ce soit le mieux à faire mais en meme temps c'est ce que j'ai trouvé de mieux pour facilement modifier le contenu de la grille de morpion..
J'ai laissé quelques remarques et interrogations en commentaire
Ps: je n'arrive plus à formater le code!! Si quelqu'un veut bien le faire pour moi en attendant que je trouve pourquoi:
#include <iostream>
#include <vector>//<Array> peut-etre plus adapté? Puisque la taille de tableau est fixe.
C'est normal que tu n'arrive plus à formater ton code, OC nous a pondu une mise à jour de derrière les fagots, non testée et buggé à mort. Au passage, pour un site qui prétend enseigner, ça la fout mal...
Bon concernant ton problème, ton idée première d'utiliser un tableau, n'est pas si absurde, si tu y réfléchis un peu plus, tu verras que non seulement elle n'est pas absurde, mais que c'est carrément la très bonne idée
Une grille de morpion c'est un tableau 2d, hors les mathématiciens nous disent qu'il est très facile de passer d'un tableau à une grille, il suffit de penser que les lignes de la grilles sont mise les une à la suite des autres. Cette petite constatation débouche sur l'idée que j'ai une formule très simple pour accéder à n'importe quelle case de ma grille: p = N° de ligne * taille des colonnes + N° de la colonne. On appelle ça la linéarisation
En attendant que l'éditeur tout pété soit de nouveau remis sur pied tu peux mettre ton code entre balise html (comme c'est tout pété on peut le faire uniquement après avoir posté le message) :
#include <iostream>
#include <vector>//<Array> peut-etre plus adapté? Puisque la taille de tableau est fixe.
void Display_grill(std::vector<char>content){
std::cout<<content.at(0)<<'|'<<content.at(1)<<'|'<<content.at(2)<<std::endl;
std::cout<<"-+-+-"<<std::endl;
std::cout<<content.at(3)<<'|'<<content.at(4)<<'|'<<content.at(5)<<std::endl;
std::cout<<"-+-+-"<<std::endl;
std::cout<<content.at(6)<<'|'<<content.at(7)<<'|'<<content.at(8)<<std::endl;
}
std::vector<char> Update_grill(int nextMove, char sign, std::vector<char>grill){
grill.at(nextMove-1)=sign;
return grill;
}
bool Someone_won(std::vector<char>grill){//Conditions pour qu'un des deux joueurs gagne. Un peu barbare, mais je voyais pas comment faire autrement X)
return ((grill.at(0)==grill.at(1) && grill.at(1)==grill.at(2)) or (grill.at(0)==grill.at(3) && grill.at(3)==grill.at(6))
or (grill.at(0)==grill.at(4) && grill.at(4)==grill.at(8)) or (grill.at(1)==grill.at(4) && grill.at(4)==grill.at(7))
or (grill.at(2)==grill.at(5) && grill.at(5)==grill.at(8)) or (grill.at(2)==grill.at(4) && grill.at(4)==grill.at(6))
or (grill.at(3)==grill.at(4) && grill.at(4)==grill.at(5)) or (grill.at(6)==grill.at(7) && grill.at(7)==grill.at(8)));
}
int main(){
bool restart{false};
do{
int nextMove, movesCount=0;
bool gameOver{false};
bool player1Turn{true};
std::vector<char>Grill{'1','2','3','4','5','6','7','8','9'};
Display_grill(Grill);
do{
//Demander le coup du joueur
if(player1Turn){
std::cout<<"Player1's turn: ";
std::cin>>nextMove;
}
else{
std::cout<<"Player2's turn: ";
std::cin>>nextMove;
}
std::cout<<std::endl;
//vérifier la validité de son coup
while(nextMove<1 or nextMove>9 or Grill.at(nextMove-1)=='X' or Grill.at(nextMove-1)=='O'){//Conditions d'invalidité de l'entrée du joueur
std::cout<<"Invalid entry"<<std::endl;
std::cin>>nextMove;
}
//Mettre à jour et la grille en fonction du coup du joueur et l'afficher
if(player1Turn){
Grill=Update_grill(nextMove,'X',Grill);
player1Turn=false;
}
else{
Grill=Update_grill(nextMove,'O',Grill);
player1Turn=true;
}
movesCount++;
Display_grill(Grill);
if(Someone_won(Grill)){
//déterminer quel joueur a gagné (le dernier à avoir joué)
if(Grill.at(nextMove-1)=='X'){
std::cout<<"Player1 wins!"<<std::endl;
}
else{
std::cout<<"player2 wins!"<<std::endl;
}
gameOver=true;
//En cas d'égalité
}else if (movesCount==9){
std::cout<<"Draw!"<<std::endl;
gameOver=true;
}
}while(!gameOver);
std::cout<<"Restart?(0/1)";
std::cin>>restart;
}while (restart);
}
Sinon ne t'embête pas si tu n'y arrives pas, demain c'est Lundi, les stagiaires de chez Openclassrooms seront là pour finir leur boulot sur l'éditeur.
--------------------------------------------
EDIT :
J'en profite pour faire 2-3 remarques sur ton code :
Le bon point c'est que tu codes en anglais, par contre "Grill" ça veut dire "Grilloir" en français, j'pense pas que ton but soit de faire griller des saucisses . Le mot correct c'est "Grid"
N'utilise pas std::vector::at(...) (je ne sais plus pourquoi mais c'est déconseillé), utilise l'opérateur fait pour [...]
La condition du return de ta fonction Someone_won sors tout droit de l'espace, ce n'est pas très lisible. Ce serait peut-être mieux d'étaler les conditions dans la fonction.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
GitHub
Architecte logiciel - Software craftsmanship convaincu.
Architecte logiciel - Software craftsmanship convaincu.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
...
...
...