Bonjour je suis loin d'être très bon en prog et l'on me demande de faire un puissance4 j'ai commencé a le réaliser mais il se trouve que je suis bloqué je n'arrive pas a aller plus loin.  
Je dois utilisé DEV Cpp je n'ai pas le choix.
 
avant tout vous aurez besoin de la librairie de l'iut.  
http://www.laas.fr/~alozes/Telecharger_C++.htm          Bibliothèque pour programmes DOS (sous Dev-Cpp)
 
Je n'arrive plus a avancer et je dois rendre mon prog demain avant midi. Si vous etes fort en prog serait il possible de le faire tourner merci. Tout bout de programme sera le bienvenue ou modification qui fait tourner complètement
le jeu . Comme vous pouvez le voir je ne suis pas très fort mais j'ai bossé je demande de l'aide en urgence.
Vous pouvez me répondre par mp ou par le biais du forum.
TT AIDE SERA la bienvenue.
Ps: ne pas faire trop des appel de code source ou cela pour que je puisse comprendre. Merci
IL S'AGIT D'UN PUISSANCE 4.      
A oui les programme qui pose souci sont  
Test diagonale et place jeton principalement.
J'aimerais gardé si possible certain de mais sous prog.
Voici mon programme:    
 A recopie sous dev et utiliser la librairie  
 
 
//************************ Application console C/C++ ***************************
//***************** IUT **** 1ERE ANNEE 08/09 ********************
//******************************************************************************
//  PROGRAMME :  P4.ccp (mettre à jour ce cartouche)
//  DATE      :  10/09/2009
//  OBJET     :  Puissance 4
//            :
//  LIMITES   :  
//            :
//  APPEL     :
//  AUTEUR(S) :    
//******************************************************************************
/******************************************************************************/
// ===================== Liste des fichiers d'entete ======================== //
/*  
Si vous utilisez une des bibliothèques de iutupadte (cf. aide en ligne)  
décommentez dans la ligne suivant.
*/
#include <iut_tlse3\iutupdate.hpp>  //inclut en une fois tous les fichiers  
 
#include <iostream>    // flux d'entrée sortie
#include <iomanip>     // manipulateurs de flux              
#include <cstdlib>     // bibliothèque c standard
#include <conio.h>            
#include <windows.h>
#include <fstream>
 
using namespace std;   // permet d'utiliser les flux cin et cout
 
// ========================= Declarations globales ========================== //
// ================================= Macros ================================= //
 
// =============================== Constantes =============================== //
const int tabx=7;   //constante du tableau qui defini la taille de celui-ci//
const int taby=6;
const int NB_ALIGNES=4;
const int ROUGE=1;
const int JAUNE=2;
//const int NOIR=16;
//const int BLANC=15;
//const int ROUG=12;
//const int BLEU=1;
//const int GREY=7;
const int VIDE=0;
const int PLEIN = 9;
const int LEFT=20;
const int TOP=2;
const int LARGCOL=6;
const int HAUTCOL=2;
 
// ================================== Types ================================= //
//typedef int grille[taby][tabx];
typedef struct {int place;
                int couleur;}t_cas;
typedef t_cas t_grille[taby][tabx];
 
// =============================== Variables ================================ //
 
// =============================== Fonctions ================================ //
//******************************************************************************
 
/*verifie si  les quatre jetons sont alignés verticalement,
horizontalement et diagonale.
programme qui controle si les 4 jetons sont alignés verticalement
*/
 
void couleur(int couleurDuTexte,int couleurDeFond)
{
    HANDLE H=GetStdHandle(STD_OUTPUT_HANDLE);
    SetConsoleTextAttribute(H,couleurDeFond*16+couleurDuTexte);
}
 
/*void affich_jeton( int col, int lig  )
{
     //declaration
     int larg, lon,rop;
     //action
  system("cls" );  
  couleur(BLACK, WHITE);  
  //grid(20,2,7,4,6,2,DOTTEDLINE);.
     larg=(LEFT+2)+col*(LARGCOL+1);
     lon=(TOP+1)+lig*(HAUTCOL+1);
     //gotoxy(larg,4);
     cout<<"  ";
     //gotoxy(larg,lon+1);
     cout<<"  ";
     
}*/
 
void aff_jeton(int couleur, int ligne, int colonne)
{    
    int h, larg;
     h=((3*ligne)+22);
     larg=((5*colonne)+22);
    gotoxy( h, larg);
    if (couleur==ROUGE)
        textcolor(LIGHTRED);
    else  
        textcolor(YELLOW);
    cprintf("##" );
     
}
 
void affiche_grille(t_grille gril)
{
  clrscr();
  cout<<"                    0    1    2    3    4    5    6  "<<endl;;
  int colo, lign;
  grid(20,2,7,4,6,2,DOTTEDLINE);
  for(colo=0;colo<taby;colo++)
      for(lign=0;lign<tabx;lign++)
            if(gril[colo][lign].place!=VIDE)
                {
                   aff_jeton(gril[colo][lign].couleur, colo, lign);
                }
 
}
 
