Discussion :

[DaZumba]

je crois que tu n'as pas bien lu le debat

J'evite de lire et de participer aux sujets marques "Debat", en general. Le rapport signal/bruit est trop bas...

Moi ca me choque, je ne trouve pas ca legitime, et de plus quand on a mentionne que c'etait pour les "experimentes", on a donne des cas bien precis (et RARES)..

Donald Knuth avait ecrit en 1974 un papier pour temperer les reactions au papier de Dijkstra (i.e. "pas de goto dans un programme, jamais"). Il listait les constructions ou goto peut etre remplace par autre chose afin d'ameliorer la lisibilite (et/ou l'efficacite) du code, et les constructions ou au contraire goto ameliore cette lisibilite.
Dans ce papier il ecrit:

Sometimes it is necessary to exit from several levels of control, cutting across code that may even have been written by other programmers; and the most graceful way to do this is a direct approach with a go to or its equivalent. Then the intermediate levels of the program can be written under the assumption that nothing will go wrong.

Je suis tout a fait d'accord avec cela. Le probleme de goto, c'est qu'il complique la comprehension du flux de logique d'un programme. Mais un goto error; est completement limpide. Il signifie: "je ne peux pas continuer, je saute a l'endroit ou je vais faire le menage et retourner un code d'erreur".

[koala01]

