Discussion :

[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)

[ulukahio]

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

Ils n'ont pas de noms, pas de numéros, ils sont exactement comme je l'ai présenté quelques posts au dessus, les ";" étant les séparateurs.

[Ti-R]

...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;

C'est pas beau
Je préfère:

Code :

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

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

Et un switch est une bonne solution je pense...
Si tu as un début de code à nous montrer (un bout à traiter et un bout de code implémenter sur le traitement...)

[jack69]

ce que je ferais (mais bon en soft il existe n solutions pour le mm pb) :

Une fonction de traitement qui prend en parametres l'indice du champ, et qui applique le formatage désiré :

Code :

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

1
2
3
4
5
6
7
<....>
switch (indice)
{
   case 1 : traitement 1
   case 2 : traitement 2
   ....
}

Et une fonction qui détermine l'indice du champ (en supposant que taille = nb max de champ):

Code :

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

1
2
3
4
5
6
indice = 0;
while (indice<taille)
{
   /*on détermine si indice est incrémenté de 1 ou de plus (si champ =2) */
   traitement(indice)
}

La difficulté étant comment je sais que je réalise indice++ ou indice+=2...
Mais ca tu dois savoir le faire, même pour les goto.

[Trap D]

Ta base de données est bien organisée en articles (des "lignes") comportant des champs séparés par des ";" non ?

[ulukahio]

ce que je ferais (mais bon en soft il existe n solutions pour le mm pb) :

Une fonction de traitement qui prend en parametres l'indice du champ, et qui applique le formatage désiré :

Code :

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

1
2
3
4
5
6
7
<....>
switch (indice)
{
   case 1 : traitement 1
   case 2 : traitement 2
   ....
}

Et une fonction qui détermine l'indice du champ (en supposant que taille = nb max de champ):

Code :

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

1
2
3
4
5
6
indice = 0;
while (indice<taille)
{
   /*on détermine si indice est incrémenté de 1 ou de plus (si champ =2) */
   traitement(indice)
}

La difficulté étant comment je sais que je réalise indice++ ou indice+=2...
Mais ca tu dois savoir le faire, même pour les goto.

Ben voilà une idée qu'elle est bonne, je crois que je vais partir là dessus... (mince j'ai presque honte, c'est idiot en fait... pourquoi j'ai dit "presque"?). Au temps pour moi. Je m'en vais dormir un peu ce soir, on dirait que plusieurs mois de suite à récupérer des fichiers ça me réussit pas. bon ben merci à tous pour votre participation active, et à jack69 qui a la palme de la pertinence.

[Mac LAK]

Il sont trés utiles pour sortir d'une multitude de boucle imbréqué.

Pour faire écho, ils peuvent (et pas doivent, attention !) être carrément cruciaux, notamment lorsque le langage ne supporte pas le concept d'exceptions !!!
C'est impératif, par exemple, pour réaliser une simili-clause "Try..Finally" en C.

Après, c'est comme tout : c'est "dangereux" à utiliser parceque l'on peut arriver à peu près n'importe où, que l'on ne peut pas "transférer" de variables au passage (sauf "globales" au bloc courant), et que le source est assez illisible. Ce n'est pas plus risqué que d'utiliser malloc ou fopen sans tester le résultat, mais je déconseille formellement aux débutants de s'amuser à tripatouiller le goto sans auparavant maîtriser les structures habituelles.
Le problème réel du goto en C n'est pas le nommage des étiquettes (because la portée est réduite), mais plutôt le fait de se planter sur la position de l'étiquette elle-même... En général, une ligne trop bas ou une ligne trop haut...

ulukahio : J'ai rarement vu un algorithme requérir impérativement des sauts inconditionnels, même à bas niveau (ASM), à l'exception notable de la gestion des erreurs. Et le source n'a jamais été significativement plus court (ni le code plus rapide) avec des goto...

