Discussion :

[francois1990]

Bonjour � tous, je suis nouveau dans la communaut�.
effectivement rien de plus anormal, puisque je d�bute en C++.

Certain font d�j� demi-tour en se disant... un d�butant, encore un qui veux cr�er un MMoRPG. :p
Et bien non, mon premier but est de cr�er des petits jeux basiques sur console (pendu, trouver le mots, pacman, etc) vous saisissez l'id�e.
par la suite, �videmment, je ne veux pas rester coincer dans le mode console, j'aimerai pouvoir cr�er des petits jeux (en exemple: heu ... le genre de jeux qu'on retrouve sur tablette). en fait, je n'aimerai pas ... je veux (on m'a dis que vouloir c��tait d�j� une belle preuve de d�termination) :p

je suis conscient du travail que cela repr�sente... et surtout du long l'apprentissage. c'est pour cela que je le dis tout de suite, je ne compte pas bruler les �tapes et faire ca bien!

bon oui, c'est vrai j'ai commencer a apprendre le c++ il y a 3 jours et mes ambitions sont d�j� importantes... oui mais, ne faut il pas avoir un but reel pour avancer?

donc voila, je vais vous pr�senter un code �crit hier. le but �tait de cr�er une fonction et de l'appeler dans le main.

la fonction permet d'ajouter de l'xp a un xp initial et de d�terminer le lvl en fonction de l'xp initial.

j'aimerai avoir quelques �claircissement sur mon code :

- est ce que cette fonction est utile (pour que mon main() soit moins lourd visuellement)
- est ce qu'il y a moyen d�am�liorer cette fonction (pas d'y ajouter des choses, mais plut�t de simplifier son �criture)

enfin, tout conseil est bon a prendre. n�h�sitez pas.
je veux vraiment coder proprement.
s'il vous plais, essayez de ne pas parlez trop technique pour l'instant, on risque de ne pas se comprendre... enfin, essayez, juste un peu.

voila le code xplvl.cpp :

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
40
41
42
43
44
45
46
47
48
49
50
51
52
 
#include "xplvl.h"
 
void ajouteXp(int& xpIni, int newXp, int& gainLevel)
{
    xpIni += newXp;
 
    if (xpIni>=0 && xpIni<100)
    {
        gainLevel = 0;
    }
    if (xpIni>=100 && xpIni<300)
    {
        gainLevel = 1;
    }
    if (xpIni>=300 && xpIni<600)
    {
        gainLevel = 2;
    }
    if (xpIni>=600 && xpIni<1000)
    {
        gainLevel = 3;
    }
    if (xpIni>=1000 && xpIni<1600)
    {
        gainLevel = 4;
    }
    if (xpIni>=1600 && xpIni<2400)
    {
        gainLevel = 5;
    }
    if (xpIni>=2400 && xpIni<3600)
    {
        gainLevel = 6;
    }
    if (xpIni>=3600 && xpIni<4800)
    {
        gainLevel = 7;
    }
    if (xpIni>=4800 && xpIni<6200)
    {
        gainLevel = 8;
    }
    if (xpIni>=6200 && xpIni<7900)
    {
        gainLevel = 9;
    }
    if (xpIni>=7900)
    {
        gainLevel = 10;
    }
}

voila le code xplvl.h :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
 
#ifndef XPLVL_H_INCLUDED
#define XPLVL_H_INCLUDED
 
void ajouteXp(int& xpIni, int newXp, int& gainLevel);
// fonction qui ajoute l'xp recue à l'xp initial et calcul gain level en fonction de l'xp^initial.
// variable entrente : xpini, newxp, gain level.
// aucune valeur retournée. car référence.
 
#endif // XPLVL_H_INCLUDED

et mon main :

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
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
 
#include <iostream>
#include "xplvl.h"
using namespace std;
 
int main()
{
    int xpJoueur(0), xpGagne(0), level(0);
    cout<<"joueur a "<<xpJoueur<< "xp."<<endl;
 
    cout<<"joueur gagne 30 xp."<<endl;
    xpGagne = 30;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
    cout<<"joueur gagne 35 xp."<<endl;
    xpGagne = 35;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
    cout<<"joueur gagne 125 xp."<<endl;
    xpGagne = 125;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
    cout<<"joueur gagne 113 xp."<<endl;
    xpGagne = 113;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
    cout<<"joueur gagne 200 xp."<<endl;
    xpGagne = 200;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
    cout<<"joueur gagne 127 xp."<<endl;
    xpGagne = 127;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
    cout<<"joueur gagne 321 xp."<<endl;
    xpGagne = 321;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
    cout<<"joueur gagne 186 xp."<<endl;
    xpGagne = 186;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
    cout<<"joueur gagne 54 xp."<<endl;
    xpGagne = 54;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
    cout<<"joueur gagne 652 xp."<<endl;
    xpGagne = 652;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
    cout<<"joueur gagne 1243 xp."<<endl;
    xpGagne = 1243;
    ajouteXp(xpJoueur, xpGagne, level);
    cout<<"le joueur a "<<xpJoueur<<" xp."<<" lvl : "<<level<<endl<<endl;
 
 
    return 0;
}