Mais, en 1974, la méthode algorithmique la plus largement répandue était le flowchart... le nassi-shneiderman (par exemple) ne datant que de deux ans (et et n'étais meme pas plus vieux )

Tres efficace pour concevoir la logique en assembleur ou en langage machine, il faut quand même avouer que le plat de spagetti que peut représenter un flowchart incite assez facilement à utiliser les goto.

Or, et on l'a abondamment justifié dans les pages du débat, si l'on trouve effectivement des cas très particuliers, bien précis et extrêmement rares dans lesquels le goto est effectivement la moins mauvaise de possibilités, la très grosse majorité des cas devraient effectivement suivre la regle du "goto, c'est mal... jamais de goto"...

[DaZumba]

Or, et on l'a abondamment justifié dans les pages du débat, si l'on trouve effectivement des cas très particuliers, bien précis et extrêmement rares dans lesquels le goto est effectivement la moins mauvaise de possibilités, la très grosse majorité des cas devraient effectivement suivre la regle du "goto, c'est mal... jamais de goto"...

Je suis d'accord. Tout ce que je dis est que la gestion d'erreur est un cas particulier, bien precis, et pas si rare que cela pour lequel goto est utile et propre. Et puisqu'il existe des cas particuliers, bien precis, eventuellement rares pour lesquels goto est la meilleure solution, alors, par definition du mot "jamais", la regle "jamais de goto" n'a pas de valeur.
EOT pour moi, je ne voudrais pas diminuer encore le rapport signal/bruit!

[souviron34]

Mais un goto error; est completement limpide. Il signifie: "je ne peux pas continuer, je saute a l'endroit ou je vais faire le menage et retourner un code d'erreur".

Je suis d'accord. Tout ce que je dis est que la gestion d'erreur est un cas particulier, bien precis, et pas si rare que cela pour lequel goto est utile et propre.

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
 
err=0 ;
 
if ( !fonction_qui_peut_merder() )
{
    fprintf(stderr, "oupss\n")
    err= 1;
}
 
if ( (! err) && (!fonction2_qui_peut_merder()) )
{
    fprintf(stderr, "oupss\n")
    err= 2;
}
......
// suite du code
...
 
if ( err )
     return 1;
else
  {
      // libérer la mémoire
      return 0;
  }

C'est pas limpide ???

[termitor]

Ah, ce débat est intéressant, mais voila il ne faut pas se focalise sur le goto mais sur son usage

quand il permet un traitement d'erreur ou une sortie d'une ensemble de boucle et conditionnel , alors ce n'est pas un goto , mais plutôt comme les exemple dans d'autre langage , un "break 2;"

si on se limite a ce genre de cas , on utilise pas toutes les possibilités (horrible) du goto , donc, c'est bien un cas de manque d'instruction dans le langage pour exprime un besoin précis de structurations, essentiellement dans la gestion des erreurs et des interruptions de boucle/condition imbriqué.

Mais un goto utilise pour faire des boucles ou jump dans le corp d'une autres fonction, non ce n'est pas acceptables. (sauf si le langage n'a pas ce genre de structure de contrôle)

Bien a vous.

[Stabia]

la valeur d'un programmeur est inversement proportionnel au nombre de goto que l'on trouve dans son code

La valeur d'un programmeur est directement proportionnelle (avec "elle" !) au nombre de Ko. de code fonctionnels qu'il à écrit !

Il vaut mieux deux ou trois "goto" judicieux que 125 tests de trop dans 78 boucles imbriquées uniquement pour faire du "structuré".

[souviron34]

La valeur d'un programmeur est directement proportionnelle (avec "elle" !) au nombre de Ko. de code fonctionnels qu'il à écrit !
.

rate !!!!

La valeur d'un programmeur est directement proportionnelle (avec "elle" !) a la fiabilite de ses programmes.

Point final.

PS: mieux vaut mettre 10 lignes de traitement de conditions d'erreurs que 1 de commenaire "ca a foire"....

Voir les autres debats sur le exit par rapport au return.....

[iMaTh]

Peur etre que goto nuis a la périnité du code ?

Mes profs me disent que ça crée rapidement l'anarchie, ou plutot du code spaghettie donc je l'utilise jamais de chez jamais, et pour le moment je n'en ai pas sentie le besoin.

[FR119492]

Bonjour à tous !

Je pense que tout dépend de ce qu'on veut faire; c'est pourquoi il y a deux philosophies diamétralement opposées:

• Si on veut (ou doit) écrire un programme portable (d'une machine à une autre, d'un programmeur à un autre), il faut faire abstraction des caractéristiques de l'ordinateur sur lequel on travaille et l'instruction GoTo n'a pas de raison d'être.
• Si on veut (ou doit) écrire un programme aussi efficace que possible, en terme de rapidité et de place en mémoire, sur un ordinateur donné, on doit avoir sans cesse à l'esprit les caractéristiques matérielles de cet ordinateur. Or le langage machine de cet ordinateur comporte une instruction de saut inconditionnel, souvent appelée JMP. Comment peut-on la faire exécuter autrement que par un GoTo ?

Jean-Marc Blanc

[Thierry Chappuis]

Bonjour à tous !

Je pense que tout dépend de ce qu'on veut faire; c'est pourquoi il y a deux philosophies diamétralement opposées:

• Si on veut (ou doit) écrire un programme portable (d'une machine à une autre, d'un programmeur à un autre), il faut faire abstraction des caractéristiques de l'ordinateur sur lequel on travaille et l'instruction GoTo n'a pas de raison d'être.
• Si on veut (ou doit) écrire un programme aussi efficace que possible, en terme de rapidité et de place en mémoire, sur un ordinateur donné, on doit avoir sans cesse à l'esprit les caractéristiques matérielles de cet ordinateur. Or le langage machine de cet ordinateur comporte une instruction de saut inconditionnel, souvent appelée JMP. Comment peut-on la faire exécuter autrement que par un GoTo ?

Jean-Marc Blanc

Le langage C ne connait pas d'instruction GoTo, mais goto. Je ne pense pas que l'utilisation de goto en soit pose un problème de portabilité. Le soucis est essentiellement au niveau de la lisibilité du code. En ce qui concerne l'optimisation, optimiser l'algo est souvent bien plus efficace que d'effectuer des micro-optimisations au niveau du code, et les compilateurs modernes font probablement cela mieux que n'importe quel programmeur (en tout cas mieux que la plupart).

Thierry

[Obsidian]

Wahou ! Enfin un vrai trollodrôme dédié pour traiter de cet épineux sujet ! :-) Après avoir lu les 21 pages de ce fil (ouf !), je ne peux m'empêcher de faire à mon tour quelques remarques.

Je trouve le mouvement anti-goto très dogmatique. Beaucoup de gens savent qu'au grand jamais il ne faut utiliser l'instruction interdite, un peu comme la pomme d'Adam et Ève, mais très peu de gens savent réellement pourquoi.

Dijkstra :

Apparement, tout est parti de lui, et la raison principale pour laquelle il faudrait proscrire les goto consiste en le fait qu'un goto est anonyme, provoque juste un saut arbitraire sans expliquer pourquoi, quand les « structures » permettent de définir un type d'action à l'avance et peuvent donc plus facilement être mises en équation. En somme, ce sont les design pattern avant l'heure.

La vraie question est : cette approche est-elle réellement la seule valable ?

Je pense que, dans ce sens, il ne faut pas systématiquement prendre les propos de Dijkstra comme parole d'évangile, même si la contribution de cet homme à l'informatique est remarquable. Les affirmations telles que « considered harmful » et surtout « It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. » sont surtout des marques d'agacement et sortent en général quand on se retrouve à court d'argument.

Il faut se souvenir que Dijkstra était surtout un mathématicien, et donc abordait la discipline de la même façon. C'est à lui que l'on doit également la formule « l'informatique n'est pas plus la science des ordinateurs que l'astronomie n'est celle des téléscopes ». Je pense que c'est dans l'interprétation de cette assertion que l'on va distinguer les pro- et anti-goto. Si la science du traitement de l'information forme les fondations de toute la discipline, je pense néanmoins que celle-ci s'étend beaucoup plus loin.

En particulier, l'implémentation d'un algorithme sur une machine est un métier qui s'est perdu ces dernières années avec l'engouement pour l'uniformisation et les couches d'abstraction. Mais si un algo doit être optimisé de façon scientifique avant même d'être rédigé, je pense qu'une implémentation réellement optimale ne peut être que contextuelle, et en relation avec la machine sur laquelle il est exécuté. Une approche purement mathématique et menée en amont uniquement sera, à mon avis, toujours incomplète.

En bref, les goto sont à proscrire du point de vue de Dijkstra, qui est certes capital, mais qui est loin d'être le seul.

D'un point de vue algorithmique :

Je crois qu'à la base, la croisade anti-goto a dû partir de deux choses : d'une part, le fait qu'à l'époque, les différents paradigmes (telle que l'approche sémantique plutôt que descriptive sur la forme, comme en HTML/XHtml, par exemple) étaient beaucoup plus flous, et d'autre part, que le goto a dû très souvent servir à se sortir d'une impasse.

Or, il est de fait qu'aujourd'hui, le problème est toujours d'actualité. En C, on ne compte plus les exit(1) au milieu d'un bloc pour se sortir d'une erreur fatale, et on compte sur le système d'exploitation pour faire le ménage.

Les flags de sortie de boucle ne sont pas beaucoup mieux, puisqu'ils obligent à utiliser un registre variable au runtime pour pallier un manque dans quelque chose qui pourrait être câblé statiquement. Mieux que cela, l'absence d'argument à break en langage C oblige à faire ce genre de détours alors qu'un tel procédé existait déjà ... en BASIC 128 !

Par ailleurs, il faut se souvenir que les gotos sont l'âme des automates (à états finis), structures de données à part entière et qui ont fait l'objet d'études poussées.

Je pense que ce qui est réellement nocif, c'est de mélanger les deux approches. Moi, je prône, en classe d'algorithmique et de programmation, un retour à l'approche par goto. Pour aller plus loin, j'inciterais les étudiants à essayer de parvenir à leur fins en rédigeant d'une part un programme à structures sans aucun goto (habituel) et d'autre part un programme sans aucune structure, rien qu'avec des gotos.

En se rapprochant d'une structure type automate, cela permettrait d'ailleurs de faire des réductions assez intéressantes.

[cameleon65]

Je considère acceptable l'utilisation d'un goto dans un code si les performances (vitesse d'exécution, quantité de mémoire utilisée et nombre d'instruction machine) sont meilleures que dans un code n'utilisant pas de goto.

Prenons le code de GnuVince:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
/* Avec goto */
int i, j, k;
for (i = 1; i <= 100; i++) {
    for (j = 1; j <= 100; j++) {
        for (k = 1; k <= 100; k++) {
            if (i == 6 && j == 6 && k == 6) {
                printf("Le Diable! Fuyons!\n");
                goto DEVIL;
            }
        }
    }
}
DEVIL:

Je pense que c'est la version de code la plus performante et donc je considère que l'utilisation du goto est correcte/meilleure dans ce cas-ci.

Existe-t'il un code sans goto et ayant de meilleures performances que celui-ci ?

[millie]

Existe-t'il un code sans goto et ayant de meilleures performances que celui-ci ?

Tout simplement avec des fonctions :

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
 
 
fonction truc() {
 int i, j, k;
 for (i = 1; i <= 100; i++) {
     for (j = 1; j <= 100; j++) {
         for (k = 1; k <= 100; k++) {
             if (i == 6 && j == 6 && k == 6) {
                 printf("Le Diable! Fuyons!\n");
                 return;
             }
         }
     }
 }
}
 
 
fonction main() {
  truc();
  faire diable
}

On peut éventuellement mettre un code de retour

[jeroman]

Existe-t'il un code sans goto et ayant de meilleures performances que celui-ci ?

Oui, et ça tient en une seule ligne :

Code :

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

printf("Le Diable! Fuyons!\n");

[Sve@r]

Je considère acceptable l'utilisation d'un goto dans un code si les performances (vitesse d'exécution, quantité de mémoire utilisée et nombre d'instruction machine) sont meilleures que dans un code n'utilisant pas de goto.

Prenons le code de GnuVince:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
/* Avec goto */
int i, j, k;
for (i = 1; i <= 100; i++) {
    for (j = 1; j <= 100; j++) {
        for (k = 1; k <= 100; k++) {
            if (i == 6 && j == 6 && k == 6) {
                printf("Le Diable! Fuyons!\n");
                goto DEVIL;
            }
        }
    }
}
DEVIL:

Je pense que c'est la version de code la plus performante et donc je considère que l'utilisation du goto est correcte/meilleure dans ce cas-ci.

Existe-t'il un code sans goto et ayant de meilleures performances que celui-ci ?

Il y a eu déjà 2 réponses différentes. Je vais y aller de la mienne

Code :

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

1
2
3
4
5
6
int i, j, k;
  for (i = 1; i <= 6; i++)
     for (j = 1; j <= 6; j++)
         for (k = 1; k <= 6; k++);
 
  printf("Le Diable! Fuyons!\n");

Et d'autres langages offrent encore d'autres solutions (comme le Bourne Shell qui peut quitter "n" niveaux de boucle avec "break n").

Mis à part les solutions humoristiques données, ce code constitue un exemple frappant d'utilisation utile du goto. Mais si on veut élever le niveau à un débat plus philosophique, alors on pourra dire que ce n'est pas l'utilisation ou l'abstention du goto qui sont à privilégier... mais simplement éviter l'extrémisme absolu. Ceux qui sont définitivement contre l'utilisation d'un goto "utile" sont tout aussi néfastes que ceux qui veulent le mettre à toute les sauces (spaghetti).
D'ailleurs, il y a une phrase qui résume bien tout ceci et qui dit: "les bons programmeurs respectent les règles, les programmeurs brillants les transgressent parfois". Soyons brillants...

[cameleon65]

Tout simplement avec des fonctions :

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
 
 
fonction truc() {
 int i, j, k;
 for (i = 1; i <= 100; i++) {
     for (j = 1; j <= 100; j++) {
         for (k = 1; k <= 100; k++) {
             if (i == 6 && j == 6 && k == 6) {
                 printf("Le Diable! Fuyons!\n");
                 return;
             }
         }
     }
 }
}
 
 
fonction main() {
  truc();
  faire diable
}

On peut éventuellement mettre un code de retour

Oui, ça serait mieux avec un code de retour, mais bon, la fonction que j'ai cité (celle de GnuVince) est bidon étant donné que le code fera tjrs la même chose...

Par contre, un appel de fonction est moins performant qu'un goto, car il y a le passage de paramètres et d'autres choses sur la pile.

[cameleon65]

Oui, et ça tient en une seule ligne :

Code :

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

printf("Le Diable! Fuyons!\n");

(J'avais pas vu qu'on pouvait faire multi-citer)

Oui, la solution que tu donnes fera sensiblement le même effet, excepté qu'il n'aura pas fait le même traitement... je vais créer une fonction moins bidon...

Il y a eu déjà 2 réponses différentes. Je vais y aller de la mienne

Code :

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

1
2
3
4
5
6
int i, j, k;
  for (i = 1; i <= 6; i++)
     for (j = 1; j <= 6; j++)
         for (k = 1; k <= 6; k++);
 
  printf("Le Diable! Fuyons!\n");

Même chose ici, le résultat affiché à l'écran sera le même, mais le traitement sera différent: dans la version orginale, j et k vont souvent jusqu'à 100 (5 fois au moins), alors que dans cette version j et k ne vont jamais jusqu'à 100.


Et d'autres langages offrent encore d'autres solutions (comme le Bourne Shell qui peut quitter "n" niveaux de boucle avec "break n").

Mis à part les solutions humoristiques données, ce code constitue un exemple frappant d'utilisation utile du goto. Mais si on veut élever le niveau à un débat plus philosophique, alors on pourra dire que ce n'est pas l'utilisation ou l'abstention du goto qui sont à privilégier... mais simplement éviter l'extrémisme absolu. Ceux qui sont définitivement contre l'utilisation d'un goto "utile" sont tout aussi néfastes que ceux qui veulent le mettre à toute les sauces (spaghetti).
D'ailleurs, il y a une phrase qui résume bien tout ceci et qui dit: "les bons programmeurs respectent les règles, les programmeurs brillants les transgressent parfois". Soyons brillants...

Même chose ici, la solution affiche le même résultat à l'écran mais le traitement n'est pas le même que la version orginale. Dans cette dernière, j et k allaient plusieurs fois jusqu'à 100.

[cameleon65]

Voici un version moins bidon:

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
#define NOMBRE_ELEMENTS	10
 
//Le tableau contient des nombres entre -70000 et 70000.
int verifierDiable(int tableau[NOMBRE_ELEMENTS][NOMBRE_ELEMENTS][NOMBRE_ELEMENTS])
{
	int i;
	int j;
	int k;
 
	for (i = 0; i < NOMBRE_ELEMENTS; i ++)
	{
		for (j = 0; j < NOMBRE_ELEMENTS; j ++)
		{
			for (k = 0; k < NOMBRE_ELEMENTS; k ++)
			{
				if (tableau[i][j][k] == 666)
				{
					printf("Le Diable! Fuyons!\n");
 
					goto DEVIL;
				}
			}
		}
	}
 
	printf("Le diable n'y est pas. Nous restons.\n");
 
	DEVIL:
		traitementA();
		traitementB();
		traitementC();
		traitementD();
 
		return tableau[0][0][0] + tableau[6][6][6];
}

Sans utiliser de goto, est-ce possible de faire le même traitement que cette fonction tout en ayant des performances égales ou meilleures ?

[jeroman]

Comme les éléments d'un tableau sont contigus en mémoire, on peut faire quelque chose du style :

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
int verifierDiable(int *tableau)
{
	int compteur;
 
	for (compteur = 0; compteur < NOMBRE_ELEMENTS*NOMBRE_ELEMENTS*NOMBRE_ELEMENTS; compteur ++)
	{
		if (tableau[compteur] == 666)
		{
			printf("Le Diable! Fuyons!\n");
			break;
		}
	}
	if (compteur==NOMBRE_ELEMENTS*NOMBRE_ELEMENTS*NOMBRE_ELEMENTS)
		printf("Le diable n'y est pas. Nous restons.\n");
 
		traitementA();
		traitementB();
		traitementC();
		traitementD();
 
		return tableau[0] + tableau[NOMBRE_ELEMENTS*NOMBRE_ELEMENTS*NOMBRE_ELEMENTS-1];
}

ou une solution moins propre :

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
int verifierDiable(int tableau[NOMBRE_ELEMENTS][NOMBRE_ELEMENTS][NOMBRE_ELEMENTS])
{
	int i;
	int j;
	int k;
	int devil_detected=0;
 
	for (i = 0; i < NOMBRE_ELEMENTS; i ++)
	{
		for (j = 0; j < NOMBRE_ELEMENTS; j ++)
		{
			for (k = 0; k < NOMBRE_ELEMENTS; k ++)
			{
				if (tableau[i][j][k] == 666)
				{
					printf("Le Diable! Fuyons!\n");
					devil_detected=1;
					i=NOMBRE_ELEMENTS;
					j=NOMBRE_ELEMENTS;
					k=NOMBRE_ELEMENTS;
				}
			}
		}
	}
	if (devil_detected==0)
		printf("Le diable n'y est pas. Nous restons.\n");
 
/*
		traitementA();
		traitementB();
		traitementC();
		traitementD();
*/		
 
		return tableau[0][0][0] + tableau[6][6][6];
}

Mais quoi qu'il en soit, les accès du style tableau[i][j][k] sont de toute manière très couteux en mémoire, surtout dans des grosses boucles.
Un accès par pointeur (comme dans le 1er exemple) est plus performant. En allant jusqu'au bout des choses, faudrait voir si un tel code est plus performant :

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
int verifierDiable(int *tableau)
{
	int compteur;
	int *tableau_temp=NULL;
	int devil_detected=0;
 
	tableau_temp=tableau;
	for (compteur = 0; compteur < NOMBRE_ELEMENTS*NOMBRE_ELEMENTS*NOMBRE_ELEMENTS; compteur ++)
	{
		if (*tableau_temp == 666)
		{
			printf("Le Diable! Fuyons!\n");
			devil_detected=1;
			break;
		}
		tableau_temp++;
	}
	if (devil_detected==0)
		printf("Le diable n'y est pas. Nous restons.\n");
 
	traitementA();
	traitementB();
	traitementC();
	traitementD();
 
	return tableau[0] + tableau[NOMBRE_ELEMENTS*NOMBRE_ELEMENTS*NOMBRE_ELEMENTS-1];
}

Mais dans un tel contexte, je crois qu'on pourra difficilement faire mieux quoi qu'il arrive. Car on est de toute façon obligé de scanner le tableau jusqu'à ce qu'on détecte le chiffre diabolique.

[millie]

Oui, ça serait mieux avec un code de retour, mais bon, la fonction que j'ai cité (celle de GnuVince) est bidon étant donné que le code fera tjrs la même chose...

Par rapport à un parcours d'un tableau de taille 100*100*100, je crois que l'appel d'une unique fonction ne change pas grand chose niveau temps

Voici une version de ta fonction :

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
 
 
//Le tableau contient des nombres entre -70000 et 70000.
int verifierDiable(int tableau[NOMBRE_ELEMENTS][NOMBRE_ELEMENTS][NOMBRE_ELEMENTS])
{
  verifierDiableAux(tableau);
  traitementA();
  traitementB();
  traitementC();
  traitementD();
 
  return tableau[0][0][0] + tableau[6][6][6];
}
 
int verifieDiableAux(int tableau[NOMBRE_ELEMENTS][NOMBRE_ELEMENTS][NOMBRE_ELEMENTS])}
 	int i;
	int j;
	int k;
 
	for (i = 0; i < NOMBRE_ELEMENTS; i ++)
	{
		for (j = 0; j < NOMBRE_ELEMENTS; j ++)
		{
			for (k = 0; k < NOMBRE_ELEMENTS; k ++)
			{
				if (tableau[i][j][k] == 666)
				{
					printf("Le Diable! Fuyons!\n");
					return;
				}
			}
		}
	}
 
	printf("Le diable n'y est pas. Nous restons.\n");
}