bool test_horizontal(int ligne, int  colonne, t_grille g)
/*verifie si trois jetons consécutif de même couleur que celui en position colonne,ligne sont alignés  
horizontalement dans la grille de gauche à droite */
{
 //declaration
 int nbrepionaligne, couleur, i;
 bool gagne;
 //Action
 nbrepionaligne=1;
 couleur=g[ligne][colonne].couleur;
 if (( colonne<=taby-3) && (couleur!=VIDE))
     for ( i=1; i<NB_ALIGNES; i++)
       if (g[ligne][colonne+i].couleur == couleur )
              nbrepionaligne++;
    gagne=(nbrepionaligne==NB_ALIGNES);
 return (gagne);  
}
//******************************************************************************
bool test_vertical(int ligne, int  colonne, t_grille g)
/*verifie si trois jetons consécutif de même couleur que celui en position colonne,ligne sont alignés  
horizontalement dans la grille de gauche à droite */
{
 //declaration
 int nbrepionaligne, couleur, i;
 bool gagne;
 //Action
 nbrepionaligne=1;
 couleur=g[ligne][colonne].couleur;
 if (( colonne<=taby-3) && (couleur!=VIDE))
     for ( i=1; i<NB_ALIGNES; i++)
       if (g[ligne+i][colonne].couleur == couleur )
              nbrepionaligne++;
    gagne=(nbrepionaligne==NB_ALIGNES);
 return (gagne);  
}
 
//******************************************************************************
bool test_diagonale(int ligne, int  colonne, t_grille g)
/*verifie si trois jetons consécutif de même couleur que celui en position colonne,ligne sont alignés  
horizontalement dans la grille de gauche à droite */
{/*
 //declaration
 int nbrepionaligne, couleur, i,j;
 bool gagne;
 
 //Action
 nbrepionaligne=1;
 couleur=g[ligne][colonne].couleur;
 if (( colonne<=taby-3) && (g[ligne][colonne].place!=VIDE))
     for ( i=1; i<NB_ALIGNES; i++)
         for ( j=1; j<NB_ALIGNES; i++)
       if (g[ligne+i][colonne+j].couleur == couleur )
              nbrepionaligne++;
    gagne=(nbrepionaligne==NB_ALIGNES);
 return (gagne);  */
 return(0);
}
//****************************************************************************//
//test etage verifie si l'etage est plein ou pas! SERT aRIEN A SUPP
/*bool test_etage1()
{  
    //declaration
 grille etage;
 int cpt,compte;
 bool etag_plein;
 //action
 for (cpt=0;cpt>=7;cpt++)
     if (etage[cpt==1])
        compte=compte++;
           if (compte==7)
           return(true);
           else
        return(false);
}  */  
//******************************************************************************
 
//******************************************************************************
//programme qui place le jezton dans la grille
 
void place_jeton(int colonne, t_grille& gril, int joueur)
{    
    int ligne=0;
   
  while(gril[colonne][ligne].place!=VIDE)
  {  
 ligne++;
  }
  gril[colonne][ligne].place = PLEIN;
  gril[colonne][ligne].couleur= joueur;
}
//******************************************************************************
//programme qui rempli la grille de jeu a des valeur de 0.
void init_grille(t_grille& grillejeu)
{
 int colon,affich;  
 int etag;
 //grille grillejeu;
 
 //action
 for(colon=0;colon<taby;colon++)
  for(etag=0;etag<tabx;etag++)  
   grillejeu[colon][etag].place = VIDE ;                          
}
//******************************************************************************
//tour_joueur renvoie la valeur qui alterne le joueur 1 et 2
void tour_joueur(int &valeur)
{
 //declaration
 //action
 if (valeur=JAUNE)
      valeur=ROUGE;
 else  
         valeur=JAUNE;
 
         //cout<<valeur;
}
//******************************************************************************
 
bool test_gagne(t_grille grille_jeu)
{
    int col, lign;
    bool gagne, vertical, horizontal, diago;
     
 for(col=0;col<taby;col++)
  for(lign=0;lign<tabx;lign++)
  {
    //cout<<"etape1";
    vertical = test_vertical(col, lign, grille_jeu) | vertical;
    //cout<<"etape2";
    horizontal = test_horizontal(col, lign, grille_jeu) | horizontal;
    //cout<<"etape3";
    //diago = test_diagonale(col, lign, grille_jeu) | diago;
    cout<<"etape4";
     }
     gagne = vertical | horizontal | diago;
     return(gagne);
}
//*****************************************************************************
//test colonne verifie si la colonne est pleine ou pas!
bool test_colonne(t_grille gril , int valu )
{
 //declaration
 bool plein=true;
 int lign;
 
    //action
    for(lign=0;lign<tabx;lign++)
        if(gril[lign][valu].place==VIDE)
                plein=plein & true;
 /*if (colonne[valu !=0].place)
    return (plein=false);
 else*/
       return (plein);
}
         
//****************************************************************************//                  
void fin_partie(int coul_jeton)
{
 if (coul_jeton==JAUNE)
    cout<<"C'est le joueur "<<JAUNE<<" qui gagne !"<<endl;  
 else
       cout<<"C'est le joueur "<<ROUGE<<" qui gagne !"<<endl;  
}
 
