Bonjour à tous, les questions:--
1)- Switch case et son "case" acceptent-ils ce genre de chose:
Switch case a
case a==x or a==y or a==z
Si oui, un petit exemple pour la syntaxe
et celui là:
Switch case a, b, c
case a==x
case b==y
2)- Soit un programme:
-) Boucle de lecture d'entrée données.
Test_1
vers fonction_1
Test_2
Test_3
-) Fin boucle lecture données
//----------
fonction_1(){
test_A
vers fonction_A
test_B
test_C
Y'a t-il un moyen de le renvoyer directement dans la boucle de lecture quand il a fini la fonction_A; sachant que je ne peux pas "toucher" à la boucle de lecture (comme par ex: en faire une fonction) ?
Il me faudrait en fait pouvoir y placer une "étiquette" que je pourrais atteindre depuis n'importe quel endroit du prog.
Merci pour la (les) réponses. Et les ch'tits exemples
- non ce n'est pas possible sous cette forme. Par contre tu peux l'écrire comme ça:
switch(a){
case x:
case y:
case z:
ton_traitement ;
break;
case w:
autre_traitement;
break;
default:
traitement_default;
}
Il va sans dire que x, y, z et w sont des constantes. Les case d'un switch doivent être connus au moment de la compilation.
- Oublie les goto et les labels. Il y a toujours moyen de s'en passer. C'est souvent la conséquence d'un mauvais découpage du code.
Maintenant il y a plusieurs solutions à ton problème.
On peut toujours sortir d'une fonction de contrôle de flux par un break.
break permet de quitter les boucles for, switch, do, while. Le break renvoie à la ligne qui suit l'accolade fermante du bloc.
On peut jouer avec les if... else...
En dernier ressort pour quitter une fonction on peut toujours utiliser return même si ce n'est pas très élégant, ni très recommandé d'avoir plusieurs points de sortie dans une fonction.
Le problème, c'est que j'ai une manade de tests à la suite; chacun envoie à une fonction différente.
En admettant que le 2ème test soit positif, il va à la fonction. Mais quand il aura fini la fonction, il va revenir tester tous les autres if's qui suivent. Et ça va me bouffer du temps.
Il faudrait qu'il retourne directement dans la boucle de lecture d'entrée. (quand même les goto et leur labels c'était bien pratique.)
Dans les "case" je peux mettre une valeur en "dur" (ex: 24; non déclarée)
Avec switch case, quand il a trouvé le bon "case", il reviens tester les autres ou pas ?
Carolyne:
Le problème, c'est que j'ai une manade de tests à la suite; chacun envoie à une fonction différente.
En admettant que le 2ème test soit positif, il va à la fonction. Mais quand il aura fini la fonction, il va revenir tester tous les autres if's qui suivent. Et ça va me bouffer du temps.
Les if... else if... else ... c'est pas fait pour les chiens et dans ce cas on ne passe que dans un seul.
Carolyne:
Il faudrait qu'il retourne directement dans la boucle de lecture d'entrée. (quand même les goto et leur labels c'était bien pratique.)
Je t'assure, il y a un moyen de découper ton code pour ne pas avoir à faire ce genre de gymnastique. Tu en arrives là parce que tu raisonnes avec des goto. Rayes-les de ton esprit.
Carolyne:
Dans les "case" je peux mettre une valeur en "dur" (ex: 24; non déclarée)
Avec switch case, quand il a trouvé le bon "case", il reviens tester les autres ou pas ?
Dans le case, il ne doit y avoir que des valeurs en dur c'est ce que j'ai dit dans ma réponse précédente. La valeur du case doit être constante et définie au moment de la compilation car le compilateur calcule la table de saut.
Toute cette cuisine, c'est toujours pour ton "affichage MIDI"?
Et le paquet de tests c'est pour tester les notes?
Il y a peut être un moyen un peu moins "boeuf" de traiter la chose. Les floppées de if c'est souvent la conséquence d'une analyse trop rapide ou trop simpliste des données. Il y a souvent des voies de simplifications aux chaînes de if en cherchant des patterns ou des règles dans l'organisation des données qui simplifient les tests.
Les floppées de if c'est souvent la conséquence d'une analyse trop rapide ou trop simpliste des données.
Et ben ouais, c'est le premier jet. Il faut que le prog tourne bien avant que je tente de le raproprir. Je ne maîtrise pas assez le "C" pour coder directement avec des "compressions" et des astuces style: B@tto (entre autres).
On fait ce qu'on peut...On est pas des boeuuuufs. :~
Hello,
Bien au contraire, si tu apprenais d'abord les bases de la programmation et de l'algorithmique, tu perdrais moins de temps : ici, tu vas torcher un truc imbuvable qui va peut-être fonctionner, mais que tu devras jeter à la poubelle car il sera inmaintenable : toute mise à jour va tirer à gauche et à droite, ça deviendra un spaghetti.
Comme dit par les autres : les goto, c'est pour des cas très très précis, mais le résultat d'une optimisation ultime. Pas dans un algorithme de base.
Jouer avec du MIDI au bas niveau, c'est pas du plus simple, car tu devras programmer l'équivalent d'une machine à état (running status, mémorisation des note on, ...). Donc prends le temps de potasser, foncer tête baissée n'apportera que frustration et échec.
foncer tête baissée n'apportera que frustration et échec.
Pas d'inquiétude là-dessus; j'ai l'habitude des plantages monumentaux, débuggages de folie et remaniements complets.
J'ai besoin que le prog tourne pour avancer sur le "hard" ,raccordements coffret/rampe (36 fils pour l'instant), tant pis si c'est "bourriné" côté code. J'y reviendrai plus tard (ou pas :P).
PS: J'ai voulu acheter un coffret tout fait. Je suis tombée sur un coffret magique:
Au magasin c'était un coffret XD, et quand je l'ai ouvert chez moi, et ben....C'était une M****de :0.
Carolyne:
Les floppées de if c'est souvent la conséquence d'une analyse trop rapide ou trop simpliste des données.
Et ben ouais, c'est le premier jet. Il faut que le prog tourne bien avant que je tente de le raproprir. Je ne maîtrise pas assez le "C" pour coder directement avec des "compressions" et des astuces style: B@tto (entre autres).
On fait ce qu'on peut...On est pas des boeuuuufs. :~
Je pense que tu es victime d'une idée reçue. Pour faire un programme propre il n'est pas indispensable de bien connaitre le langage dans lequel le programme sera écrit.
L'algorithme est indépendant du langage. C'est juste une "recette" pour résoudre un problème dans un contexte donnée. La "recette" peut être compliqué ou simple. C'est à toi de trouver cette recette et de la simplifier pour qu'ensuite elle soit facile à coder.
C'est un travail à faire en amont.
Je t'en ai donné un exemple il y a peu sur le traitement des codes des notes en MIDI.
http://forum.arduino.cc/index.php?topic=207859.msg1530347#msg1530347
Pour identifier les notes tu peux soit faire 128 tests (puisqu'il y a 128 notes possibles) soit remarquer que comme les notes vont de 12 en 12, si tu divises le code de la note par 12 tu as l'octave et que le reste de la division te donnes la note. Tu vois cette réflexion fait complètement abstraction du langage de programmation et tu te dis qu'une malheureuse division cela ira surement plus vite que 128 tests et ce sera plus facile à tester aussi.
C'est seulement lorsque tu vas passer de l'algorithme au codage que ta connaissance plus ou moins bonne du langage de programmation va faire la différence. Mais là, pour le coup ce sera plus facile de l'optimiser ultérieurement. Par exemple tu peux très bien coder l'algo sans savoir que l'opérateur modulo existe en C. Cela te fera un peu plus de calculs mais l'ensemble fonctionnera bien. Un jour tu découvriras le modulo et tu reprendra ton code pour le simplifier.
Je sais bien ce que tu dit. Mais c'est la théorie.
En pratique: Quand je commence par faire l'algorithme, les idées ;réalisables et non-réalisables; viennent au fur et à mesure; et je finis par obtenir une usine à gaz algorithmique dans laquelle je fini par me perdre. En plus, ça consomme un papier de diiingue, et faire un organigramme à l'ordi, j'ai essayé; c'est impossible (écran < 1m^2).
En avançant avec un code même complètement pourri, mais qui marche, je suis avec du "solide".
Je sais bien qu'il ne faut pas faire comme ça. Je le sais ..Snif! et re-Snif! =(
Mais y'a que comme ça que j'y arrive. Un jour peut-être....Je ferai des beaux algorithmes, bien pensés. Pour l'instant, je patapouille dans le bac à sable.
Arheu...Agheu... Pâté..joli pâté...Arheu.... 
Cherchez pas docteur...C'est la tête. 
Mais t'inquiète, ton histoire de division et de modulo, elle est pas tombée dans l'oreille d'une sourde.
Essaie d'écrire d'abord sur papier des opérations à faire, que tu relies avec des lignes (un diagramme, en sorte).
Puis "exécute" ce diagramme avec quelques valeurs pour voir si ça tient la route, puis code cela.
Sans analyse, tu vas foncer la tête dans l'eau, arriver à un résultat, mais qui sera beaucoup plus alambiqué que si tu avais un peu de recul.
On pourra pas dire qu'on a pas essayé de la convertir
fdufnews:
On pourra pas dire qu'on a pas essayé de la convertir
A mon avis c'est pas un cast qui faut ici, mais plutôt un flash complet 
je rajouterai une chose,
toujours prévoir son code au départ afin d'avoir une porte pour ajouter des fonctions par la suite sans tout reprogrammer ni faire du triturage de méninges.
ce qui revient a confirmer ce qui est dit au dessus.
mieux vaut passer plus de temps a organiser son programme au départ sur une feuille que de le passer a debugger en double ou triple de temps par la suite.
toujours prévoir son code au départ
T'es bien toi... Faudrait déjà que je sache ce que je veux faire de "A" à "Z".
Le problème, c'est qu'au fur et à mesure que j'avance, y'a la fin qui recule. 
Y'a bien un moment où il faut commencer de coder. Sinon, le "projet"; et ben il reste: "En projet".
A pas peur...Je ne posterai pas 500 ligne avec la question: Cherchez l'erreur. 8)
Juste des ch'tites questiounettes. 
Commence déjà par écrire ce à quoi tu pense même si c'est incomplet.
Rien que le fait d'écrire oblige à approfondir : ce qui paraissait évident dans la tête devient tout d'un coup obscur dès qu'on veut le coucher sur le papier ou on s’aperçoit qu'on n'a même pas vu 10 % des cas possibles.
Cela te parait difficile mais tu verra qu'avec l'habitude cela deviendra beaucoup plus aisé, il faut juste accepter de commencer.
Également un projet se mûri. Rappelles-toi du vieil adage : "Souvent sur le métier remet ton ouvrage".
Il faut partir avec l'idée qu'on est pas un génie et réexaminer régulièrement ce que l'on a fait ou décidé.
Ce qui paraissait génial à 22h peut changer de statut le lendemain matin en devenant irréalisable ou inutile.
Le maître mot "Patience" avant de se jeter dans le code, dans le câblage ou les commandes de matériel parce que le principe est universel.
c'est ce qu'on appelle faire un cahier des charges.
comme le dit 68tjs, une idée super la veille pourra devenir idiote le landemain.
quand tu dis que ca consomme du papier, MDR, tu as le pc pour mettre noir sur blanc tes idées.
certains vont sauter au plafond, mais je compare un code pour nono à un site internet.
mieux vaut coucher sur le papier ou pc les idées, faire des modules qui vont s'imbriquer par la suite.
après tu as juste les menus a modifier pour ajouter tes modules.
je dis pas que je mets sur le papier mes idées lorsque je code 
mais au moins les grandes lignes pour du complexe.
je fais mes modules, les teste et après je les imbrique un par un en regardant si une fonction ne pourrait pas servir pour une autre et ainsi gagner du temps et de la mémoire dans le nono et le faire bosser au maximum de sa vitesse en l'économisant aussi niveau calcul.
infobarquee:
mieux vaut coucher sur le papier ...
Le vieil adage :
Un problème bien posé est un problème à moitié résolu
s'applique autant à la petite sphere de l'arduino qu'aux autres domaines de la vie
Artouste:
infobarquee:
mieux vaut coucher sur le papier ...Le vieil adage :
Et il n'y a pas que les Arduino qui couchent pour réussir XD
ca sent le vécu fdufnews
=> []
Y'a pas...Vous êtes de bons conseils.
Vous me faites ch***er Je vais le faire ce p****n d'algo sur papier.
En pseudo code; parce qu'avec les carrés et les triangles, à la fin, y'a des fils qui se croisent dans tous les sens et on y comprends plus rien.
J'espére que ça va correspondre à ce que j'ai dans la tête.
Sinon, j'ai plus qu'à me trouver une tête qui va bien avec l'algo. :~