voila ce que donne la console :

[white_tentacle]

Plusieurs remarques :

- la premi�re, c�est le nom des param�tres. En ce qui me concerne, j�aime bien les param�tres avec des noms explicites, pas trop les abr�viations. Donc plut�t que xpIni, xpInitial.
- la deuxi�me, c�est que les param�tres doivent avoir un nom qui correspondent � ce qu�il sont / font. Or ici, je vois :
* xpIni qui est aussi la valeur utilis�e pour les xps de retour --> pourquoi pas plut�t playerXp ?
* newXp qui est en r�alit� les xps suppl�mentaires --> additionalXp ?
* gainLevel qui est en r�alit� le niveau � actuel � du personnage, non ?
- la troisi�me, c�est que ajouter des xps et savoir quel est le niveau � partir du nombre d�xps sont deux choses diff�rentes, non ? Donc je ferais plut�t une fonction qui donne, � partir d�un nombre d�xps donn�s, le niveau actuel du personnage.

Voil� pour le premier jet de remarques.

[prgasp77]

Bonjour et bienvenu !

C'est une bonne chose que tu te rendes compte du travail qu'il te faudra accomplir, que tu souhaites avancer progressivement et que tu te focalises sur ta fa�on de faire autant que sur le r�sultat. Le code que tu as pr�sent� est un bon d�but, il a l'avantage d'�tre simple � lire. Et �a c'est beaucoup. Voici quelques axes d'am�lioration :

1. Prototype de ta fonction ajouteXp
   • Cette fonction prend un gain d'xp en entr�e et sors un total d'xp et un niveau. Elle fait donc deux choses. Devrait-il y avoir deux fonctions ? Ces deux fonctions auraient-elles � gagner en synergie en �tant deux m�thodes d'une m�me classe dont les objets repr�senteraient le niveau d'un personnage ... ou pour �tre plus pr�cis quelque chose qui peut avoir un niveau ?
   • Dans le cas contraire (on reste sur l'id�e d'une unique fonction), il est d'usage de mettre tous les param�tres de sortie (ici gainLevel et xpIni) "� c�t�" dans la liste des param�tres (ex : void ajouteXp(int& xpIni, int& gainLevel, int newXp)
   • Il serait de bon aloi de documenter ta fonction en explicitant ce qu'elle fait, ce qu'elle prend en entr�e, ce qu'elle retourne en sortie, ses effets de bords, son comportement quand l'entr�e n'est pas telle qu'attendue, etc. Cette documentation peut prendre la forme de commentaires C++, tout simplement.
   
   
2. S�paration des donn�es et de l'impl�mentation.
   Dans le corps de la fonction ajouteXp, des constantes apparaissent d�finissant les limites de niveau. Id�alement, ces donn�es seraient s�par�es du traitement, d�finies dans une structure de ton choix (un liste de constantes, un tableau, ou tout autre chose). Ton impl�mentation utiliserait ensuite ces donn�es pour calculer le niveau correspondant � l'XP. De la sorte, si tu veux modifier une limite de niveau, ou d�finir la limite pour un nouveau niveau, il n'y a qu'une partie du code � changer.
3. Divers
   
   • Enl�ve-moi donc cet horrible using namespace std et prends l'habitude, d�s maintenant, d'�crire std::cout, std::vector, std::string, etc. Ce n'est pas si long, et �a a l'avantage d'�viter les conflit de noms et d'expliciter imm�diatement au lecteur qu'il s'agit de classes/d'objet de la SLT et non des d�finitions locales.
   • Montre nous tes options de compilations que l'on te les pourrisse un peu

Au sujet de ton apprentissage � proprement parler, quel(s) livre(s)/tutoriel(s) suis-tu ? Fait bien attention � ce qu'il(s) soient r�cents (pas apr�s 2008--2010).
Au plaisir de te voir fr�quemment parmi nous.

[francois1990]