// Sous programme de jeu!!!
//******************************************************************************
//******************************************************************************
void presentation()
{    
 couleur(WHITE, BLACK);
 cout<<"--Puissance 4  --"<<endl;
 couleur(LIGHTRED, BLACK);
 cout<<endl;
 cout<<endl;
 cout<<"  zzzzzzz  zz   zz  zz   zzzzzz  zzzzzz  zzzzzzz  zzz  zz  zzzzzz  zzzzzz "<<endl;
 cout<<"  zz   zz  zz   zz       z       z       zz   zz  zz z zz  zz      zz     "<<endl;
 cout<<"  zzzzzzz  zz   zz  zz   zzzzzz  zzzzzz  zzzzzzz  zz z zz  zz      zzzz   "<<endl;
 cout<<"  zz       zz   zz  zz        z       z  zz   zz  zz z zz  zz      zz     "<<endl;
 cout<<"  zz       zzzzzzz  zz   zzzzzz  zzzzzz  zz   zz  zz  zzz  zzzzzz  zzzzzz "<<endl;
 couleur(LIGHTBLUE, BLACK);
 cout<<"                                                                          "<<endl;
 cout<<"                                 zz   zz                                  "<<endl;
 cout<<"                                 zz   zz                                  "<<endl;
 cout<<"                                 zzzzzzz                                  "<<endl;
 cout<<"                                      zz                                  "<<endl;
 cout<<"                                      zz                                  "<<endl;
 couleur(WHITE, BLACK);
 cout<<"  *********************************************************************** "<<endl;  
    couleur(LIGHTGRAY, BLACK);
}
 
//******************************************************************************
//programme qui affiche le menu
//
int menu()
{    
 char choix;
 do
 {  
        system("cls" );  
        presentation();
  couleur(WHITE, BLACK);
  cout<<" Quel mode de jeu desires tu ?"<<endl;
  cout<<endl;
  cout<<"-Selectionner :"<<endl;
  cout<<"1 pour le mode Joueur 1 vs Joueur 2"<<endl;
  cout<<"2 pour les regles du jeux"<<endl;
  cout<<"3 pour  a propos"<<endl;
  cout<<"4 pour quitter"<<endl;
  cout<<"-Ton choix: "<<endl;  
  cin>>choix;
 }
 while(choix!='1' and choix!='2' and choix!='3' and choix!='4');
 return(choix);
}
//******************************************************************************
 
//******************************************************************************
void J1vsJ2()
{
     
 //declaration
 int colon, num_joueur;
 t_grille grill_jeu;
 //t_grille grill_jeu={{VIDE},
                        //{VIDE},
                      //  {JAUNE,JAUNE,ROUGE,JAUNE},
                        /*{VIDE,VIDE,ROUGE,JAUNE,ROUGE},
                        {VIDE,ROUGE,JAUNE},
                        {ROUGE,JAUNE,JAUNE}*///};
                         
 
 //action
 //init_grille(grill_jeu);
 num_joueur=JAUNE;
 
 //cout<<test_gagne(grill_jeu);
 while(test_gagne(grill_jeu))
 {    
        cout<<"hi!";
        affiche_grille(grill_jeu);
         
        delay(1000);
  cin>>colon;
  do
  {
   while(true)
   {
    switch(colon)
    {
    case 1 : place_jeton (colon, grill_jeu,  num_joueur);
     break;
    case 2 : place_jeton (colon, grill_jeu,  num_joueur);
     break;
    case 3 : place_jeton (colon, grill_jeu,  num_joueur);
     break;
    case 4 : place_jeton (colon, grill_jeu,  num_joueur);
     break;
    case 5 : place_jeton (colon, grill_jeu,  num_joueur);
     break;
    case 6 : place_jeton (colon, grill_jeu,  num_joueur);
     break;
                }  
   }
  }while(true);
 }
 //fin_partie(num_joueur);
}
 
//******************************************************************************
 
void regle()
{
 cout<<"------------------------Regle------------------------"<<endl;
 cout<<"Puissance 4 est un jeu qui se joue a deux. "<<endl;
 cout<<"Le but du jeu est d'aligner le premier 4 pions de sa propre couleur"<<endl;
 cout<<"Les 4 pions peuvent etre alignes horizontalement, verticalement "<<endl;
 cout<<"ou encore en diagonale. "<<endl;
    cout<<" Taper sur une touche pour revenir au menu"<<endl;
    getch();
    menu();
     
}
 
//******************************************************************************
 
void apropos()
{    
    cout<<"------------------------A propos------------------------"<<endl;
 cout<<"Ce programme a ete cree dans le cadre du projet de programmation"<<endl;
 cout<<"il est totalement opensource"<<endl;
    cout<<" Taper sur une touche pour revenir au menu"<<endl;
    getch();
    menu();
}  
 
//****************************************************************************//
//****************************************************************************//
// ========================== Programme principal =========================== //
int main ()
{
 // Déclaration locale
 int choi;
   /*  grille grille_test={{VIDE},
                        {VIDE},
                        {JAUNE,JAUNE,JAUNE,JAUNE,JAUNE},
                        {VIDE,VIDE,ROUGE,JAUNE,ROUGE},
                        {VIDE,ROUGE,JAUNE},
                        {ROUGE,JAUNE,JAUNE}};
                        */
    bool resultat;
 // Action  
 choi=menu();
 
 switch(choi)
 {
        case '1' :J1vsJ2();
           break;
        case '2' : regle();
                 break;
        case '3' : apropos();
           break;
        case '4' : return (0);  
           break;
  default : menu();  
 }
cout<<endl;
system("pause" );
return(0);
}
// ============================ Fin du programme ============================= //

