Discussion :

[Ti-R]

Bizarre je n’ai jamais utilisé de goto...
Pourtant je code souvent...
Alors on pourrait s'en passer ??
A par dans de très très très rare cas...

[gege2061]

iagine ce que ça donne avec une centaine de champs, quand tous saufs le dernier ne sont pas présents.... tu marques un if avec cent tests dedans? Pas très lisible tout ça...

Non, je revoie ma façon de codée

[DavG]

Bizarre je n’ai jamais utilisé de goto...
Pourtant je code souvent...

"Coder" .. ça ne veut rien dire ... tout dépend si tu fais du temps-réel critique (genre switch en bas de la ms avec un OS très performant) ou si tu fais des applications plus standard

Alors on pourrait s'en passer ??
A par dans de très très très rare cas...

Dans la mesure du possible, oui, mais c'est un peu comme l'école qui refuse les "continue" dans les for

[ulukahio]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
if( ligne[i] == 2 )
{  /* traitement du champ2 */ }
else if ( lign[i] == 1 || ligne[i]==3 )
{ /* traitement du champ3 */ }
else{ /* traitement du champ1 */}

la même avec les switch:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
switch( ligne[i] )
{
  case 2:
    /* traitement du champ2 */
  break;
  case 1:
  case 3:
    /* traitement du champ3 */
  break;
  default:
    /* traitement du champ1 */
  break;
}

Si les sont peu utiliser c'est qu'ils sont facilement remplassable.

sauf que pour mon programme ce switch marche mais est tres lourd à programmer... Pourquoi? Parcequ'il il faudrait que je l'écrive cent fois:

En effet, la valeur de ligne [i] ne correspond pas au champ dans lequel se placer, mais au nombre de champs à sauter. Donc le case 3 peut m'emmener dans le champ 3 comme dans le champ 10, et il faudrait que je mette ce switch à chaque fois que je teste la valeur de ligne[i] avec un corps différent. Et du coup je vois pas ce que je gagne en lisibilité.

[calogerogigante]

Une autre piste pour ton problème, à condition que tes ligne[i] renvoit toujours des entiers:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
main(...)
{
traitement_champs(ligne[i]);
 
//....
}
 
void traitement_champs(int nombre)
{
switch(nombre)
  {
   case 1: // traitement champs 1
 
   case 2: // traitement champs 2
 
   case 3: // traitement champs 3
 
  default: // traitement divers...
  }
 
}

Bien sûr, tu modifies le type de retour "void" de la fonction en ce que tu aurais besoin de récupérer éventuellement...

Enfin, c'est dur de proposer une solution sans avoir tous les tenants et les aboutissants du problème...
C'est juste une piste...

[ulukahio]

iagine ce que ça donne avec une centaine de champs, quand tous saufs le dernier ne sont pas présents.... tu marques un if avec cent tests dedans? Pas très lisible tout ça...

Non, je revoie ma façon de codée

je ne demande que ça... Je ne suis absolument pas un programmeur né et je ne demande qu'à faire des progrès.

[Trap D]

C'est vrai il faut éviter les goto mais parfois c'est bien utile .....
Dans les exemples du SDK de Direct X il y a utilisation de quelques goto .
Ils sont vraiment mauvais programmeurs alors chez M$

