Version imprimable
la typographie sur ce code est très mauvaise, je l'es reprit en cours puisqu'on est plusieurs à travailler dessus, j'ai suivit la "convention" qu'ils ont prit pour finir le code puis je comptait renommer toute les variable, fonction etc. en suivant une convention mais je n'ai pas eu le temps ^^ même moi je me perd dans la façon de nommer les variable/fonction etc.
C'est tentant bien sûr. Ainsi on n'est plus obligés de se coltiner 2 paramètres chaque fois qu'on veut transmettre le tableau à une fonction qui doit le traiter.Citation:
Envoyé par gerald3d
Malheureusement cette technique ne peut pas s'appliquer à un tableau d'ints dans lequel toutes les valeurs sont utilisables et donc où aucune d'elle ne peut servir de flag.
Ce souci s'est aussi posé pour la fonction fgetc() qui récupère un caractère d'un flux et le renvoie à l'appelant. Le souci c'est qu'il fallait trouver une valeur spéciale signifiant "j'ai tout lu" or aucun caractère ne pouvait convenir puisque l'appelant n'a aucun moyen, s'il avait reçu ce caractère, de distinguer s'il provenait du flux ou bien si c'était le signal "EOF".
La solution trouvée a été astucieuse: la fonction renvoie un int et non pas un caractère. Ainsi, quand elle lit le flux elle renvoie les caractères lus (convertis en int lors du cast implicite que l'appelant peut reconvertir sans perte). Mais quand la fonction doit indiquer "EOF" là elle renvoie l'int 0xFFFF qui se distingue aisément du caractère 0xFF (0x00FF quand il est casté en int).
Malheureusement cette solution ne peut pas s'adapter quand on a déjà des int comme ici (j'ai essayé d'imaginer un truc équivalent avec un tableau contenant des doubles mais c'est pas super aisé à manipuler).
Reste une solution que tu n'as pas évoquée: la structure. Après tout, c'est son rôle que de permettre le regroupement d'éléments. Ainsi en créant une structure contenant le tableau d'un côté et sa taille de l'autre, on se simplifie ensuite la vie quand on veut transférer son tableau à une fonction qui doit le parcourir... ;)
Et tu as raison, c'est important. Ne serait-ce que pour s'éviter lassitude et fatigue. N'oublie pas qu'il existe nombre outils pour t'assister sur ce problème : clang-format, indent..Citation:
Envoyé par LittleTatsumi
Conseil habituel (je m'auto-cite car ça revient tout le temps) :
Je sais que les fins de projet peuvent être intenses mais ce n'est pas une raison pour oublier la méthode.Citation:
Envoyé par Matt_Houston
Un bon programme, c'est une collection de modules qui échangent en fonction d'un contrat. N'ajoutez pas des fonctionnalités en vrac comme des cuillerées de sauce au dernier moment sur un plat de spaghetti. Divisez le problème, dispatchez les responsabilités, parlez-vous.
Définissez clairement les pré- et post-conditions de chaque sous-tâche. Codez générique : trier des pommes et des oranges par exemple, c'est strictement la même procédure, il n'y a que le comparateur qui change. Assurez-vous bien qu'une implémentation fonctionne avant de l'intégrer au reste : c'est pas la peine d'essayer de trier des Disk si ça part déjà en sucette avec des int. Écrivez des fonctions de test, voire des programmes indépendants.
Avec un minimum de rigueur vous aurez bouclé avant les autres et si ça se trouve à 17 heures vous serez déjà en terrasse à penser à autre chose.