- balise code SVP
- c'est moi ou vous etes tt les 3 de la mm ecole les gars du Puissance 4 là

Et sans message d'erreur iu de bug report, je regarde pas 156789 lignes de codes mal ecrites et qui compilent pas ttes seules Un peu d'effort jeune homme

Sinon je rajoute l'IUT GEII à ma liste d'ecole ou pas envoyé mes gamins ... on vous a pas appris que les var globales c'etait nazes. La typiquement, c'ets du C-- : pas de classe, cout à la place de printf, mauvais C ...

bien dis.
on peut ajouter le system("cls" ) dans la fonction menu() qui est loin d'etre portable, m'enfin puisque c'est un programme destiné eux environnements compatible MSDOS, ça peut passer.

 
Ayez un peu de respect à l'égard de cet étudiant qui pour une fois à fournit un travail personnel non négligeable et qui aurait besoin de vos lumiere pour l'éclaircir un peu sur son travail    
De plus la bibliothèque de l'iut n'est pas necessaire pour corriger son programme ou lui donner des conseils constructifs .
Je ne peux hélas pas l'aider du fait que je ne m'y connait pas assez en programmation (C++) mais sinon je l'aurai fait volontier.

Certes. Il y a eu tu travail, personne ne le nie.
Mais:
1. Le délai était un peu court.
2. Comme Joel l'a dis la bibliothèque de l'IUT est buggée, donc impossible de sortir une solution testé.
Ou alors, on fait tout de visu; ça peut le faire dans le delai imparti mais ça fait mal à la tête. Autant aider de manière efficace et offrir une vraie solution. Contrairement à ce que tu dis lamedor31 la bibliothèque est nécessaire pour fournir une solution fiable, puisque testée, ou à la limite pour passer son code au débugger ce qui lui apporterai une solution en moins d'une heure, sinon il faut élaguer les appels à la bibliothèque donc perte de temps. Pour être efficace il faut la bibliothèque, nous ne sommes que des être humains, repérer un problème de visu à la vitesse de la lumière sur son code, requiert d'être super bon, pour les autres, une bibliothèque qui fonctionne est mieux. ("fonctionne" = "qui passe la compil" aussi, pas seulement au runtime) De plus une doc sur cette bibliothèque un peu plus accessible aurait été mieux, j'ai un peu galéré avant de la trouver, le site n'est pas très ergonomique (pas conçu pour des externes à l'IUT).  
3. Si en première année, ils n'apprennent pas des principes fondamentaux comme la présentation du code, ou  
- const int == bouffe mémoire (à ce rythme son puissance 4 aura besoin d'un CRAY ou d'un mainframe pour fonctionner)
#define ou type enum pas fait pour les chien
- privilégier les variables locales
- un minimum de concept de portailité
Je plains le prof qui va lire code (à moins qu'il se limite au résultat; eh bien alors c'est du joli)
Je suis désolé mais moi dans ma promo en 1ère année tout le monde était capable (voire imposé) de produire un code de meilleur qualité.
 
 
Bref ça promet quand ils passeront professionnels. Faut dire j'ai déjà du travailler avec des zozo comme ça et bien ça m'a valu l'absorption de plusieurs boites d'aspirine en moins d'une semaine de collaboration sur des projets de 10000 lignes de code (ce qui est moins qu'un noyau minix).
 
Je rejoins donc Joel car on est là pour aider mais cela ne dois pas nous donner de migraine pour autant; même si le travail préalable est bien avancé, autant présenter son travail de manière à faciliter une aide. Ceux qui me disent le problème est facile à résoudre, je leur dirais, "tant mieux pour toi, tu es un génie, mais moi je parle au nom du commun des mortels".
 
Bref s'il suit ces quelques conseils, ça fera de lui un meilleur professionnel. C'est raté pour ce coup-ci; le suivant sera le bon.

      Je suis en iut Génie ÉLECTRIQUE et info indus donc la prog c'est pas mon truc je fini sa et jamais plus j'en ferai. Et c'est moi qui utilise la solution de constante globale. Pas comme tt le monde à mon iut.
JE pense que la programmation soit on comprend tt de suite comment sa marche soit on y trouve que des difficulté moi personnellement l'élec je trouve sa très simple alors que bon nombre de mes camarades trouvent la prog simple et l'élec très dur, chacun son domaine.  
J'avais la solution de prendre un p4 internet changer le cors et voilà mais je préfère le faire de moi même quitte a ne pas y arriver.
Çà m'apporte rien de le prendre d'internet.  
A l'iut ils nous apprennent correctement la prog éviter constante globale...  Mais je suis pas en iut informatique.
Peu programme comme moi. Je ne suis pas doué pour çà.
Enfin je sais que le temps restant et plutôt cour mais je pense que pour boss de la prog sur internet m'aurait sortis de là en quelque minute.

