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
"Emmanuel Delahaye" a écrit dans le message de news:438f7366$0$7712$
"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é.
Un if else aussi... La question n'est pas là.
Je confirme que la question n'est pas là, évidement, puisqu'il n'y a pas de question.
Ce qui m'émerveille, c'est ce tour de force : - voir une question, là où il n'y en a pas. - répondre à cette question imaginaire. - et dans la réponse dire que "la question n'est pas là".
Trop paradoxal.
"Emmanuel Delahaye" <emdel@YOURBRAnoos.fr> a écrit dans le message de news:438f7366$0$7712$79c14f64@nan-newsreader-06.noos.net...
"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é.
Un if else aussi... La question n'est pas là.
Je confirme que la question n'est pas là, évidement, puisqu'il n'y a pas de question.
Ce qui m'émerveille, c'est ce tour de force :
- voir une question, là où il n'y en a pas.
- répondre à cette question imaginaire.
- et dans la réponse dire que "la question n'est pas là".
"Emmanuel Delahaye" a écrit dans le message de news:438f7366$0$7712$
"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é.
Un if else aussi... La question n'est pas là.
Je confirme que la question n'est pas là, évidement, puisqu'il n'y a pas de question.
Ce qui m'émerveille, c'est ce tour de force : - voir une question, là où il n'y en a pas. - répondre à cette question imaginaire. - et dans la réponse dire que "la question n'est pas là".
Trop paradoxal.
Antoine Leca
In news:438f7417$0$7712$, Emmanuel Delahaye va escriure:
Ces histoires d'implémentation ne nous interesse pas.
Si tu veux dire que c'est ton avis et que tu le partages, je respecte ton point de vue mais permet moi de trouver que le "nous" est un peu présompteux. Ou alors tu a oublié la majuscule : « ne Nous interesse pas » ;-).
Si tu veux dire que les questions d'implémentations des constructions les plus classiques (et spécifiques) du C ne concernent pas ce forum, je ne suis pas d'accord.
Antoine
In news:438f7417$0$7712$79c14f64@nan-newsreader-06.noos.net,
Emmanuel Delahaye va escriure:
Ces histoires d'implémentation ne nous interesse pas.
Si tu veux dire que c'est ton avis et que tu le partages, je respecte ton
point de vue mais permet moi de trouver que le "nous" est un peu
présompteux.
Ou alors tu a oublié la majuscule : « ne Nous interesse pas » ;-).
Si tu veux dire que les questions d'implémentations des constructions les
plus classiques (et spécifiques) du C ne concernent pas ce forum, je ne suis
pas d'accord.
In news:438f7417$0$7712$, Emmanuel Delahaye va escriure:
Ces histoires d'implémentation ne nous interesse pas.
Si tu veux dire que c'est ton avis et que tu le partages, je respecte ton point de vue mais permet moi de trouver que le "nous" est un peu présompteux. Ou alors tu a oublié la majuscule : « ne Nous interesse pas » ;-).
Si tu veux dire que les questions d'implémentations des constructions les plus classiques (et spécifiques) du C ne concernent pas ce forum, je ne suis pas d'accord.
Antoine
Antoine Leca
In news:438f51ff$0$21298$, Albert va escriure:
if (year == Gregoire && month == 9 && day > 2)
Vérifie tes annales ; pour moi, l'application de la réforme remonte au plus tôt au 15 octobre (en calendrier grégorien).
N'hésitez pas à sur-parenthéser oui c'est vrai un defaut de ma part.
Ce n'est pas un défaut. Il s'agit de style (comme toute cette enfilade d'ailleurs).
Pierre préfère les parenthèses, mêmes inutiles.
D'autres, par exemple Brian Kernighan (oui, je suis présompueux) sont plus économes à ce niveau ; et ils ont institué un style classique très épuré mais qui oblige les programmeurs (au sens large, ceux qui écrivent mais aussi et surtout ceux qui lisent le code derrière) à bien connaître les règles de précéance (c'est surtout un problème entre +-, <<>>, ==!=<> et &|^).
Il faut bien avoir en tête le conseil (juste) de Pierre : quand cela manque de lisibilité, mettre des parenthèses peut aider. Ce n'est cependant pas la seule solution : on peut aussi écrire if( year == Gregoire && month == 9 && day > 2 ) qui ne nécessite strictement aucune parenthèse pour être limpide (enfin, je trouve :^)).
Parfois, c'est plus simple : ainsi il n'est pas rare de rencontrer des normes de programmation (en environnement « industriel ») qui demandent à mettre des parenthèses un peu partout.
/* c'est un 29 non fevrier donc saisie plausible = Vrai */ if ((day == 29 ) && ( month != 2)) return(Vrai);
Encore une affaire de style, mais je ne comprend pas trop pourquoi tu exclus ce cas en _dehors_ du switch ?
En C, il est possible d'avoir _plusieurs_ instructions après un case (et en général, la dernière d'entre elles sera un break;). C est différent du Pascal ici, *attention*.
case 30: if ( day == 30 && month == 2)
Pas satisfaisant. Inattention, certainement.
Monsieur est elliptique...
L'approche manque d'homogénéité. Pour parler comme à la radio, on ne perçoit pas immédiatement le projet.
C'est juste une fonction de test sur le JOUR de saisie c'est tout.
Sauf que les cas jour<1 et jour>31 ne sont pas traités ici (on espère qu'ils le sont ailleurs).
case janvier: case mars: case mai: case juillet: case aout: case octobre: case decembre: retour = !((day > 31) || (day < 0));
Inattention, certainement. ;-)
break; case avril: case juin: case novembre: retour = !((day > 30) || (day < 0)); break; case fevrier: /* à faire */ break; case septembre: /* à faire */ break;
Janvier, mars, mai,etc rien a dire. Des case sans reelle utilite ?
Le compilateur s'en moque (OK ED, c'est un détail d'implémentation, mais c'est important à comprendre). En fait, que tu passes dans un switch par un case avec rien à faire, OU que tu passes par default avec rien non plus à faire, c'est la même chose (et selon les implémentations, tu auras l'une _ou_ l'autre des solutions qui sera plus rapide ; aujourd'hui, les compilateurs analysent globalement et le résultat sera exactement le même).
Par contre, pour l'½il humain, cela montre que tu as bien prévu ces cas-là, donc que cette fonction est bien prévue pour être appelée dans ce cas-là, etc. Très important.
Antoine
In news:438f51ff$0$21298$8fcfb975@news.wanadoo.fr,
Albert va escriure:
if (year == Gregoire && month == 9 && day > 2)
Vérifie tes annales ; pour moi, l'application de la réforme remonte au plus
tôt au 15 octobre (en calendrier grégorien).
N'hésitez pas à sur-parenthéser
oui c'est vrai un defaut de ma part.
Ce n'est pas un défaut. Il s'agit de style (comme toute cette enfilade
d'ailleurs).
Pierre préfère les parenthèses, mêmes inutiles.
D'autres, par exemple Brian Kernighan (oui, je suis présompueux) sont plus
économes à ce niveau ; et ils ont institué un style classique très épuré
mais qui oblige les programmeurs (au sens large, ceux qui écrivent mais
aussi et surtout ceux qui lisent le code derrière) à bien connaître les
règles de précéance (c'est surtout un problème entre +-, <<>>, ==!=<> et
&|^).
Il faut bien avoir en tête le conseil (juste) de Pierre : quand cela manque
de lisibilité, mettre des parenthèses peut aider. Ce n'est cependant pas la
seule solution : on peut aussi écrire
if( year == Gregoire
&& month == 9
&& day > 2 )
qui ne nécessite strictement aucune parenthèse pour être limpide (enfin, je
trouve :^)).
Parfois, c'est plus simple : ainsi il n'est pas rare de rencontrer des
normes de programmation (en environnement « industriel ») qui demandent à
mettre des parenthèses un peu partout.
/* c'est un 29 non fevrier donc saisie plausible = Vrai */
if ((day == 29 ) && ( month != 2))
return(Vrai);
Encore une affaire de style, mais je ne comprend pas trop pourquoi tu exclus
ce cas en _dehors_ du switch ?
En C, il est possible d'avoir _plusieurs_ instructions après un case (et en
général, la dernière d'entre elles sera un break;). C est différent du
Pascal ici, *attention*.
case 30:
if ( day == 30 && month == 2)
Pas satisfaisant. Inattention, certainement.
Monsieur est elliptique...
L'approche manque d'homogénéité. Pour parler comme à la radio, on ne
perçoit pas immédiatement le projet.
C'est juste une fonction de test sur le JOUR de saisie c'est tout.
Sauf que les cas jour<1 et jour>31 ne sont pas traités ici (on espère qu'ils
le sont ailleurs).
case janvier:
case mars:
case mai:
case juillet:
case aout:
case octobre:
case decembre:
retour = !((day > 31) || (day < 0));
Inattention, certainement.
;-)
break;
case avril:
case juin:
case novembre:
retour = !((day > 30) || (day < 0));
break;
case fevrier:
/* à faire */
break;
case septembre:
/* à faire */
break;
Janvier, mars, mai,etc rien a dire. Des case sans reelle utilite ?
Le compilateur s'en moque (OK ED, c'est un détail d'implémentation, mais
c'est important à comprendre).
En fait, que tu passes dans un switch par un case avec rien à faire, OU que
tu passes par default avec rien non plus à faire, c'est la même chose (et
selon les implémentations, tu auras l'une _ou_ l'autre des solutions qui
sera plus rapide ; aujourd'hui, les compilateurs analysent globalement et le
résultat sera exactement le même).
Par contre, pour l'½il humain, cela montre que tu as bien prévu ces cas-là,
donc que cette fonction est bien prévue pour être appelée dans ce cas-là,
etc. Très important.
Vérifie tes annales ; pour moi, l'application de la réforme remonte au plus tôt au 15 octobre (en calendrier grégorien).
N'hésitez pas à sur-parenthéser oui c'est vrai un defaut de ma part.
Ce n'est pas un défaut. Il s'agit de style (comme toute cette enfilade d'ailleurs).
Pierre préfère les parenthèses, mêmes inutiles.
D'autres, par exemple Brian Kernighan (oui, je suis présompueux) sont plus économes à ce niveau ; et ils ont institué un style classique très épuré mais qui oblige les programmeurs (au sens large, ceux qui écrivent mais aussi et surtout ceux qui lisent le code derrière) à bien connaître les règles de précéance (c'est surtout un problème entre +-, <<>>, ==!=<> et &|^).
Il faut bien avoir en tête le conseil (juste) de Pierre : quand cela manque de lisibilité, mettre des parenthèses peut aider. Ce n'est cependant pas la seule solution : on peut aussi écrire if( year == Gregoire && month == 9 && day > 2 ) qui ne nécessite strictement aucune parenthèse pour être limpide (enfin, je trouve :^)).
Parfois, c'est plus simple : ainsi il n'est pas rare de rencontrer des normes de programmation (en environnement « industriel ») qui demandent à mettre des parenthèses un peu partout.
/* c'est un 29 non fevrier donc saisie plausible = Vrai */ if ((day == 29 ) && ( month != 2)) return(Vrai);
Encore une affaire de style, mais je ne comprend pas trop pourquoi tu exclus ce cas en _dehors_ du switch ?
En C, il est possible d'avoir _plusieurs_ instructions après un case (et en général, la dernière d'entre elles sera un break;). C est différent du Pascal ici, *attention*.
case 30: if ( day == 30 && month == 2)
Pas satisfaisant. Inattention, certainement.
Monsieur est elliptique...
L'approche manque d'homogénéité. Pour parler comme à la radio, on ne perçoit pas immédiatement le projet.
C'est juste une fonction de test sur le JOUR de saisie c'est tout.
Sauf que les cas jour<1 et jour>31 ne sont pas traités ici (on espère qu'ils le sont ailleurs).
case janvier: case mars: case mai: case juillet: case aout: case octobre: case decembre: retour = !((day > 31) || (day < 0));
Inattention, certainement. ;-)
break; case avril: case juin: case novembre: retour = !((day > 30) || (day < 0)); break; case fevrier: /* à faire */ break; case septembre: /* à faire */ break;
Janvier, mars, mai,etc rien a dire. Des case sans reelle utilite ?
Le compilateur s'en moque (OK ED, c'est un détail d'implémentation, mais c'est important à comprendre). En fait, que tu passes dans un switch par un case avec rien à faire, OU que tu passes par default avec rien non plus à faire, c'est la même chose (et selon les implémentations, tu auras l'une _ou_ l'autre des solutions qui sera plus rapide ; aujourd'hui, les compilateurs analysent globalement et le résultat sera exactement le même).
Par contre, pour l'½il humain, cela montre que tu as bien prévu ces cas-là, donc que cette fonction est bien prévue pour être appelée dans ce cas-là, etc. Très important.
Antoine
Pierre Maurette
[...]
case janvier: case mars: case mai: case juillet: case aout: case octobre: case decembre: retour = !((day > 31) || (day < 0));
Inattention, certainement. ;-) Oui. Mais inquiétant, quand même. Ça remet en cause partiellement un
autre post dans lequel j'utilise unigned int, alors qu'effectivement j'attends des day sur [1..X] et des month sur [1..12].
-- Pierre Maurette
[...]
case janvier:
case mars:
case mai:
case juillet:
case aout:
case octobre:
case decembre:
retour = !((day > 31) || (day < 0));
Inattention, certainement.
;-)
Oui. Mais inquiétant, quand même. Ça remet en cause partiellement un
autre post dans lequel j'utilise unigned int, alors qu'effectivement
j'attends des day sur [1..X] et des month sur [1..12].
case janvier: case mars: case mai: case juillet: case aout: case octobre: case decembre: retour = !((day > 31) || (day < 0));
Inattention, certainement. ;-) Oui. Mais inquiétant, quand même. Ça remet en cause partiellement un
autre post dans lequel j'utilise unigned int, alors qu'effectivement j'attends des day sur [1..X] et des month sur [1..12].
-- Pierre Maurette
Richard Delorme
if (year == Gregoire && month == 9 && day > 2)
Vérifie tes annales ; pour moi, l'application de la réforme remonte au plus tôt au 15 octobre (en calendrier grégorien).
Ça dépend des pays. Le 2/9/1752 suivi du 14/9/1752 est la date de passage des pays anglo-saxons. En France, le passage c'est fait en décembre 1582, le 9 étant suivi du 20 décembre. Normalement, une bonne localisation devrait aussi tenir compte du calendrier républicain utilisé en France du 22 septembre 1792 au 31 décembre 1805.
-- Richard
if (year == Gregoire && month == 9 && day > 2)
Vérifie tes annales ; pour moi, l'application de la réforme remonte au plus
tôt au 15 octobre (en calendrier grégorien).
Ça dépend des pays. Le 2/9/1752 suivi du 14/9/1752 est la date de
passage des pays anglo-saxons. En France, le passage c'est fait en
décembre 1582, le 9 étant suivi du 20 décembre. Normalement, une bonne
localisation devrait aussi tenir compte du calendrier républicain
utilisé en France du 22 septembre 1792 au 31 décembre 1805.
Vérifie tes annales ; pour moi, l'application de la réforme remonte au plus tôt au 15 octobre (en calendrier grégorien).
Ça dépend des pays. Le 2/9/1752 suivi du 14/9/1752 est la date de passage des pays anglo-saxons. En France, le passage c'est fait en décembre 1582, le 9 étant suivi du 20 décembre. Normalement, une bonne localisation devrait aussi tenir compte du calendrier républicain utilisé en France du 22 septembre 1792 au 31 décembre 1805.
-- Richard
Pierre Maurette
[...]
Ca, avec votre permission, je le garde precieusement sous la main :-) Ne faites jamais confiance à un vieux ! C'est bugué, à cause des
saisies possibles à 0. Correction, à vérifier:
enum mois {fevbissext, janvier, fevrier, mars, avril, mai, juin, juillet, aout, septembre, octobre, novembre, decembre};
#define isBadGreg(y, m, d) ( ( (y) == 1582 ) && ( m == octobre) && ( d > 4 ) && ( d < 15 ) )
int SaisieValide(int day, int month, int year) { return (day > 0) && (month > 0) && (day <= MaxJours[isBissextile(year, month)?fevbissext:month]) && !isBadGreg(year, month, day); }
(voir: évaluation incomplète des expressions booléennes)
-- Pierre Maurette
Antoine Leca
In news:43901fd8$0$18582$, Richard Delorme va escriure:
if (year == Gregoire && month == 9 && day > 2)
Vérifie tes annales ; pour moi, l'application de la réforme remonte au plus tôt au 15 octobre (en calendrier grégorien). ^^^^^^^^^^^---------- <- précaution !
Ça dépend des pays.
Définit « pays » :-)))
Normalement, une bonne localisation devrait aussi tenir compte du calendrier républicain utilisé en France du 22 septembre 1792 au 31 décembre 1805.
En l'occurence, son programme en tient compte... en quelque sorte : les dates républicaines sont rejetées, si mon hypothèse que la routine qui appelle celle-ci fait le filtrage sur les années et les mois, et ne permet que les années supérieures à 1582, ce qui est me semble-t-il supérieur à 18, est correcte.
Antoine
In news:43901fd8$0$18582$7a628cd7@news.club-internet.fr, Richard Delorme va
escriure:
if (year == Gregoire && month == 9 && day > 2)
Vérifie tes annales ; pour moi, l'application de la réforme remonte
au plus tôt au 15 octobre (en calendrier grégorien).
^^^^^^^^^^^---------- <- précaution !
Ça dépend des pays.
Définit « pays » :-)))
Normalement, une bonne localisation devrait aussi tenir
compte du calendrier républicain utilisé en France du
22 septembre 1792 au 31 décembre 1805.
En l'occurence, son programme en tient compte... en quelque sorte : les
dates républicaines sont rejetées, si mon hypothèse que la routine qui
appelle celle-ci fait le filtrage sur les années et les mois, et ne permet
que les années supérieures à 1582, ce qui est me semble-t-il supérieur à 18,
est correcte.
In news:43901fd8$0$18582$, Richard Delorme va escriure:
if (year == Gregoire && month == 9 && day > 2)
Vérifie tes annales ; pour moi, l'application de la réforme remonte au plus tôt au 15 octobre (en calendrier grégorien). ^^^^^^^^^^^---------- <- précaution !
Ça dépend des pays.
Définit « pays » :-)))
Normalement, une bonne localisation devrait aussi tenir compte du calendrier républicain utilisé en France du 22 septembre 1792 au 31 décembre 1805.
En l'occurence, son programme en tient compte... en quelque sorte : les dates républicaines sont rejetées, si mon hypothèse que la routine qui appelle celle-ci fait le filtrage sur les années et les mois, et ne permet que les années supérieures à 1582, ce qui est me semble-t-il supérieur à 18, est correcte.
Antoine
Albert
Albert wrote:
Pour avoir naviguer pendant une quinzaine d'annees ( surtout en atlantique sinon bien plus loin ) j'avoue que je me suis plus interesse au calcul de position qu'aux horaires de marees ( sinon celles de granville avec un record de marnage !! ) y avait pas de GPS .. Au sextant mon petit.
C'est vrai que lorsqu'on ne voit plus la côte, l'horaire des marées et l'emploi du temps des bigornaux...
Granville, je connais aussi, un joli petit port, j'y ai passé un certain temps sur la pointe.
[HS] : c'est vrai qu'en bretagne la navigation cotiere est nettement
plus complexe que sur oleron ou re. La beaute de ses cotes a son inconvenient: une parfaite connaissance des sites ainsi que ... les horaires de marees. Ici une erreur se paie souvent mois cher que chez vous. A part le golf de gascogne qui reserve parfois de bonnes surprises ( j'ai donne).
C'est un programme comme un autre pour reapprendre les bases du C. Ma question n'a jamais porte sur le programme lui meme mais sur la syntaxe employee. Tout a fait different :-)
Je me permets de récidiver. La nature ou je ne sais qui ou quoi m'a affublé d'un esprit analytique et je pense qu'il faut séparer les problèmes. Les problèmes de dates sont très compliqués voire excessivement chiants pour le commun des mortels, prendre en même temps 2 niveaux de complexité n'additionne pas mais multiplie la complexité.
Je n'ai pas de Pb avec le calcul des dates. j'ai repris un ancien algo
utilise par beaucoup et qui fonctionne tres bien. Je recidive en disant que mon pb etait les return dans le switch case . Rien d'autre.
Le problème vient du fait que programmer ne consiste pas à écrire des programmes syntaxiquement corrects.
D'accord avec toi.
A bientot ( j'espere aller un jour a Brest ) !!! gil
Albert wrote:
Pour avoir naviguer pendant une quinzaine d'annees ( surtout en
atlantique sinon bien plus loin ) j'avoue que je me suis plus
interesse au calcul de position qu'aux horaires de marees ( sinon
celles de granville avec un record de marnage !! ) y avait pas de GPS
.. Au sextant mon petit.
C'est vrai que lorsqu'on ne voit plus la côte, l'horaire des marées et
l'emploi du temps des bigornaux...
Granville, je connais aussi, un joli petit port, j'y ai passé un certain
temps sur la pointe.
[HS] : c'est vrai qu'en bretagne la navigation cotiere est nettement
plus complexe que sur oleron ou re. La beaute de ses cotes a son
inconvenient: une parfaite connaissance des sites ainsi que ... les
horaires de marees.
Ici une erreur se paie souvent mois cher que chez vous.
A part le golf de gascogne qui reserve parfois de bonnes surprises (
j'ai donne).
C'est un programme comme un autre pour reapprendre les bases du C. Ma
question n'a jamais porte sur le programme lui meme mais sur la
syntaxe employee. Tout a fait different :-)
Je me permets de récidiver.
La nature ou je ne sais qui ou quoi m'a affublé d'un esprit analytique
et je pense qu'il faut séparer les problèmes.
Les problèmes de dates sont très compliqués voire excessivement chiants
pour le commun des mortels, prendre en même temps 2 niveaux de
complexité n'additionne pas mais multiplie la complexité.
Je n'ai pas de Pb avec le calcul des dates. j'ai repris un ancien algo
utilise par beaucoup et qui fonctionne tres bien.
Je recidive en disant que mon pb etait les return dans le switch case .
Rien d'autre.
Le problème vient du fait que programmer ne consiste pas à écrire des
programmes syntaxiquement corrects.
D'accord avec toi.
A bientot ( j'espere aller un jour a Brest ) !!!
gil
Pour avoir naviguer pendant une quinzaine d'annees ( surtout en atlantique sinon bien plus loin ) j'avoue que je me suis plus interesse au calcul de position qu'aux horaires de marees ( sinon celles de granville avec un record de marnage !! ) y avait pas de GPS .. Au sextant mon petit.
C'est vrai que lorsqu'on ne voit plus la côte, l'horaire des marées et l'emploi du temps des bigornaux...
Granville, je connais aussi, un joli petit port, j'y ai passé un certain temps sur la pointe.
[HS] : c'est vrai qu'en bretagne la navigation cotiere est nettement
plus complexe que sur oleron ou re. La beaute de ses cotes a son inconvenient: une parfaite connaissance des sites ainsi que ... les horaires de marees. Ici une erreur se paie souvent mois cher que chez vous. A part le golf de gascogne qui reserve parfois de bonnes surprises ( j'ai donne).
C'est un programme comme un autre pour reapprendre les bases du C. Ma question n'a jamais porte sur le programme lui meme mais sur la syntaxe employee. Tout a fait different :-)
Je me permets de récidiver. La nature ou je ne sais qui ou quoi m'a affublé d'un esprit analytique et je pense qu'il faut séparer les problèmes. Les problèmes de dates sont très compliqués voire excessivement chiants pour le commun des mortels, prendre en même temps 2 niveaux de complexité n'additionne pas mais multiplie la complexité.
Je n'ai pas de Pb avec le calcul des dates. j'ai repris un ancien algo
utilise par beaucoup et qui fonctionne tres bien. Je recidive en disant que mon pb etait les return dans le switch case . Rien d'autre.
Le problème vient du fait que programmer ne consiste pas à écrire des programmes syntaxiquement corrects.
D'accord avec toi.
A bientot ( j'espere aller un jour a Brest ) !!! gil
Pierre Maurette
[...]
A part le golf de gascogne qui reserve parfois de bonnes surprises J'y ai beaucoup navigué, c'est un sale coin où il faut avoir une
cartographie à jour. A cause des 18 trous. Si on pousse à l'Ouest, à part le poteau noir avec lequel une collision est toujours possible, c'est clair jusqu'en amérique.
-- Pierre Maurette
[...]
A part le golf de gascogne qui reserve parfois de bonnes surprises
J'y ai beaucoup navigué, c'est un sale coin où il faut avoir une
cartographie à jour. A cause des 18 trous.
Si on pousse à l'Ouest, à part le poteau noir avec lequel une collision
est toujours possible, c'est clair jusqu'en amérique.
A part le golf de gascogne qui reserve parfois de bonnes surprises J'y ai beaucoup navigué, c'est un sale coin où il faut avoir une
cartographie à jour. A cause des 18 trous. Si on pousse à l'Ouest, à part le poteau noir avec lequel une collision est toujours possible, c'est clair jusqu'en amérique.