white_tentacle, merci pour ta r�ponse.
j'ai pris en compte tes remarque quant aux noms donn� dans ma fonction.
il est vrai qu'avec les noms que tu m'a propos�, c'est nettement plus explicite.

pour ton troisi�me point : je me suis justement dis, qu'une fonction ne doit elle pas �tre bien fournie pour �tre int�ressante?

l�exp�rience d'un joueur �volue tout au long d'un jeu, en fonction de l�exp�rience, le niveau du joueur augmente. les deux sont donc li�... plut�t que de faire deux fonction, je l'ai r�duite � une seule. je pensais que c'�tait une bonne chose.

quel est le r�el probl�me de cette fonction � deux utilit�s?



prgasp77, tu as toi aussi pris le temps de r�pondre a mes question, milles merci.
que veux tu dire par : "Ces deux fonctions auraient-elles � gagner en synergie en �tant deux m�thodes d'une m�me classe dont les objets repr�senteraient le niveau d'un personnage ... ou pour �tre plus pr�cis quelque chose qui peut avoir un niveau ?"

en attendant, j'ai tout de m�me suivi ton conseil de mettre les param�tres de sorties les uns a cot� des autres. c'est un petit d�tail, mais a la lecture c'est plus fluide.

pour la documentation de la fonction, en fait j'ai fais un petit r�sum� dans mon fichier .h
il y a juste son comportement quand l'entr�e n'est pas telle qu'attendue, que je n'ai pas fait (d'ailleur je n'ai pas prevu ca non plus)
pourquoi l'entr�e ne serait elle pas telle qu'attendue ?
en programment un jeu ou un personnage gagnera de l'xp, l'xp gagn�e est implant�e dans le jeu pour chaque mission, donc si la programmation est bien faite, il ne devrait pas y avoir de probl�me au niveau des entr�es non?

pour le point 2., je t'avoue ne pas avoir trop compris :p

"prends l'habitude, d�s maintenant, d'�crire std::cout, std::vector, std::string, etc." et je dois noter cela pour chaque type de variable utilis�?


"Montre nous tes options de compilations que l'on te les pourrisse un peu" heu, je souffre vraiment de d�butantisme la :p


pour l'instant j'utilise les cours du sites du zero initialement. c'est pas le top, mais bon :/

[prgasp77]

prgasp77, [...] que veux tu dire par : "Ces deux fonctions auraient-elles � gagner en synergie en �tant deux m�thodes d'une m�me classe dont les objets repr�senteraient le niveau d'un personnage ... ou pour �tre plus pr�cis quelque chose qui peut avoir un niveau ?"

Je me suis un peu emball� l� ... ces notions arriveront plus tard quand tu apprendras la programmation orient�e objet. Mais je reste sur mon id�e que deux fonctionnalit�s = deux fonctions. Moins une fonctions fait de choses, plus elle est riche, car pr�cise, concise, et exempte de bug.

pour la documentation de la fonction, en fait j'ai fais un petit r�sum� dans mon fichier .h

Tr�s bien.

il y a juste son comportement quand l'entr�e n'est pas telle qu'attendue, que je n'ai pas fait (d'ailleur je n'ai pas prevu ca non plus)
pourquoi l'entr�e ne serait elle pas telle qu'attendue ?

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
int xpIni = 0;
int gainLevel = 0;
ajouteXp(int& xpIni, -1, int& gainLevel);

en programment un jeu ou un personnage gagnera de l'xp, l'xp gagn�e est implant�e dans le jeu pour chaque mission, donc si la programmation est bien faite, il ne devrait pas y avoir de probl�me au niveau des entr�es non?

Il y en aura. Un jour. S�r. 100%. Un programme �a vie, �a �volue. On revient sur son code des ann�es apr�s. Certains jours on a la t�te ailleurs. D'autres d�veloppeurs peuvent se joindre au projet. bref, quand (et pas "si") �a arrive, on est face � un bug. Si la fonction trucmuche est document�e avec un paragraphe disant "si en entr�e on me donne 18, alors la sortie est invalide" ce sera d'une pr�cieuse aide le jour o� �a arrivera.

pour le point 2., je t'avoue ne pas avoir trop compris :p

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
/**
 * Retourne le niveau d'un personnage ayant totalisé xp points d'expérience.
 */