Déja constante globale = mauvaise idée, c'est désastreux surtout dans la programmation des microcontrôleurs qui apparaissent de plus en plus sur des cartes visant à remplacer des cartes analogiques pur surtout dans le domaines des systèmes requérants des composants intelligents car moins cher et plus efficace, le numérique permet souvent de filtrer des bruits parasites que certains systèmes analogiques doivent ajouter.
 
Au lieu de "const int toto= 23;" vaut mieux utiliser "#define toto 23", fonctionnellement ça fait la même chose mais ça évite de bouffer un registre (donc de la mémoire). Vaut mieux reserver la mémoire à ce qui est variable, ce qui est constant ira semblablement en ROM.
 
Tu as tord, la programmation c'est comme tout, ça se travaille, ça s'apprends, si tu crois que certains comprends tout de suite, c'est qu'ils ont des notions, la programmation, c'est un métier, si c'était si simple, il n'y aurait pas des BAC +5 en informatique !!! L'electronique et l'informatique sont simple si on a la matière nécessaire (connaissances) pour résoudre un problème. Ex: les filtres analogiques sont simple à comprendre du moment où l'on comprends comment un condo, une self, et une résistance fonctionnent, si tu connais pas les lois de bases de ces composants alors les filtres c'es dur à comprendre. Essaie aussi de comprendre pourquoi l'informatique est simple à comprendre pour d'autres !! Réponse: ils connaissent simplement mieux l'algorithmique que toi, ainsi ce dont est composé un programme, c'est à dire qu'ils ont des outils et qu'ils essaient juste de ne pas faire rentrer une forme carré dans un trou rond à coup de maillets. L'algorithmique si tu ne sais pas c'est simplement la manière d'utiliser des composants logiciels (variables, constantes, types, structures de controles, etc.) pour résoudre un problème efficacement.
 
En disant que tu n'es pas à l'IUT d'informatique, tu réagis comme celui qui veut ouvrir une boulangerie et qui dis je suis pas comptable, je me fout de la comptabilité, pourtant elle fait partie intégrante de son activité. A l'heure actuelle, tout système électronique (analogique) est relié à un système numérique et donc à de la programmation pour la plupart, même s'il y a un intermédiaire analogique. Tu peux chercher, tu ne trouveras pas de contre exemple. Même les sonos ou les machines à pain ou à café, il y a une puce programmée. Donc même si tu ne veux pas programmer et que tu auras ton poste purement analogique 9 fois 10 ton recruteur vérifiera si tu as des notions d'informatique, même si c'est de la culture. De même ceux qui programme des systèmes embarqués, meme s'ils ne touchent pas ou peu à la partie analogique doivent évidemment connaitre le coté analogique.
 
De plus, tu dis avais la solution d'un P4 sur internet, sache que dans la réalité professionnelle, s'il toutes les solutions informatiques se trouvaient sur le net, il n'y aurait pas de gens dont c'est le métier. Ne pense pas toujours tout trouver sur le net, ou du moins tu risque de trouver des "briques". Je sais que tu n'as pas utilisé la version que t'as trouvé, donc bravo, je te conseille juste que ça devienne un réflexe ou une solution de dernière minute aussi. En effet, tu nous as laissé moin d'une heure pour trouver un problème à ton code, c'est impossible, d'ailleurs tu sais pourquoi c'est impossible en moins d'une heure, car je pense pas que toi tu as passée une heure à concevoir ton bout de code, je parle pas seulement de l'écriture du code mais de la conception, c'est à dire, tu as bien du réfléchir de la manière de faire avant d'écrire le code. Bah sache que même un pro, doit "décoder" ton algorithmique. Les trucs qui se voient en moins d'une heure sont les erreurs de syntaxe, hors tout le monde pense que tu as quand même eu la présence d'esprit de fournir un code qui compile puisque ton message initiale laisse à penser qu'il compile. Donc les erreurs telles de syntaxe, ça oui, ça se résous en moins d'une heure, une erreur d'algo ou fonctionnelle, bah dans la réalité, pour le résoudre en moins d'une heure seul le debugger est efficace, même pour un bon.
 
Pour finir, je vais t'indiquer un truc simple que tu aurais pu faire en moins d'une heure pour résoudre le problème ou qui aurait évité de te bloquer.
 
En elec, je pense que tu sais que certains système meme sur un typon est décomposés en bloc fonctionnels (ex: alim, codeur, multiplexeur, etc...) et donc que tu testes chacun des blocs de manière indépendante, tu leur présente une entrée et tu observes la réponse pour voir si elle entre dans la caractérique.
En informatique, c'est pareil, tu aurais donc pu monter tes blocs fonctionnels un par un en les testants indépendemment au fur et à mesure, de les tester comme tu le ferais en elec. Par exemple, un bloc affichage, un bloc gestion du plateau de jeu, un bloc gestion des coups oués. En plus, une telle décomposition facilite la programmation dite objet que normalement permet le C++ à opposer à la programmation dite procédurale (bref ce que tu as fais), c'est dire programme organisé en appels de procédures (ce sont les fonctions en C/C++). Chaque procédure se doit alors d'exécuter un travail ou un sous-travail. Chaque travaux peut se voir comme un bloc ou un sous-bloc fonctionnel.
 
