using un_nom_pertinent = std::vector<float> ;
using un_autre_nom_pertinent = std::vector<un_nom_pertinent> ;
using un_dernier_nom = std::vector<un_autre_nom_pertinent> ;
// (voir même de nouvelles structures selon les besoins)
un_dernier_nom machin ;
Plutot que faire des alias de types, tu peux meme (surtout) creer des classes pour chaque niveau, en lui donnant une semantique claire et des contrats précis. (Layer, Neurone, Connection)
"les 'for' sont des 'if' !" ça m'éclaire sur pas mal de messages mais je ne vois pas comment je peux parcourir un vecteur à trois dimension sans ces boucles. Et puis dans ce cas il n'y a pas 2 chemins je pense c'est le même chemin emprunté un certain nombre de fois (même si c'est peut-être très mal dit)
les boucles, quelles quelle soient, effectuent d'office un test...
C'est un test du genre de
si (la condition d'entrée dans la boucle est vérifiée)
je reprend au début de la boucle
sinon
je vais à la première instruction qui suit
je renote les problèmes pour faire le point:
A: les typedef c'est mal --> comment je m'en défait ?
B: les if (et donc les boucles imbriquées) c'est mal --> comment je parcours ce vecteur 3d sans ?
C:conio.h c'est mal --> j'ai un getch dans mes menus, y a-t-il une alternative ?
A: Quand tu écrit du code C++, tu ne mets simplement pas de typedef... le code
struct Machin{
/* les différentes données membres */
};
déclare déjà le nom Machin comme étant un type de donnée (du moins, en C++). Il n'y a donc aucune raison de vouloir définir une type de donnée à la C, qui prend une forme proche de
typedef struct{
/* les différentes données
} Machin; // voici le nom, qui arrive APRES la définition
// de la struture
B: Tu as plusieurs solutions.
La "plus efficace" est de partir du principe que
Chaque nom (groupe nominal) dans ton analyse des besoins doit être représenté sous la forme d'une donnée ou d'un type de donnée dans ton code
Chaque verbe (groupe verbal) dans ton analyse des besoins doit être représenté sous la forme d'une fonction dans ton code
Et de rajouter un soupçon d'encapsulation dans l'histoire, car chaque type de donnée devrait être considéré comme un fournisseur de services:
Un neurone, par exemple, cela peut obéir à "certains ordres", et cela peut répondre à "certaines questions",et le cerveau peut obéir aux ordres "crée plus de neurones", "crée une liaison entre tel neurone à tel autre" et "évalue telle liaison".
Grâce à cela, tu obtiendras des "notions élémentaires", qui veilleront à ne s'occuper que d'une seule chose bien particulière. Et, du coup, les trois dimensions de ton tableau devraient être "réparties" dans les différentes notions que tu auras créées.
Et les services rendus par ces différentes notions pourront se contenter de boucler sur une des dimensions de ton tableau, quitte à faire appel à "une fonction particulière" d'une autre notion pour ... boucler sur les autres dimensions de ton tableau.
L'autre solution consiste à "linéariser" tes tableaux à dimensions multiples, mais elle ne peut être envisagée que quand on a affaire à des "matrice pleines" .
En gros, il s'agit de se dire que, si on a une matrice à N dimensions, que la première dimension doit contenir X élément, que la deuxième doit en contenir Y , que la troisème doit en contenir Z et que la Nieme doit en contenir Y' (sous entendu: nous connaissons exactement le nombre d'éléments que nous trouverons dans chacune des dimensions), notre but est en fait de pouvoir représenter un nombre d'éléments correspondant à X*Y*Z...*Z' et donc de créer, non pas un tableau à N dimensions, mais bel et bien un tableau à une seule dimension, qui contient l'ensemble des éléments auxquels nous voulons avoir accès.
Après, il y a le problème de l'accès aux éléments. Pour cela, on utilise une formule "relativement simple" qui, pour deux dimensions, revient à indice_de_l_element_rechreche = ligne * NOMBRE_COLONNE + colonne.
pour trois dimensions, cela revient donc à quelque chose comme indice_de_l_element_recherche = ((X * NOMBRE_EN_Y)+Y)*NOMBRE_EN_Z + Z.
ATTENTION : la linéarisation semble impossible dans ton cas, je n'en ai parlé que par soucis d'être complet
C: tu veux extraire un caractère de l'entrée standard. Que penserais tu de
char choice;
std::cin>>choice;
/* la suite */
Je fais volontairement simple ici
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
cependant goût personnel je préfère mes vieux for imbriqués
C'est pas une histoire de goûts personnels. Statistiquement, les développeurs font plus d'erreurs quand les fonctions sont plus longues. D'autant plus quand on imbrique des boucles. Donc si on veut faire moins d'erreurs, on fait du code moins compliqué.
Après, on peut quand même se pencher sur ton code. Qu'est ce que tu penses de :
Ce code de chargement fait la même chose que le tien, en revanche, il évite de manipuler des références et de faire des effets de bord qui rendent le code plus compliqué à comprendre.
(Note : dans l'espace de nom global, ne nomme pas des éléments de ton programme avec un "_" en préfixe, c'est réservé aux compilos/bibliothèques standard).
D'habitude on encourage à faire des recherches pour aboutir aux fonctionnalités désirées, mais le je croit qu'une intervention devient nécessaire: L'équivalent de getch() est std::cin.get();
PS: S'il s'agit de faire une pause en fin de programme pour éviter que la console ne se ferme, revoit la configuration ton IDE.
Hum non. std::cin nécessite que le flux d'entrée soit "validé" par l'utilisateur. La fonction getch attend juste un appui sur la touche pour la renvoyer. Cela dit, comme je l'ai dit, voir du côté de ncurses et équivalents.
× 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
Architecte logiciel - Software craftsmanship convaincu.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Discord NaN. Mon site.
Discord NaN. Mon site.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C