Je suis d'accord que chez Micro$oft ils ne sont pas complètement nuls, mais quand même, ils pourraient faire quelques efforts :
Tiré de MSDN

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
BOOL ProcessCmdLine(LPSTR lpCmdLine, LPDWORD pdwRegisterCF,
               LPDWORD pdwRegisterActiveObject, int nCmdShow)
{
   LPCLASSFACTORY pcf = NULL;
   HRESULT hr; 
   *pdwRegisterCF = 0;
   *pdwRegisterActiveObject = 0;
 
   // Expose class factory for application object if command line
   // contains the /Automation switch.
   if (_fstrstr(lpCmdLine, "-Automation") != NULL
      || _fstrstr(lpCmdLine, "/Automation") != NULL)
   {
      pcf = new CApplicationCF;
      if (!pcf)
         goto error;
      pcf->AddRef();
      hr = CoRegisterClassObject(CLSID_Lines, pcf,
                        CLSCTX_LOCAL_SERVER, REGCLS_SINGLEUSE,
                        pdwRegisterCF);
      if (hr != NOERROR)
         goto error;
      pcf->Release();
   }
   else            // Show window if started as stand-alone. 
   g_pApplication->ShowWindow(nCmdShow );
 
// Register Lines Application object in the running object table 
// (ROT). Use weak registration so that the ROT releases its reference
// when all external references are released.
   RegisterActiveObject(g_pApplication, CLSID_Lines, ACTIVEOBJECT_WEAK,
         pdwRegisterActiveObject);
   return TRUE;
 
error:
   if (pcf)
      pcf->Release();
   return FALSE;
}

Le goto est-il vraiment utile ici ??

[DavG]

En effet, la valeur de ligne [i] ne correspond pas au champ dans lequel se placer, mais au nombre de champs à sauter.

Peux-tu poster ton code de traitement de champs qu'on comprenne un peu plus ce que tu veux dire ?

[ulukahio]

Oui je suis d'accord avec toi, mais ce n'est pas dans ce type de circonstances que je compte utiliser goto.

(on est à l'intérieur d'une boucle while qui lit une par une les lignes d'un fichier texte)

Si quelqu'un pouvait me donner un code propre et sûr correspondant à celui ci:

if (ligne[i]==2) //le chiffre correspond au nombre de champs non présents dans la base d'origine
goto champ2;
else if (ligne[i]==3)
goto champ3;
else{ //traitement du champ1}

champ2: //traitement du champ2

if (ligne[i]==1)
goto champ3;

champ3: //traitement du champ 3

Là par contre, en effet, je trouve déjà l'utilisation du goto risquée... Très risquée...

Plutôt d'accord avec les propositions des deux posts au-dessus de celui-ci...

En quoi cette utilisaation est elle risquée? (par contre trap D, si on pouvait éviter de faire dévier le topic sur l'incapacité à programmer des gens de grosoft ça m'arrangerait )

[gege2061]

Tiré de MSDN

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<...>

Le goto est-il vraiment utile ici ??

Effectivement dans ce cas, il est possible de faire une fonction mais je trouve que le programme est clair quant même. Je n'est pas mis plus de temps à comprendre le programme que s'il y avait eu une fonction. Contrairement au code de ulukahio.

[ulukahio]

En effet, la valeur de ligne [i] ne correspond pas au champ dans lequel se placer, mais au nombre de champs à sauter.

Peux-tu poster ton code de traitement de champs qu'on comprenne un peu plus ce que tu veux dire ?

un exemple: le fichier original contient une centaine de champs présentés comme suit:

Michel; Barnier; 21rue machin; c'est la fête

mais si le premier champ n'est pas présent, on a:

1; Barnier; 21rue machin; c'est la fête

si le premier et le deuxième ne sont pas présents, on a:

2; 21rue machin; c'est la fête

Si le premier, le deuxieme et le troisieme ne sont pas présents:

3; c'est la fête

Si le deuxieme n'est pas présent:

Michel; 1; 21rue machin; c'est la fête

Si le deuxieme et le troisieme ne sont pas présents:

Michel; 2; c'est la fête

Et ainsi de suite...

[calogerogigante]

Au plus tu rajoutes de "petits jump" à saute mouton au-dessus de petits bouts de code, au plus tu risques de louper une étape logique du déroulement de ton code... Surtout si tu dis toi-même qu'il risque d'y avoir une centaine de traitements de champs...

Je ne suis pas foncièrement contre, mais je trouve cela dangereux car tu risques de louper plus facilement une incohérence dans ton code...
A moins d'être sûr de ce que tu fais à 100 % (exemple: t'as écrit un petit ordinogramme clair qui représente toutes les possibilités de cette partie de ton programme utilisant les gotos...), alors OK...

Mais à mon avis: ordonner les choses clairement avec un switch, dans ton cas, serait beaucoup plus propre et plus lisible... Notamment en cours de déboguage...

[HRS]

il faut se rappeler que les instructions "return", "break", "continue"
sont des "goto" déguisés et maîtrisés

par contre il n'existe aucune instruction pour sortir élégamment de
2 boucles imbriquées. à part "goto".

[jack69]

En fait, le pb pour éviter les goto est souvent un problème d'algo.
Ne pourrais-tu pas mettre en place un code à base de pointeur ?
1 -Tu fais pointer le pointeur sur le champ1,
2 - tu récupères le nombre de champ à sauter,
3 - tu incrémentes ton pointeur du nombre de champ correspondant
4 - tu appelles mon_traitement (mon_pointeur) ?

Bien sur ne connaissant pas ton code et ton traitement il n'est pas sûr que cela soit réalisable...

Mais généralement il est fortement conseiller de mettre en place une solution sans goto (pourquoi ? .... Parce que.... )

[ronan99999]

le 'no goto ' me fait aussi penser à certaines personnes qui vont te dire de ne surtout pas utiliser le 'switch' parceque c'est pas compilé de maniére optimum, que le 'continue' dans un while n'est pas propre parceque tu ne respectes pas ta condition de sortie etc....

n'empeche que un beau et magnifique goto bien placé et ben c'est tres propre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
 
piVar = (int*) calloc(SIZE,sizeof(int));
if(!piVar )
goto labelError;
 
/*traitement*/
 
return 0;
labelError:
return -1;

[ulukahio]

Au plus tu rajoutes de "petits jump" à saute mouton au-dessus de petits bouts de code, au plus tu risques de louper une étape logique du déroulement de ton code... Surtout si tu dis toi-même qu'il risque d'y avoir une centaine de traitements de champs...

Je ne suis pas foncièrement contre, mais je trouve cela dangereux car tu risques de louper plus facilement une incohérence dans ton code...
A moins d'être sûr de ce que tu fais à 100 % (exemple: t'as fait un petit organigramme clair qui resprésente toutes les possibilités de cette partie de ton programme utilisant les gotos...)