Pour finir, je te conseille, même si tu n'aimes pas cela, d'avoir des bases en informatique, car sans doute tu y seras confronté dans ta carrière professionnelle. Car dis-toi que même en génie électrique, s'ils te font faire de l'informatique, c'est pas pour t'emmerder, c'est que dans le milieu pro ça se justifie ! C'est pas comme au collège, l'histoire/géo sert vraiment à rien pour ceux qui font de l'electronique.
 
Voilà j'espère cela a pu t'apporter quelques lumières sur certaines fausses idées que tu te faisais.

 
Non c'est pas ça le probleme....
les static const sotn en C++ la manière propre de coder des constantes. Tout compilateur correct les inline. Non ce qui m'embete c'est surtout  
les variables glboales non constantes qui sont anti-objet

Oui j'avais compris.
 
Eh non pas tous les compilateurs, certaines versions des compilateurs C, par exemple, pour les PIC de Microchip (je ne sais plus lesquelles) ne le faisaient pas, on devait obligatoirement utiliser le #define (enfin pas toujours, le const int était préféré au #define), sinon des registres des microntroleurs étaient bouffées. C'était fait exprès car les temps d'accès en ROM programme ou en PROM données ont un temps d'accès était trop long. Le const int était une "constante" à accès rapide en RAM, le compilo générait alors une serie d'initialisation des constantes au boot, et aussi parce que certaine fois les instructions de chargement de valeurs immédiates étaient contraignantes en terme de perf et de longueur de code asm; ce qui rendait proscrit le #define.
 
Maintenant, avec les nouveaux produits, le #define ou le type enum est mieux car portable, de plus les temps d'accès en ROM sont acceptables, et les instructions à valeurs immédiates sont performantes et répandues, de plus les tailles actuelles des ROM programme le permettent aisément.

Bon d'accord, je sais que j'ai mal programmé mais je le rep après j'ai plus rien. DE nos jour un pc a de la mémoire un µp plutôt performent non?
Enfin j'ai réussi a faire tourner mon jeu j'ai supprimer l'idée de faire un grille par le conio.

 
on parle 1/ de C++ au vu de la catégorie 2/ de compiler pour machines normales et pas pic

Et alors? L'un n'empêche pas l'autre.
- Vu le code ça ressemble plus à du C, et puis ce que j'ai dit est valable pour le C++.
- Machine normale? C'est quoi? Pour moi un système embarqué, un palm, un mobile, un PC, pour moi, ce sont toute des machines normales.
- J'ai donnée PIC en exemple, mais cela peut aussi être des motorola, des SPARC ou des ARM.
 
- Il a dit qu'il était en génie électrique, dans ce domaine les "machines normales" sont en général utilisées en outils de développement, et on est plus confronté à des architectures restreintes à quelques composants numériques ou des logiciels proches du hardware tel des drivers et interfaces de commandes ou de pupitrage. D'où mon choix d'exemple pour des microcontroleurs en exemple, pour cibler. Malgré cela, ça vaut aussi pour la prog sur PC.
 
Pour cibler sur la citation; désolé mais dans le code du noyau linux, j'ai pas vu beaucoup de const int, même si c'est la version la plus propre, gcc fout en général les const int dans un segment type BSS (c-à-d un segment de données à part un lecture seule initialisé par une structure interne au binaire exécuté), si on ne met pas le static (static const int), ça bouffe quand meme de la mémoire pour rien. En général, le type enum est préféré quand on le peut.

enum Couleurs
{
   ROUGE=1,
....
};
 
class Jeton
{
   int x,y;
public:
   ...
void  Affiche();
void Affiche( Couleurs Coul );
};
 
