Journal un peu de pub !

Posté par  .
Étiquettes : aucune
0
14
sept.
2003
Salut mon bon journal.

Je sais pas, si j'ai le droit, si je fais bien ou pas mais bon, je me lance quand même:

Voila, j'écris depuis quelques temps déjà un programme de jeu d'échec en C. Je voudrai votre avis sur le programme ( dans l'état actuel du développement !) et sur le site qui va avec.

voila l'adresse : www.linechec.tuxfamily.org

Je vous en prie, ne me tapez pas sur la tête si j'ai pas le droit de faire cette pub !
  • # Re: un peu de pub !

    Posté par  (site web personnel) . Évalué à 2.

    Et les screenshots ?

    L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

  • # Re: un peu de pub !

    Posté par  (Mastodon) . Évalué à 1.

    http://www.linechec.tuxfamily.org/telechargement.php(...)
    j'ai un petit soucis sous firebird 0.6.1, du texte dépasse du cadre vert ? c normal ?
    et lorsque je compile :
    In file included from main.cc:27:
    echecs_arbre_k_aire.cc:4:33: echecs_arbre_k_aire.h: No such file or directory

    voilou
  • # Re: un peu de pub !

    Posté par  (Mastodon) . Évalué à 10.

    Je viens de tester, ça marche bien, même si cela ne permet que de jouer à deux. Si tu as besoin d'une source d'inspiration, tu peux regarder du côté du logiciel eboard (je pense surtout pour la récupération de ses très jolis thèmes :-)

    Une question: pourquoi nommes-tu tes fichiers .cc au lieu de .c ? (Aucune importance, mais la convention c'est .c pour le C, et je crois .cc pour le C++)

    Sinon, quelques remarques sur le code: c'est assez violent de faire un include de tous tes fichiers dans main.cc. Ça t'oblige à compiler l'intégralité du code à chaque fois, même si tu n'as changé qu'un seul fichier.

    La bonne méthode, c'est de compiler chaque fichier séparément, avec quelque chose comme:

    gcc -c lefichier.c

    Ce qui te donne un fichier "lefichier.o".

    Une fois que tu as tous tes fichiers .o, tu peux les réunir ensemble en faisant

    gcc *.o -o nom_programme

    Comme ça, si tu ne changes qu'un seul fichier, tu n'as besoin de recompiler que ce fichier.

    C'est l'intérêt d'un Makefile, car il faiit toutes ces opérations tout seul. Un exemple de makefile:

    CC=gcc
    CFLAGS = -g -Wall `gtk-config --cflags`
    LDFLAGS = `gtk-config --libs`
    FILES=fichier1.o fichier2.o ...

    .c.o:
        $(CC) $(CFLAGS) -c $<

    all: $(FILES)
        $(CC) $(LDFLAGS) $(FILES) -o nom_du_programme

    clean:
        rm -f *.o nom_du_programme *core*

    Explication:
    CFLAGS, c'est les paramètres de compilation, LDFLAGS les paramètres de liaison (deux étapes séparées). `gtk-config blabla`, ça donne les paramètres nécessaires pour compiler avec GTK, ceux que tu places dans tes variables $(GTK) et $(GLIB). C'est mieux d'utiliser gtk-config, car c'est indépendant de la machine sur laquelle on compile.

    La règle .c.o, ça dit à Make que à chaque fois qu'il veut un fichier.o, il doit regarder si le fichier.c est plus récent. Si oui, il doit faire les actions précisées. Le parmaètre -c dit à gcc de compiler, sans lier.

    La règle all dépend de la liste de tes fichiers (dans $(FILE)), car ils doivent tous être compilés avant de faire la liaison.
    • [^] # Re: un peu de pub !

      Posté par  . Évalué à 1.

      Merci pour tous vos commentaires.

      Pour l'histoire du echecs_arbre_kaire.cc, effectivement c'est un pb. Je le rectifie de ce pas.

      Pour le pb d'affichage sur le site, je débute dans la programmation html, CSS et php. J'ai quelques soucis pour contenir les textes dans des blocs. Mais je ne désespère pas...

      Pour Yusei :

      Je nomme mes fichiers .cc parce que j'ai une erreur de compilation avec les déclarations de macros dans echecs_var.h !!! Mais je suis d'accord avec, c'est pas trés correcte. L'déal voudrait ".c".

      Quand à séparer la compilation de chaque fichier, j'ai essayé mais 'arrive toujours pas à le faire. En fait, j'ai un fichier commun de déclaration de variable echecs_var.h que je dois intégrer à toutes les sources.

      J'arrive donc à compiler chaque source séparement, mais lorsque je compile le fichier main.cc e utilisant les .o précédement compilés, gcc me dit que toutes les déclarations de echecs_var.h sont déja initialisées. Je ne comprends pas ?

      Pour ton Makefiles, j'en prends bonne note et vais un peu modifier le mien histoire de le faire progresser.

      Pour finir, pour les screenshots, ca se résume à une seule image que l'on peut trouver www.linechecs.tuxfamily.org/previsualisation.php .
      Je sais, limage est de priêtre qualité, mais ca évite un chargement trop long. Le principe des vignettes pour une seule image ne m'a pas paru opportun.
      • [^] # Re: un peu de pub !

        Posté par  (Mastodon) . Évalué à 2.

        «lorsque je compile le fichier main.cc e utilisant les .o précédement compilés, gcc me dit que toutes les déclarations de echecs_var.h sont déja initialisées. Je ne comprends pas»

        En fait tu ne dois pas déclarer de variables dans un .h qui doit être inclus dans plusieurs fichiers, en principe. Normalement, tu déclares ta variable dans un fichier (comme main.c):

        int toto;

        Et dans ton .h, tu indiques à tous les fichiers qu'il existe une variable toto déjà déclarée:

        extern int toto;

        Ainsi, elle n'est déclarée qu'une fois mais peut être utilisée dans tous les fichiers.
        • [^] # Re: un peu de pub !

          Posté par  . Évalué à 1.

          Merci pour l'info. Je vais faire quelques essais sur ce principe. Encore merci.
        • [^] # variables globales & code

          Posté par  . Évalué à 2.

          De plus, il est en general déconseillé d'utiliser des variables globales :)

          tu n'en n'as pas beaucoup pour l'instant, profites-en des maintenant pour y penser. D'un autre coté vu qu'en définitive tout est inclu dans main.c ... ;)

          Tu pourrais peut-etre creer une structure contenant l'ensemble du jeu, au lieu d'avoir des variables dispersées (le tableau de jeu, le numero de coup) que tu passerai en parametre à toutes les fonctions. Ca rallonge un peu l'ecriture de certaines variables, mais je pense qu'un jour ca te sera utile...

          Pense à utiliser des enum{} à la place de tes #defines pour les types de pieces etc. Le compilateur pourra ainsi te signaler des erreurs de type, et les sessions gdb seront + lisibles.

          J'ai pas trop lu le code pour l'instant, mais j'ai une remarque de "coding style" (Holy War Alert) : rajoute des espaces autour des operateurs, virgules et parentheses !! Il y a des sections de code tres dense, et assez dure à lire.

          Question qui me hante: le tableau de jeu est unidimensionnel, et du coup tu utilise des horreurs (désolé) du style if (echiquier[piece.place+25].type_piece!=bord . Est-ce que c'est fait expres ? Dans un numero de Login sur les echecs ils parlaient du stockage lineaire pour optimiser certains trucs, est-ce le cas ? Si oui, utilise au moins des constantes du style HAUT=12 BAS=-12 DROITE=1 et ecris (place+2*HAUT+DROITE) pour qu'un s'y retrouve; sinon, utilise un tableau bidimensionnel !

          De meme dans echecs_init, tu as le droit d'utiliser 2 boucles imbriquées pour faire tes initialisations en x ET en y ;)
        • [^] # Re: un peu de pub !

          Posté par  . Évalué à 1.

          En fait tu ne dois pas déclarer de variables dans un .h qui doit être inclus dans plusieurs fichiers, en principe. Normalement, tu déclares ta variable dans un fichier (comme main.c):

          En fait il y a quand même des cas où ça peut servir, Il est alors possible de s'en sortir en utilisant le préprocesseur.

          Si tu a un fichier titi.h que tu peux avoir à inclure plusieurs fois,
          la solution:

          #ifndef TITI_H
          #define TITI_H 1

          int toto;

          etc ...

          #endif

          A la première inclusion, la macro TITI_H est définie à 1 et le fichier ne sera plus inclu ensuite.

          Je sais pas si c'est barbare, moche ... en tout cas je trouve ça propre et ça marche.
          • [^] # Re: un peu de pub !

            Posté par  . Évalué à 1.

            C'est effectivement la méthode que j'ai employée mais elle n'est pas suffisante. Lorsque le compilateur crée un .o, il le fait ( d'aprés ce que je comprends ) de façon à ce que le .o soit indépendant. Ainsi, il est possible de réutiliser cette librairie ailleurs.

            Donc, à chaque fois que le gcc compile un .o, il intègre à ce .o les déclarations des variables, même si un #if !defined(TOTO) est inscrit, puisque pour chaque .o, TOTO n'est jamais défini.

            Je ne suis pas sûr d'être trés clair, et je ne suis même pas sûr du principe, mais c'est ce que j'ai pu en comprendre à force de m'arracher les cheveux avec.

            D'autres confirmerons ou non...
            • [^] # Re: un peu de pub !

              Posté par  . Évalué à 1.

              en fait tu peux faire des variables comme ca dans tes headers, mais il ne faut surtout pas les initialiser, sinon effectivement ca compile pas du tt
            • [^] # Re: un peu de pub !

              Posté par  . Évalué à 1.

              Hum, il faut que tu utilises l'option -c de gcc pour compiler tes .o, il évite de lancer le linker comme ça. Tirer de la page man de gcc:

              When you invoke GCC, it normally does preprocessing, compilation, assembly and linking. The ``overall options'' allow you to stop this process at any intermediate stage. For example, the -c option says not to run the linker. Then the output consists of object files output by the assembler.


              Dans ce cas la liaison n'est faite que quand tu compiles le programme final.

              Pour créer tes objets tu as donc des lignes du style:

              gcc -c -o toto.o toto.c

              Puis tu créé ton executable

              gcc -o monprog toto.o tata.o tutu.o ...

              Ca devrait marcher comme ça.

              Si dans ton Makefile tu mets des entrées du style:

              toto.o: toto.c
              tata.o: tata.c

              c'est ce qui est fait automatiquement.

              Par ailleurs je suis aller farfouiller dans /usr/include et cette technique à l'air très employée dans la bibliothèque C standard de GNU, donc je pense que c'est une bonne méthode :)
    • [^] # Re: un peu de pub !

      Posté par  . Évalué à 1.

      Rahalalala j'ai passé une soirée à comprendre comment marchait un Makefile, g lu plein de tutoriaux contradictoires, avec soit trop d'info soit pas assez, on m'a donné pelin de conseils confus et incompréhesibles. Et là paf ! en 10 lignes g tout compris, merci.
  • # Re: un peu de pub !

    Posté par  . Évalué à 1.

    argg une balise blink !!

    en + ton logo "valid html 4.0.1" est mensonger :-(
    http://validator.w3.org/check?uri=http%3A%2F%2Fwww.linechec.tuxfami(...)
    • [^] # Re: un peu de pub !

      Posté par  . Évalué à 1.

      C'est vrai. Je le reconnais. J'avais fait le contrôle sur cette page mais en locale, et il y a longtemps.

      Toutes mes excuses.

      Je vais refaire la demande pour être en concordance avec la norme.
      • [^] # Re: un peu de pub !

        Posté par  . Évalué à 1.

        Bon voila, j'ai passé mon site à la moulinette et maintenant il respecte la norme 4.01 transitional je précise.

        Quand au soft, j'ai réussi à créer des fichiers objets de tous mes modules et ensuite de tous les lier pour créer l'application avec un Makefiles inspiré d'un post un peu plus haut. Mais voila, avant mon application faisait 100 ko, maintenant, elle fait 1,3 Mo pour le même résultat ?

        Pour l'instant, je n'ai pas recréer d'archive, vous ne les trouverez donc pas sur le site. Je le réserve pour la prochaine mise à jour.

        Enfin bref, c'est pas grave, je suis arrivé à créer des modules, c'était là l'essentiel.

        Encore merci à tous pour votre aide et vos critiques constructives qui m'ont permis d'en apprendre encore un peu plus.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.