int niveau(int xp)
{
    const int[] limites_de_niveau = { 0, 1000, 3000, 6000, 10000 }; /* YEAH! ol' style C++98 !! */
    const std::size_t niveau_max = sizeof(limites_de_niveau) / sizeof(limites_de_niveau[0]); /* Pour info, défini niveau_max à 5. Cette construction est classique et permet de récupérer, dans certains cas, le nombre d'éléments d'un tableau. */
 
 
    for (std::size_t niveau = 0 ; niveau < niveau_max ; ++niveau)
    {
        if (xp >= limites_de_niveau[niveau])
        {
            return niveau;
        }
    }
 
    return niveau_max;
}

"prends l'habitude, d�s maintenant, d'�crire std::cout, std::vector, std::string, etc." et je dois noter cela pour chaque type de variable utilis�?

Si tu �cris plus de dix fois le m�me type au sein d'une m�me fonction, dans ma grande mansu�tude, je vais tol�rer using std::quelquechose;, qui dans le bloc courant, permet d'utiliser quelquechose comme tu utiliserais std::quelquechose.

"Montre nous tes options de compilations que l'on te les pourrisse un peu" heu, je souffre vraiment de d�butantisme la :p

Normal. Quel environnement de d�veloppement utilises-tu ? Syst�me d'exploitation ? IDE (Code::Blocks ? Microsoft Studio ? ...) ? On te guidera pour activer ce qu'on appelle les warnings de compilation qui demande au compilateur de te relever tous les �l�ments qui lui semblent �tranges et qui pourraient �tre une erreur ou une mauvaise habitude.

pour l'instant j'utilise les cours du sites du zero initialement. c'est pas le top, mais bon :/

Effectivement, pas top. Un habitu� des cours de dvp aurait une suggestion avant qu'il ne soit trpo tard ?

[koala01]

white_tentacle, merci pour ta r�ponse.
j'ai pris en compte tes remarque quant aux noms donn� dans ma fonction.
il est vrai qu'avec les noms que tu m'a propos�, c'est nettement plus explicite.

pour ton troisi�me point : je me suis justement dis, qu'une fonction ne doit elle pas �tre bien fournie pour �tre int�ressante?

Non, au contraire : il existe un principe nomm� SRP (pour Single Responsability Principle ou, si tu p�f�res "principe de la responsabilit� unique" en francais) qui stipule que chaque fonction, chaque type ne doit s'occuper que d'une seule et unique chose, mais qu'il/elle doit s'en occuper correctement.

L'id�e au niveau des fonction est que tu auras surement des fonctions dont la responsabilit� unique est complexe, mais que tu peux cr�er des fonctions beaucoup plus simples ne prenant qu'une partie bien sp�cifique de cette responsabilit� en charge et que ces fonctions plus simples seront plus facilement utilisables, par exemple, en changeant l'ordre dans lequel elles sont appel�e.
Imaginons que tu veuille cr�er une fonction (c'est in, la domotique ) qui lance le caf�, fait la lessive, fait la vaisselle et sort le chien avant d'aller faire les courses.

Tu peux, bien sur, cr�er une seule fonction qui fait tout cela � la suite. Mais ca te fera une fonction de surement 150 lignes .


Un peu plus tard, tu risque d'avoir besoin d'une fonction qui fait la lessive, sort le chien, va faire les courses, fait la vaisselle avant de pr�parer le caf�. Tu auras remarqu� qu'il s'agit de faire exactement les m�mes choses, mais dans un ordre diff�rent. Si tu avais 150 lignes de code dans la premi�re fonction, tu auras aussi 150 lignes dans celle-ci

Et comme tu es fain�ant (en tout cas, je le suis moi), tu vas te "contenter" d'un gros copier / coller du code avant de le r�organiser pour qu'il s'ex�cute dans le bon ordre.

Plus tard encore, tu voudras une troisi�me fonction qui fait exactement les m�mes choses dans un ordre diff�rent. Puis une quatri�me, une cinqui�me et une sixi�me... Et comme il est possible d'avoir 120 combinaisons diff�rentes, tu pourras en rajouter encore tout plein

Mais, un jour, tu auras un client qui se plaint que son chien pisse syst�matiquement sur le tapis persan lorsqu'on fait les courses tout de suite apr�s avoir sorti le chien. L'un dans l'autre, cette description du probl�me devrait t'inciter � essayer de corriger une bonne 30aine de fonctions. Sauf que tu peux avoir la certitude que tu en oubiera l'une ou l'autre.

Et puis, le probl�me n'est pas que l'on aille faire les courses apr�s avoir sorti le chien... c'est qu'on sort le chien 25 minutes alors qu'il aurait fallu le sortir une grosse demi-heure, qu'il ait l'occasion de se vider correctement la vessie

Tu croiras donc avoir corrig� le probl�me, mais tu peux avoir la certitude que, tot ou tard, tu sera de nouveau confront� � un probl�me similaire (le chien qui pisse sur le tapis persan), simplement parce que l'ordre des actions est diff�rent.

Maintenant, imaginons que l'on cr�e une fonction qui ne s'occupe que de faire le caf�, une autre qui ne s'occupe que de faire la vaisselle, une troisi�me qui ne s'occupe que de faire la lessive, une quatri�me qui ne s'occupe que de sortir le chien et une cinqui�me qui ne s'occupe que d'aller faire les courses.

Les 120 combinaisons possibles des fonctions "complexes" peuvent �tre impl�ment�es tr�s facilement en modifiant l'ordre dans lequel ces diff�rentes fonctions sont appel�es. Et, si tu re�ois un rapport de bug disant que le chien pisse sur le tapis persan du client, tu n'en a rien � foutre de savoir l'ordre dans lequel les diff�rentes actions sont prises : c'est parce que tu ne prom�ne pas le chien pendant assez longtemps.

Tu augmente donc le temps de la ballade et tu as la garantie (pour autant que cela ait effectivement permis de r�soudre le probl�me) que le probl�me est r�solu pour les 120 combinaisons possibles, et que le chien ne pissera plus jamais � l'int�rieur.

l�exp�rience d'un joueur �volue tout au long d'un jeu, en fonction de l�exp�rience, le niveau du joueur augmente. les deux sont donc li�... plut�t que de faire deux fonction, je l'ai r�duite � une seule. je pensais que c'�tait une bonne chose.

Non, et je viens de t'expliquer pourquoi (par contre, il n'est pas exclu que tu aies une fonction qui augmente l'exp�rience du joueur et qui, lorsque l'on atteint un certain nombre de point d'exp�riences, d�cide d'appeler la fonction qui s'occupe d'augmenter le niveau )