A mon avis: ordonner les choses clairement avec un switch (dans ton cas) serait beaucoup plus propre et plus lisible..

J'ai peut être un gros problème mais je ne vois pas de solutions simple avec un switch...
PS: j'ai fait un organigramme clair, j'ai rajouté énormément de tests et j'ai beaucoup de temps pour le débuggage, et comme les noms des étiquettes que j'utiliserai seraient très explicites, le risque d'erreur me parait plutôt faible.

[jack69]

Le traitement des champs est-il toujours le même ?

[calogerogigante]

le risque d'erreur me parait plutôt faible.

Le propre de la programmation: c'est qu'il y a cent façons différentes de faire la même chose... T'es libre, malgré tout ce qu'on peut dire, de choisir ta méthode...

N'empêche qu'en cas de problème... Ca peut devenir un casse-tête les gotos multipliés exagérement !!

Mais au fond, l'important, c'est que ça tourne convenablement... Surtout si c'est pour un client...

C'est mon avis, et je le partage !!
;-)

[Trap D]

Comment sont organisés ces fameux champs, ils sont nommés, numérotés ?

[ulukahio]

Le traitement des champs est-il toujours le même ?

Non ce n'est jamais le même, et c'est bien là le problème, puisque je traite le contenu de chaque champ pour le formater selon les besoins de ma base d'arrivée.

et calogerogigante heureusement que je suis libre, mais c'est juste que pour l'instant je ne vois pas de solutions qui ne rajoute pas environ 10 000 lignes de codes à mon problème dans ce que l'on me propose .

(Merci à tous pour votre aide, je ne pensais pas que ce sujet déchainerai autant les passions)