class Grille
{
   ...
public:
    void Reinitialise();
    void PlaceJeton( const Jeton &Jet, unsigned int Joueur );
    void TestVertical( ....
   ....
  etc
};
 
Hop hop on refactorise tout ça pour que ça ressemble un peu à de l'objet.

Certes. Ca n'empeche pas de ne pas dire de sottises si jamais ce thread servait à qqun d'autre.
En C oui, define et enum
En C++, non, static const ca suffira vu que cela sera optimisé proprement

les systemes embarqués ont ça "d'anormale" que leur ressources sont tres limité et souvent differente d'une machine à RAM+cache.

Le noyeau linux est tout sauf un exempel sain de bonnes pratiques de programmation.
Une constante static, je le repete n'a pas d'impact sur la taille de l'executable car elle est propagée en place pdt l'optimsiation.

 
C'est marrant je trouve l'enum beaucoup plus objet qu'un tas de static const
En tous cas pour les états d'un même type comme les couleurs l'enum est beaucoup plus élégant.

 
Comment fais-tu quand ta constante n'ets pas un entier ?

C'est sûr.  
Je veux pas mettre des enums dans -tous- les cas, mais il y a quand même pas mal de cas ou c'est parfaitement adapté.
Et le cas présent des couleurs limitées est un cas typique à mettre en enum.
 
Enfin je propose, mais c'était surtout pour montrer à wolfmandu31 la distance de son code vis à vis d'une implémentation déjà plus objet.
 
Le define étant le plus gerbatif pour déclarer un état

oui exactement

effectivement.
 

Si c'est "anormal" alors pourquoi ne pas mettre une carte-mère, un disk dur dans une machine à laver et installer un Windows Vista?
Pour moi, il n'y a rien d'anormal, c'est une solution adaptée à un produit approprié.
Et puis désolé mais même certains systèmes embarqués intègre de la RAM externe avec un cache de niveau 1. Je crois que certains Atmel le permettent. Les ressources sont limités de manière voulu, car les concepteurs ont estimé le besoin en ressources. Une limitation des ressources n'est pas signe d'un manque technologique, mais simplement une solution pour répondre au besoin et souvent pour éviter que le produit aie un prix exorbitant. Tu tourne ça comme si c'était une tare rédhibitoire des systèmes embarqués.

J'essaie juste d'aider en étant au plus proche de ce que la personne connais et du problème.
Je ne vois pas l'intéret de fournir une solution avec des explications s'appuyant autours d'arguments en inadéquations avec ce que connais la personne.
Si cela est une sottise, bah alors une sottise vaut mieux que d'écrire quelque chose qui ne servent à rien.
Pour l'instant, je n'ai pas eu la preuve que ce que j'ai écris était faux ou inapropriés. Je peux juste m'excuser que les raisons en soient incomprises car n'étant pas été suffisemment clair quant à mes motivations, je suis pas ici pour emmerder les gens, je suis là pour aider comme je peux, je ne suis qu'un simple et humble être humain, je ne connais pas tout.
J'ai exposé ici ce que je connais en essayant d'apporter des informations utiles. Mais j'ai eu souvent le retour de gens qui me disais que mes propos étaient inutiles mais bizarement ils n'ont jamais me dire significativement pourquoi. Peut-être est-ce pourquoi c'est récurent.
 

Oui dans ce cas j'admets que c'était pas un bon exemple. Et puis, c'est vrai que du code propre, avec de bonnes manière de coder, est lisible, maintenable, tout ça, et qu'en général un tel code a une performance et une fiabilité acceptable. Ce qui explique effectivement pourquoi, le noyau n'est pas un exemple sain de bonnes pratiques de programmation.
 
 
Et puis pour la constante statique, une constante statique oui mais pas un const int, en voilà la preuve:
Le meme programme compilé avec GCC 4.4.0 (va pas me dire que gcc n'est pas le meilleur compilateur, je trouverai cela de mauvaise foi mais aussi assez vaseux et car là n'est pas le propos)
Donc compilé avec dans le source un "const int" (essai_pas_statique) et après recompilé sans le "const int" (essai_statique). Et compilé avec une optimisation optimale.
Résultat du "ls -l essai_*":
-rwxr-xr-x 1 frederic frederic 33181 Jun 13 00:25 essai_pas_statique
-rwxr-xr-x 1 frederic frederic 33163 Jun 13 00:25 essai_statique
 
Tu vois bien ce coup-ci. Ce n'est pas un problème d'optimisation, mais simplement comme j'ai dis, le compilateur va placer le const int dans un segment de donnée. C'est parfaitement voulu dans ce sens.
 
Sur l'honneur résultats non truqués, vous pouvez essayer; voici le code:

 
Bon pour finir, je n'ai pas eu l'occasion de poster une solution au problème d'origine.
Bon c'est une solution, pas la solution, j'ai fait ça vite fait, donc veuillez excuser mon manque de rigueur par rapport aux règles de la bonne programmation, et des noms pas toujours équivoques, et même le manque total de commentaire.
 
Vous avez le droit de dire c'est de la merde, je m'en fout, ceux qui disent ça ils ont qu'à quitter ce thread.
 
De plus, je n'ai rien repris d'ici. Ce n'est pas vraiment, en soit, une solution, elle ne corrige pas le code d'origine, elle part de zéro avec une interface texte inexistante rappelant les T.P. à l'école.
 
Bref, c'est un truc qui compile sur GCC 4.4.0 et qui fonctionne à priori d'après des tests rapidement effectués. Je dis bien GCC 4.4.0, je ne garanti rien avec le compilateur recommandé ici.

 
J'ai dis ça car je les sens au pif arriver de loin ceux qui par exemple vont me dire tout de suite, "eh pourkoi t'as pas utilisé un singleton?" ou alors "des méthodes statiques n'auraient pas été mieux?" et d'autres encore. En général, à ces gens je leur réponds tiens voilà, fais le. Il y a toujours des chieurs qui occupent leur journée à m'emmerder, donc ils ont de quoi dépenser leur énergie à faire cette modif puisque visiblement ils ont temps de le faire.

Alors c'ets anormal qui est un mot mal choisi. Je veut dire que, comparait à un dev sur architecture cache+mémoire de type x86 ou PPC, le dev sur embarqué à souvent des spécificités qui font que le dev d'applications dessus va te forcer à faire des choses qui ne sont pas des idiomes naturelles sur le reste. Donc remplacons anormal par le mot qui va bien, peut etre exotique e=ou je ne sais quoi.  
 
Y a pas de tare à être embarqué hein. J'ai fait des deux et je sais d'experience que je suis obligé d'ecrire des choses en embarqué pour lesquels j'aurai senvie de me baffer si j'ecrivais les meme en pas embarqué.
 
 

Je disais juste que, en général ici, le lecteur moyen fait pas d'embarquer et que donc, proner la solution correcte qui est "mes constantes glboales sont rangés dans des static const" etait de meilleur aloi que de fournir une répoinse correspondant au corner-case de l'embarqué.
 

C'est pas ce que je disais là ? Les constantes pas static sont obv. rangés quelquepart, y a que les static qui sont inliné.
J'ai du etre pas clair dans mes explications.
 

Sauf que non quoi, c'est juste la manière de faire. Tu as une instance de Jeu et zou.
Le seul reproche que je ferais et que ton modele objet est trop contraint. Jeu devrait prendre les Joueur en argument de son constructeur pour pouvoir permettre d'elargir le champ de la chose facilement (quid si tu veut jouer à puissance 4 à 9 personne par ex.)
 
En general, on essaye de moins contraindre les relations creature-createurs entre obejt de ce type.
 
Dernier details, le buffer de 1024 dans l'exception est assez unsafe. donc soit new/delete sur la vrai taille, soit std::string si ton systeme le permet.

Corebreaker > avant de faire le boulot pour wolfmandu31, fais-toi payer avant

Eh bien oui. C'est clair que à s'en tirer les cheveux la plupart du temps.
Mais moi e trouve ça en quelque sorte naturel car un système embarqué remplis souvent une fonction spécifique (il peut il y en avoir plusieurs quelque fois mais peut-être qu'il s'agit d'un bloc fonctionnel plus imposant). Et donc, il est naturel, mais si on est contraint de le faire, que le code introduise des "exoticités" afin de répondre soit à la fonction exécutée, soit au bon fonctionnement du système qui permet donc indirectement d'exécuter correctement la fonction.
T'as bien du le voir si tu as programmé sur Z80A, 6808 ou même 80x286. Qui ne sont pas des microntroleurs et n'ont pas intégrés au départ des systèmes embarqués.
 

Peut-être tout simplement sytème embarqué ou système non-embarqué (même si ça fait un peu bizarre), ou architecture fixe, architecture distribuée (pour certains), architecture non terminal (sans le sens ou les différentes fonctions sont sur des puces distinctes), voire architecture décentralisée (dans le sens où tout n'est pas traité par l'unité de calcul).
D'autres encore, à vous de choisir.    
J'ai l'impression d'être un rédacteur de la MOA a essayer de chercher des noms à des choses qui peuvent simplement être nommé PC.
 

Je l'admets, surtout sur le PBASIC.
 

Oui c'est certains et je ne rien dire, je suis nouveau sur ce site.  
D'une part je disais juste qu'en général en IUT en génie électrique plus particulièrement il sera sans doute amené à exploiter des systèmes embarqué, ainsi j'ai ciblé, même s'il ne les connais pas encore. Car ainsi, j'espère qu'il se souviendra ce que j'ai écris (ou qu'il le relira) et que ce sera utile le moment venu. Je procède toujours ainsi, et de manière général j'essaie toujours, dans la mesure du possible à fournir un maximum d'informations, et les plus complètes qu'il soit. Et aussi en essayant de ne pas le noyer avec des infos inutiles. Car comme c'est écris et conservé, on n'a pas besoin de mémoriser. Il suffit de reconsulter le thread via un lien.
D'autre part je disais juste que l'utilisation d'un "const int" n'est pas toujours approprié suivant la plateforme d'exécution. Et donc ici dans le cas présent, pour par excemple du ROUGE et JAUNE un enum était plus de coutume. Visiblement, j'ai eu du mal à faire comprendre mes motivations.  
 

Ok. Mais relis le thread, dès le départ je parlais bien des "const int" (pour reprendre le contenu du source originel) et au départ tu allais dans ce sens sans préciser le "static" qui fais une énorme différence. J'avoue, tout mes excuses, en fait, j'avais compris et je me suis un peu amusé avec toi, c'était méchant et je m'en excuse (les enfants, ne refaites pas ça à la maison   ).
 

Ben oui, voulu ou pas voulu, tout a été vite fait, et en général dans la vitesse je perd souvent de bon reflexes. Mais bon, ça bon à signaler oui pour les autres lecteurs.
 
Pour le buffer unsafe, c'est une sale habitude que j'ai choppé justement à cause de programmation reflexe attrapé pour le dev sur systèmes embarqués ou processeurs basiques tel le Z80.
Je fais ça dans la limite où par exemple ici, je sais que l'utilisateur du programme ne peut pas exploser le buffer et produire un segmentation fault. Une erreur ne peut venir si un autre développeur sous-classe Mon_Exception avec un message de plus de 1023 octets.
Donc je ne suis pas sympa envers les dev, c clair, mais il reste fiable au runtime au nivo des exceptions. C'est le résultat d'un "programmé vite fait". J'aurais pu le rendre safe aussi en utilisant stncpy dans le constructeur, solution oui même si elle n'est pas satisfaisante du fait qu'elle tronque le message. Et puis sinon il y a solution d'aggrandir la taille   sans que ça resolve le coté unsafe, on suppose qu'un message "statique" (message fixe seul présent dans le source et non modifié) ne dépasseras pas les 1023 octets sinon ça commence à alourdir le source et le binaire. (arguments vaseux qui tend juste à rester dans la facilité)

 
Je l'ai déjà fait mais jamais sur des sites comme celui ci. Si e dois me faire payer je sais où chercher.