Bonjour a tous,
Mon probleme est dans le titre.
J'ai un switch case et a l'interieur est il "permis" de sortir d'un
case par un return ( le switch case est bien sur dans une fonction)
A la compile ( gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5))
je n'ai aucun message d'avertissement. Mais je voudrais etre sur que
c'est correcte. Rien vu a ce sujet.
Merci de vos reponses.
gil
En tant qu'ardent défenseur des choses simples et de la programmation structurée, je n'aime pas cette pratique...
Absulument ! Un goto vers la fin de la fonction est nettement préférable.
Harpo
Albert wrote:
En fait je voulais eviter les if imbriques ou avoir une autre variable a l'interieur de la fonction ( ce qui faciltait d'un cote mais alourdissait de l'autre). Mon probleme etait de savoir si le return dans un switch respectait la norme (vu que je n'ai pas de warning). C'est une fonction hyper simple de verification des dates entrees pour le calendrier.
Si la fonction est simple ou courte ( tient sur un écran et sera peu susceptible d'être allongée ), cela se conçoit. C'est même un souvent un bon choix pour une fonction de contrôle qui renvoie 0 ou un code d'erreur, cela peut permettre d'éviter les cascades de if{}else{} imbriqués qui deviennent illisibles dès qu'ils dépassent une page d'écran - i.e. 25 lignes 80 colonnes -
C'est mon premier prg depuis une 15iene d'annees donc soyez indulgents. Il fonctionne correctement :-)
Je ne demande qu'à te croire, mais on ne peut dire qu'un programme fonctionne sinon pour les essais que l'on a effectués dans les circonstances où on les a effectués dans la mesure où on ne s'est pas trompé en vérifiant les résultats. Surtout les problèmes de date, c'est compliqué.
Albert wrote:
En fait je voulais eviter les if imbriques ou avoir une autre variable
a l'interieur de la fonction ( ce qui faciltait d'un cote mais
alourdissait de l'autre). Mon probleme etait de savoir si le return
dans un switch respectait la norme (vu que je n'ai pas de warning).
C'est une fonction hyper simple de verification des dates entrees pour
le calendrier.
Si la fonction est simple ou courte ( tient sur un écran et sera peu
susceptible d'être allongée ), cela se conçoit.
C'est même un souvent un bon choix pour une fonction de contrôle qui
renvoie 0 ou un code d'erreur, cela peut permettre d'éviter les
cascades de if{}else{} imbriqués qui deviennent illisibles dès qu'ils
dépassent une page d'écran - i.e. 25 lignes 80 colonnes -
C'est mon premier prg depuis une 15iene d'annees donc soyez
indulgents. Il fonctionne correctement :-)
Je ne demande qu'à te croire, mais on ne peut dire qu'un programme
fonctionne sinon pour les essais que l'on a effectués dans les
circonstances où on les a effectués dans la mesure où on ne s'est pas
trompé en vérifiant les résultats.
Surtout les problèmes de date, c'est compliqué.
En fait je voulais eviter les if imbriques ou avoir une autre variable a l'interieur de la fonction ( ce qui faciltait d'un cote mais alourdissait de l'autre). Mon probleme etait de savoir si le return dans un switch respectait la norme (vu que je n'ai pas de warning). C'est une fonction hyper simple de verification des dates entrees pour le calendrier.
Si la fonction est simple ou courte ( tient sur un écran et sera peu susceptible d'être allongée ), cela se conçoit. C'est même un souvent un bon choix pour une fonction de contrôle qui renvoie 0 ou un code d'erreur, cela peut permettre d'éviter les cascades de if{}else{} imbriqués qui deviennent illisibles dès qu'ils dépassent une page d'écran - i.e. 25 lignes 80 colonnes -
C'est mon premier prg depuis une 15iene d'annees donc soyez indulgents. Il fonctionne correctement :-)
Je ne demande qu'à te croire, mais on ne peut dire qu'un programme fonctionne sinon pour les essais que l'on a effectués dans les circonstances où on les a effectués dans la mesure où on ne s'est pas trompé en vérifiant les résultats. Surtout les problèmes de date, c'est compliqué.
slyver
"Pierre Maurette" a écrit dans le message de news:
A moins d'avoir une raison particulière pour un seul return par fonction (par exemple des outils de vérification ou de débogage que je ne connais pas), et dans le cas classique d'un fonction réduite à d'éventuels inits suivis d'un vaste switch, ça me semble la meilleure solution même sur le plan du style.
... ou pour oublier de libérer des ressources... Ce n'est pas sur les pistes noires qu'on se casse le plus du matériel
osseux, ce n'est pas à Waimea ou Pipeline qu'il y a le plus de noyés. Pourquoi ? Parce que face à l'évidence du danger, le combattant est prudent. Donc, en mettant des return absolument n'importe où, aux endroits les plus improbables, le programmeur d'élite, keskifera ? Il flairera le danger, supputera le piège, et pensera "Et mes p..... de ressources, les ai-je bien libérées ?". Dans le baroud, le codeur se sublime.
Donc, vive le return dans les switch quand c'est possible. Sinon, un petit: goto finalize; bien crapuleux ...
-- Pierre Maurette
"crapuleux" le goto ? Dans ce cas j'utiliserais plutot le mot "approprié"...
"Pierre Maurette" <maurettepierre@wanadoo.fr> a écrit dans le message de
news: mn.ec877d5ba1da2fab.31483@laposte.net...
A moins d'avoir une raison particulière pour un seul return par fonction
(par exemple des outils de vérification ou de débogage que je ne connais
pas), et dans le cas classique d'un fonction réduite à d'éventuels inits
suivis d'un vaste switch, ça me semble la meilleure solution même sur le
plan du style.
... ou pour oublier de libérer des ressources...
Ce n'est pas sur les pistes noires qu'on se casse le plus du matériel
osseux, ce n'est pas à Waimea ou Pipeline qu'il y a le plus de noyés.
Pourquoi ? Parce que face à l'évidence du danger, le combattant est
prudent.
Donc, en mettant des return absolument n'importe où, aux endroits les plus
improbables, le programmeur d'élite, keskifera ? Il flairera le danger,
supputera le piège, et pensera "Et mes p..... de ressources, les ai-je
bien libérées ?". Dans le baroud, le codeur se sublime.
Donc, vive le return dans les switch quand c'est possible. Sinon, un
petit:
goto finalize;
bien crapuleux ...
--
Pierre Maurette
"crapuleux" le goto ? Dans ce cas j'utiliserais plutot le mot "approprié"...
"Pierre Maurette" a écrit dans le message de news:
A moins d'avoir une raison particulière pour un seul return par fonction (par exemple des outils de vérification ou de débogage que je ne connais pas), et dans le cas classique d'un fonction réduite à d'éventuels inits suivis d'un vaste switch, ça me semble la meilleure solution même sur le plan du style.
... ou pour oublier de libérer des ressources... Ce n'est pas sur les pistes noires qu'on se casse le plus du matériel
osseux, ce n'est pas à Waimea ou Pipeline qu'il y a le plus de noyés. Pourquoi ? Parce que face à l'évidence du danger, le combattant est prudent. Donc, en mettant des return absolument n'importe où, aux endroits les plus improbables, le programmeur d'élite, keskifera ? Il flairera le danger, supputera le piège, et pensera "Et mes p..... de ressources, les ai-je bien libérées ?". Dans le baroud, le codeur se sublime.
Donc, vive le return dans les switch quand c'est possible. Sinon, un petit: goto finalize; bien crapuleux ...
-- Pierre Maurette
"crapuleux" le goto ? Dans ce cas j'utiliserais plutot le mot "approprié"...
screetch
Pierre Maurette wrote:
Nous voilà partis dans l'interminable ;-) Le contre-exemple de l'exemple, les trucs immondes où on alloue n'importe où et où tout à coup on est devenu nullissime. Puis viendront les machines improbables, les exemples vécus, les fusées qui tombent, et j'en passe. Je me positionne dans le cas où les multiples return s'imposent logiquement bien entendu, et je considère que le programmeur est capable de structurer son code, y compris au niveau du style. Bien entendu, si un seul case n'aboutit pas à return, c'est différent. Dans ces conditions, je vois mal la supériorité de 36:
retour = qqchose; break; /* un goto qui fait sa chochote */ je dirai juste que le code n'invoque pas ses posts conditions et que
c'est mal.
case 1: rval = -1; goto end;
end: assert(rval >= 0); return rval;
c'est mieux que
case 1: return -1;
vu qu'apparemment la fonction n'est pas censée renvoyer du négatif. Quand meme le goto devient mieux que le return......
Pierre Maurette wrote:
Nous voilà partis dans l'interminable ;-)
Le contre-exemple de l'exemple, les trucs immondes où on alloue
n'importe où et où tout à coup on est devenu nullissime. Puis viendront
les machines improbables, les exemples vécus, les fusées qui tombent, et
j'en passe.
Je me positionne dans le cas où les multiples return s'imposent
logiquement bien entendu, et je considère que le programmeur est capable
de structurer son code, y compris au niveau du style. Bien entendu, si
un seul case n'aboutit pas à return, c'est différent. Dans ces
conditions, je vois mal la supériorité de 36:
retour = qqchose;
break; /* un goto qui fait sa chochote */
je dirai juste que le code n'invoque pas ses posts conditions et que
c'est mal.
case 1:
rval = -1;
goto end;
end:
assert(rval >= 0);
return rval;
c'est mieux que
case 1:
return -1;
vu qu'apparemment la fonction n'est pas censée renvoyer du négatif.
Quand meme le goto devient mieux que le return......
Nous voilà partis dans l'interminable ;-) Le contre-exemple de l'exemple, les trucs immondes où on alloue n'importe où et où tout à coup on est devenu nullissime. Puis viendront les machines improbables, les exemples vécus, les fusées qui tombent, et j'en passe. Je me positionne dans le cas où les multiples return s'imposent logiquement bien entendu, et je considère que le programmeur est capable de structurer son code, y compris au niveau du style. Bien entendu, si un seul case n'aboutit pas à return, c'est différent. Dans ces conditions, je vois mal la supériorité de 36:
retour = qqchose; break; /* un goto qui fait sa chochote */ je dirai juste que le code n'invoque pas ses posts conditions et que
c'est mal.
case 1: rval = -1; goto end;
end: assert(rval >= 0); return rval;
c'est mieux que
case 1: return -1;
vu qu'apparemment la fonction n'est pas censée renvoyer du négatif. Quand meme le goto devient mieux que le return......
TERENCE
"Pierre Maurette" a écrit dans le message de news:
retour = qqchose; break; /* un goto qui fait sa chochote */
Oui, de même que 'switch' est une succession de 'if ... goto ...', relooké.
"Pierre Maurette" <maurettepierre@wanadoo.fr> a écrit dans le message de news:mn.eb487d5b8ee72df5.31483@laposte.net...
retour = qqchose;
break; /* un goto qui fait sa chochote */
Oui, de même que 'switch' est une succession de 'if ... goto ...', relooké.
"Pierre Maurette" a écrit dans le message de news:
retour = qqchose; break; /* un goto qui fait sa chochote */
Oui, de même que 'switch' est une succession de 'if ... goto ...', relooké.
Pierre Maurette
"Pierre Maurette" a écrit dans le message de news:
retour = qqchose; break; /* un goto qui fait sa chochote */
Oui, de même que 'switch' est une succession de 'if ... goto ...', relooké. (il y avait un soupçon de second degré dans mon post)
Le switch du C est effectivement peu utile. On peut regretter l'absence d'intervalle, qui permettrait à la Delphi d'écrire: case 12, 20..29, 50, 52: /* etc. */
Tel qu'il est, il me semble présenter peu d'avantage sur:
Inconvénients, quand même: - pas d'erreur ni de warning en cas de duplication de cas. - il faut au moins une fois avoir réfléchi à l'algo du if / else if / else if / ... / else, qui n'est pas nécessairement absolument trivial la première fois.
Je trouve que le switch est pratique si on ne le bricole pas, à part remplacer le break par un return bien entendu ;-) et en liaison avec une enum.
-- Pierre Maurette
"Pierre Maurette" <maurettepierre@wanadoo.fr> a écrit dans le message de
news:mn.eb487d5b8ee72df5.31483@laposte.net...
retour = qqchose;
break; /* un goto qui fait sa chochote */
Oui, de même que 'switch' est une succession de 'if ... goto ...', relooké.
(il y avait un soupçon de second degré dans mon post)
Le switch du C est effectivement peu utile. On peut regretter l'absence
d'intervalle, qui permettrait à la Delphi d'écrire:
case 12, 20..29, 50, 52: /* etc. */
Tel qu'il est, il me semble présenter peu d'avantage sur:
Inconvénients, quand même:
- pas d'erreur ni de warning en cas de duplication de cas.
- il faut au moins une fois avoir réfléchi à l'algo du
if / else if / else if / ... / else, qui n'est pas nécessairement
absolument trivial la première fois.
Je trouve que le switch est pratique si on ne le bricole pas, à part
remplacer le break par un return bien entendu ;-) et en liaison avec
une enum.
"Pierre Maurette" a écrit dans le message de news:
retour = qqchose; break; /* un goto qui fait sa chochote */
Oui, de même que 'switch' est une succession de 'if ... goto ...', relooké. (il y avait un soupçon de second degré dans mon post)
Le switch du C est effectivement peu utile. On peut regretter l'absence d'intervalle, qui permettrait à la Delphi d'écrire: case 12, 20..29, 50, 52: /* etc. */
Tel qu'il est, il me semble présenter peu d'avantage sur:
Inconvénients, quand même: - pas d'erreur ni de warning en cas de duplication de cas. - il faut au moins une fois avoir réfléchi à l'algo du if / else if / else if / ... / else, qui n'est pas nécessairement absolument trivial la première fois.
Je trouve que le switch est pratique si on ne le bricole pas, à part remplacer le break par un return bien entendu ;-) et en liaison avec une enum.
-- Pierre Maurette
Jean-Marc Bourguet
"TERENCE" writes:
"Pierre Maurette" a écrit dans le message de news:
retour = qqchose; break; /* un goto qui fait sa chochote */
Oui, de même que 'switch' est une succession de 'if ... goto ...', relooké.
Les switch sont des goto table[i].
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
"TERENCE" <Ael-Rowan.TERENCE@NoReply.com> writes:
"Pierre Maurette" <maurettepierre@wanadoo.fr> a écrit dans le message de news:mn.eb487d5b8ee72df5.31483@laposte.net...
retour = qqchose;
break; /* un goto qui fait sa chochote */
Oui, de même que 'switch' est une succession de 'if ... goto ...', relooké.
Les switch sont des goto table[i].
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