quel est le r�el probl�me de cette fonction � deux utilit�s?

Dans le cas bien particulier que tu cite, pour �tre tout � fait honn�te : aucun.

Dans le cas g�n�ral, pose toi simplement une seule question : Et Si...?

Et si on voulait changer l'ordre dans lequel sont faites les deux choses?

ou pire

Et si on voulait une nouvelle fonction inversant l'ordre dans lequel les deux choses sont faites, tout en gardant la premi�re version?

ou encore

Et si j'acc�pte q'une fonction ait deux utilit�s, ne vais-je pas avoir tendance d'en accepter une qui en a 3, 4, 5... 10...100? quelle sera la limite?

pourquoi l'entr�e ne serait elle pas telle qu'attendue ?

Parce que l'utilisateur est -- au mieux -- un imb�cile distrait, au pire, quelqu'un qui cherche � acc�der � un niveau de contr�le auquel il ne devrait pas avoir acc�s

pour le point 2., je t'avoue ne pas avoir trop compris :p

"prends l'habitude, d�s maintenant, d'�crire std::cout, std::vector, std::string, etc." et je dois noter cela pour chaque type de variable utilis�?

Pour tout ce qui est issu de la SL (la biblioth�que standard), en tout cas, oui.

PS: peut-�tre mon livre (lien en signature) te permettra-t-il d'am�liorer encore la mani�re dont tu �cris ton code (et ta conception de mani�re g�n�rale)

[francois1990]

donc je prend note : il est plus int�ressant de cr�er des fonctions qui ne s'occupe que d'une chose

std::cout, std::vector, std::string, etc ... je dois placer tout ca ou ?

Pour la question, j'utilise code::blocks
oui ce serai cool d'avoir un rapport du logiciel lorsqu'il trouve des choses bizarres

[koala01]

donc je prend note : il est plus int�ressant de cr�er des fonctions qui ne s'occupe que d'une chose

Ouaip

std::cout, std::vector, std::string, etc ... je dois placer tout ca ou ?

L� o� tu en as besoin, par exemple :
au lieu d'�crire le code

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
#include <string>
using namespace std;
int main(){
    string str{"Hello world"};
    /* ... */
}

tu �criras le code

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
#include <string>
int main(){
    std::string str{"Hello world"};
    /* ... */
}

au lieu d'�crire le code

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
#include <iostream>
using namespace std;
int main(){
    cout<<"I'm happy";
    /* ... */
}

tu �criras le code

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
#include <iostream>
 
int main(){
    std::cout<<"I'm happy";
    /* ... */
}

et ainsi de suite