Je suis plus enclin à penser que tu as un problème de conception, éventuellement au cran immédiatement supérieur de ton programme. Au vu de l'exemple que tu as fourni, ça me semble être un bête analyseur lexical plutôt simple à implémenter (parser + machine à état), j'avoue ne même pas comprendre où tu pourrais bien mettre des "goto" là-dedans... Mais tu ne nous as pas tout dit non plus, comme ce qu'il faut faire ensuite de ces champs (stockage en structure ? Texte ? Requête SQL ?)...

Toutefois, si tu n'as pas de notions de syntaxe/sémantique/traduction, alors effectivement, c'est normal que tu "patauges" un peu sur l'algo à choisir...

[ulukahio]

Ta base de données est bien organisée en articles (des "lignes") comportant des champs séparés par des ";" non ?

Oui mais le problème était qu'il n'y avait pas le même nombre de ";" à chaque ligne, vu que si les champs n'étaient pas remplis, dans la bse on ne retrouvait pas un champ vide, mais pas de champ du tout.

[jack69]

Euh, ne t'emballe pas trop au sujet de ma pertinence. Ma solution est certainement une usine à gaz.
Mais bon, elle est surement mieux que des goto.

N'oublies pas le tag résolu si tu es satisfait....

[ulukahio]

Toutefois, si tu n'as pas de notions de syntaxe/sémantique/traduction, alors effectivement, c'est normal que tu "patauges" un peu sur l'algo à choisir...

Je crois que tu viens de mettre le doigt sur quelque chose d'important, En gros je n'en ai jamais entendu parler, et on m'a balancé des fichiers à récupérer

Et c'est fait pour le tag, mais jack, ta solution est effectivement plus claire que la mienne, même si c'est également une usine à gaz. ( de toutes façon, vu le nombre de champ ça v a être difficile pour un débutant de faire un truc tip top et qui marche)

[Trap D]

Une simple remarque, tu n'as pas été très gaté par la personne qui t'a donné les fichiers à récupérer, car ne rien mettre du tout quand les champs sont vides c'est un peu dur pour un traitement de base de données
Je ne suis pas du tout expert en la matière mais ça me parait fort.

[Trap D]

Tu peux faire une fonction de traitement pour chaque champ et les regrouper dans un tableau et ensuite appeler la fonction correspondantes au numéro du champ, ça évite le switch :
par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
int fn_champ1(void)
{
	puts("champ 1");
	return 1;
}
int fn_champ2(void)
{
	puts("champ 2");
	return 2;
}
 
typedef int (*MyFonc)(void);
 
MyFonc TabFonc[] = {fn_champ1, fn_champ2, ......};

Appel par TabFonc[numero_champ - 1]();

[ulukahio]

Une simple remarque, tu n'as pas été très gaté par la personne qui t'a donné les fichiers à récupérer, car ne rien mettre du tout quand les champs sont vides c'est un peu dur pour un traitement de base de données
Je ne suis pas du tout expert en la matière mais ça me parait fort.

C'est ce que je me dis également . Quand j'ai dis à mon patron que certains champs n'étaient pas là, il voulait que j'arrête de travailler dessus.. Mais bon j'aime pas rester sur un échec alors j'ai continué comme un mulet . Mais je pense que je vais y arriver, et je pense que grâce à vous des gens pourront comprendre ce que j'ai écrit .

Mais bon c'est pas pire que la premiere base de données que j'ai du analyser, (la première fois que je voyais une base de données de ma vie haha), avec des champs cryptés, pas de séparateurs, des champs de taille variable... Une vraie horreur celle là aussi. Enfin on s'égare.

Sinon Mac LAK est ce que tu aurais par hasard un site ou je pourrai trouver des infos sur les analyseurs lexicaux? Pour l'instant sur google je trouve que des trucs pas terribles.

[argoet]

à tous les "Pros" du goto !!
1 - Je vous souhaite de ne pas avoir à debugger un programme truffé de ces petites betes
2 - personnellement je n'ai jamais eu , plus précisement , j'ai toujours pris soint d'éviter le moindre goto dans mes programmes .
3 - Avec l'experience , je peux vous assurer que cette façon de proceder est la meilleur qui soit.