goto et Objective-C
Philippe49
Membre
Quelqu'un a déjà rencontré des problèmes avec le goto en Objective-C ?
if(condition) goto LABEL;
.....
LABEL:
char ** cStrings
.....
J'ai un projet C qui fonctionne avec ce branchement, ce qui est on ne peut plus normal, et en l'incluant dans un projet Obj-C, j'ai le message d'erreur syntax error before char ? ???
if(condition) goto LABEL;
.....
LABEL:
char ** cStrings
.....
J'ai un projet C qui fonctionne avec ce branchement, ce qui est on ne peut plus normal, et en l'incluant dans un projet Obj-C, j'ai le message d'erreur syntax error before char ? ???
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
--> Pas de problème...
Essaie de faire "preprocess" histoire de voir si LABEL n'est pas une macro définie dans ton projet :P
PS : "goto" c'est une technologie d'un autre âge
ça reste encore le meilleur moyen pour sortir de deux boucles imbriquées.
Dans mon cas, cela me semblait le plus élégant :
action1
arrêter si réussite
action2 utilisant la construction faite dans l'action1, mais pas la même méthode
arrêter si réussite
...
et les actions sont des fonctions C .
J'ai remplacé mon étiquette par MACHINTRUCCHOUETTE, pareil.
Bon, je fais autrement ... mais je ne comprends pas.
action1
if(pas reussite) action2
if(pas reussite) action3
...
...
Cela fait un certain nombre de tests faits inutilement, mais bon.
action1(..,..); if(condition) goto BAIL_OUT;
action2(..,..,..,..); if(condition) goto BAIL_OUT;
....
action8(..); if(condition) goto BAIL_OUT;
BAIL_OUT:
Pour moi la disparition du goto dans les années 80 était la volonté de supprimer ces codes en organigramme où la multiplicité des branchements nuisaient à une bonne structuration du programme. De là à ne pas l'utiliser quand c'est une solution simple et lisible ...
Le seul dogme que j'admets c'est : " un code doit être clair, sans astuce qui demande une double lecture "
Mon problème , que je n'ai d'ailleurs toujours pas résolu, c'est pourquoi j'ai un bug.
Merci pour ta solution que je n'avais pas envisagée.
Quand on lit un code et qu'on tombe sur un "goto", il faut chercher l'étiquette et aucune indication d'indentation ou autre peut nous dire rapidement où elle est ; particulièrement quand il y a plusieurs étiquettes (d'où le " plus lisible " ).
Sans compter que les étiquettes se mettent en général en tout début de ligne et de ce fait perturbent la visibilité des indentations
Le " propre " étant en effet une notion subjective 8--)
Pour le problème de compilation, je ne vois pas puisque mon exemple ci-dessus fonctionne :P
En l'occurence le nom choisi pour l'étiquette (BAIL_OUT) indique où elle se trouve, et de plus j'ai huit lignes avant cette étiquette, franchement la lecture est claire. Alors que l'appel d'une fonction à but astucieux mais relativement abstrait, qui sera peut-être physiquement éloignée dans mon code, je ne suis prêt à en payer le prix que si son contenu est lourd.
En réalité dans le code au-dessus j'ai reporté la lourdeur du contenu dans trois fonctions annexes, dont le rôle est bien précis.
Pour comparaison, sans goto:
Avec goto:
Il ne faut faire des sauts qu'en avant, autrement, ça revient à faire des plats de spaghetti. Mais dire "ah non le goto c'est mal", c'est bien un dogme.
[size=12pt]Avant le goto, mon code était terne. Maintenant, je suis bien dans mon code, et le regards des femmes à mon sujet a changé. Alors faà®tes comme moi... adoptez le goto ![/size]
Tu me permettras de le réécrire de cette manière ? :P
Mais pareil... pour ce genre de cas (somme toute assez rare), je préfère une fonction avec un return :P
De toute manière, il faut bien connaà®tre les techniques, car nombre de langages n'ont pas cette instruction (dont le Java !)
YES!!
GOTO POWER !!!
:adios!: :brule:
Bon, je dois avouer que je suis loin d'être un fan du goto, et préfère largement les break ou surtout le découpage en fonctions distinctes sinon. Mais bon de là à brûler au bûcher ceux qui l'utilisent quand c'est justifié... faut savoir faire la part des choses. Le tout est surtout que ça ne devienne pas une habitude, le goto venant de la programmation itérative (ça me rappelle mes programmes en BASIC sur Apple ][e ou les fichiers BAT de windoze ;D).
Donc pour moi, c'est à éviter... mais c'est toléré... à condition que ce soit justifié :P
Ouais mais là pour le coup tu perds tes valeurs (du coup le NSLog à la fin est foireux...)
ni goto, ni break, ni return.
Je m'explique : quand une fonction doit renvoyer une valeur, je ne mets qu'un seul return, et c'est la dernière instruction. Pour les contrôles de boucle, je traà®ne une variable d'erreur qui me permet de les stopper dans la condition des "for". Avec des "if", je décompose la fonction en morceaux à exécuter uniquement s'il n'y a pas eu d'erreur précédemment.
Exemple :
Avant de me traiter de psychopathe, voici les raisons :
-Quand on lit le code on sait tout de suite comment s'appelle la variable de retour, quel est son type, etc.
-Quand on veut débugguer, on peut mettre des printfs partout, il seront toujours affichés dans le même ordre. Et pas de surprise : aucun goto ou break ne risque de passer par dessus.
-Quand on se met à poser des verrous (style NSLock() et compagnie), avec mon système, on a beaucoup moins de chances de sortir de la fonction en ayant sauté le unLock().
En réalité, je m'autorise les break dans un seul cas : au début d'un for "nouvelle syntaxe".
Il est vraiment très rare que mon schéma soit plus contraignant à lire/écrire que la sécurité qu'il apporte.
+
Chacha
Alors pour les malades comme vous, je conseille le GOTO++ (http://www.gotopp.org//)
C'est un langage dont le but est de rendre l'exécution la plus imprévisible possible.
C'est un langage évolué : on peut même utiliser des sockets (fonction enfiler_chaussette(), je crois).
C'est un langage avec des particularités inédites : une instruction permet d'effectuer un GOTO aléatoire.
Oui, c'est drôle
+
Chacha
Oui c'est vrai, comme je l'ai dis, ça dépend des cas, ici, il faut juste recopier le résultat dans d'autres variables si on a besoin des valeurs.
Ah ben si, je l'avais oublié celui-là . Bon, mais là c'est pas trop pareil, puisque le break d'un case est toujours à la fin de son bloc. Donc il ne saute pas au-dessus d'un bloc qui aurait pu être exécuté (ou alors ça devient vraiment un switch subtil).
Bon, mais j'ai quand même, là aussi, une ligne de conduite très claire :
Je n'utilise le switch que sur les type énumérés, pour faire la part belle à -Wswitch-enum.
Pour tout le reste, c'est if...else if... else if...
Alors ce serait moi le grand malade ?
+
Chacha