Ordre de préséance des opérateurs ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

04/09/2007, 10h28
yan
Citation:

Envoyé par doccpu

merde j'ai fais un troll ! :(

non, non, c'est pas "ça peux", mais "ça doit" faire 5*5 = 25

pour la petite phrase que Mongaulois à relevé dans son dernier post était erronée et due a une erreur de raisonnement de ma part, due à une veille trop tardive et est donc complètement hors de propos. Je l'ai d'ailleurs expliqué dans mon dernier post

codiallement

En faite cela va dépendre du compilateur, des optimisations (explique dans les autre réponses).... Donc cela peux faire 25 comme 20, comme autre chose.

Par contre du coup ce code :
Code:

1 2 3 4 5 6 if (test1() ||test2()) { . . . }
va exécuter en premier test1() et :
- si vrai : ne va pas appeler test2
- si faux : va appeler test2

ou, je me trompe?
04/09/2007, 11h02
Jean-Marc.Bourguet
Citation:

Envoyé par doccpu

non, non, c'est pas "ça peux", mais "ça doit" faire 5*5 = 25

On va etre clair:
Code:

1 2 3 int n = 5, x; x = ++n * --n;
est un comportement indefini. N'importe quoi peut arriver a partir du moment ou le code doit etre execute, y compris avant l'execution (je ne connais pas de cas, pour d'autre cas de comportement indefini tel que le dereferencement d'un pointeur nul ou du depassement de capacite des entiers signes, ca c'est deja vu suite a des optimiseurs pousses).

Si tu veux des references, cherche "sequence point" dans la norme et le paragraphe suivant

Citation:

Envoyé par ISO/IEC 14882:1998, 5/4

Between the previous and next sequence point a scalar object shall have its stored value modified at most one by the evaluation of an expression.

(Note: il est bien connu que la formation de la norme n'est pas toujours claire en ce qui concerne les points de sequencement, entre autres problemes, il n'est pas necessairement d'ordre total entre eux; la prochaine norme utilisera un concept different pour expliquer ce genre de choses, entre autres pour specifier des contraintes sur le multi-threads).
04/09/2007, 12h08
aoyou

Citation:

va exécuter en premier test1() et :
- si vrai : ne va pas appeler test2
- si faux : va appeler test2

ou, je me trompe?

Non, c'est parfaitement juste. Les expressions booléennes sont évaluées de gauche à droite et de manière passive.
04/09/2007, 18h00
Aszarsha

Citation:

Envoyé par aoyou

Non, c'est parfaitement juste. Les expressions booléennes sont évaluées de gauche à droite et de manière passive.

Non, de manière paresseuse ! ;)
04/09/2007, 18h21
aoyou

oui oui paresseux
05/09/2007, 10h36
doccpu
Citation:
Envoyé par Mongaulois

En faite cela va dépendre du compilateur, des optimisations (explique dans les autre réponses).... Donc cela peux faire 25 comme 20, comme autre chose.

Par contre du coup ce code :

Code:

1 2 3 4 5 6 if (test1() ||test2()) { . . . }

va exécuter en premier test1() et :
- si vrai : ne va pas appeler test2
- si faux : va appeler test2

ou, je me trompe?
totalement juste :)
05/09/2007, 10h44
doccpu
Citation:
Envoyé par Jean-Marc.Bourguet

On va etre clair:

Code:

1 2 3 int n = 5, x; x = ++n * --n;

est un comportement indefini. N'importe quoi peut arriver a partir du moment ou le code doit etre execute, y compris avant l'execution (je ne connais pas de cas, pour d'autre cas de comportement indefini tel que le dereferencement d'un pointeur nul ou du depassement de capacite des entiers signes, ca c'est deja vu suite a des optimiseurs pousses).

Si tu veux des references, cherche "sequence point" dans la norme et le paragraphe suivant

(Note: il est bien connu que la formation de la norme n'est pas toujours claire en ce qui concerne les points de sequencement, entre autres problemes, il n'est pas necessairement d'ordre total entre eux; la prochaine norme utilisera un concept different pour expliquer ce genre de choses, entre autres pour specifier des contraintes sur le multi-threads).
Je sait pas avec quel compilateur tu compile mais en la matierre j'ai travaillé avec GNU/GCC et VisualStudio 6 et les deux reprennent le comportement que j'ai expliqué plus haut. Les seuls moyens de ne pas obtenir ce résultat sont soit de changer la priorité des opérateur avec des parenthèses soit d'avoir un problème d'effet de bord (ce qui m'étonnerais dans le cas précis sus-cité). La norme mettant la priorité maximale aux opérateurs d'incrémentation et de décrémentation, on ne peux avoir un autre résultat que 5*5=25 dans une configuration et une utilisation standard de ces compilateurs et des pc qui vont les utiliser.
05/09/2007, 11h02
yan

Citation:

Envoyé par doccpu

Je sait pas avec quel compilateur tu compile mais en la matierre j'ai travaillé avec GNU/GCC et VisualStudio 6 et les deux reprennent le comportement que j'ai expliqué plus haut. Les seuls moyens de ne pas obtenir ce résultat sont soit de changer la priorité des opérateur avec des parenthèses soit d'avoir un problème d'effet de bord (ce qui m'étonnerais dans le cas précis sus-cité). La norme mettant la priorité maximale aux opérateurs d'incrémentation et de décrémentation, on ne peux avoir un autre résultat que 5*5=25 dans une configuration et une utilisation standard de ces compilateurs et des pc qui vont les utiliser.

J'ai continué cette partie de cette discution sur le topic C et C++ mythe et realité
05/09/2007, 11h17
Jean-Marc.Bourguet
Citation:

Envoyé par doccpu

Je sait pas avec quel compilateur tu compile mais en la matierre j'ai travaillé avec GNU/GCC et VisualStudio 6 et les deux reprennent le comportement que j'ai expliqué plus haut.

Un comportement indefini, ca peut etre celui auquel tu t'attends, sauf les jours de pleine lune coincidant avec un changement d'heure entre 2h et 3h du matin.

Citation:

Les seuls moyens de ne pas obtenir ce résultat sont soit de changer la priorité des opérateur avec des parenthèses soit d'avoir un problème d'effet de bord (ce qui m'étonnerais dans le cas précis sus-cité).

++ et -- ont des effets de bords

Citation:

La norme mettant la priorité maximale aux opérateurs d'incrémentation et de décrémentation, on ne peux avoir un autre résultat que 5*5=25 dans une configuration et une utilisation standard de ces compilateurs et des pc qui vont les utiliser.

J'aimerais avoir ton raisonnement argumente par des references a la norme. Je te rappelle le mien (ce ne serait pas la premiere fois que j'oublie un passage introduisant une exception dans une regle generale):

dans l'expression
Code:

1 2 x = ++n * --n
il n'y a pas de points de sequencement. Donc le paragraphe deja cite s'applique:

Citation:

Between the previous and next sequence point a scalar object shall have its stored value modified at most once by the evaluation of an expression.

Mais n est un objet scalaire et sa valeur est modifiee deux fois. Donc le programme ne respecte pas la contrainte. Donc tout comportement est possible.
06/09/2007, 01h21
doccpu
Citation:

Envoyé par Jean-Marc.Bourguet

Un comportement indefini, ca peut etre celui auquel tu t'attends, sauf les jours de pleine lune coincidant avec un changement d'heure entre 2h et 3h du matin.

c'est valable avec un language comme delphi mais pas en c++ ou en assembleur.

Citation:

Envoyé par Jean-Marc.Bourguet

++ et -- ont des effets de bords

oui dans des cas exceptionnels ou tu a des additions qui se font avec des incrémentations. ELLE EST OU L'ADDITION DANS LE CAS SUS CITÉ ?

Citation:

Envoyé par Jean-Marc.Bourguet

J'aimerais avoir ton raisonnement argumente par des references a la norme. Je te rappelle le mien (ce ne serait pas la premiere fois que j'oublie un passage introduisant une exception dans une regle generale):

ma norme : C/C++ (GNU/GCC, VISUALStudio 6), C#, VB6, VB.NET, Basic, logo, GRAfcet et plus récement Assembleur intel (doc intel processeur)ainsi qu'une licence en informatique industrielle, 3 ans de développement professionels et 19 ans de développements autodidacte et j'ai que 26 ans (j'ai comencé a 7 ans). tu veux un CV ?
Citation:
Envoyé par Jean-Marc.Bourguet

dans l'expression

Code:

1 2 x = ++n * --n

il n'y a pas de points de sequencement. Donc le paragraphe deja cite s'applique:
que fait tu de la priorité des opérateurs de la norme ?

dans l'ordre décroissant(ligne par ligne):

{},
++,--,
[],
(),
*,/,
+,-,

Citation:

Envoyé par Jean-Marc.Bourguet

Mais n est un objet scalaire et sa valeur est modifiee deux fois. Donc le programme ne respecte pas la contrainte. Donc tout comportement est possible.

c'est pas scalaire t'est pas sous delphi. c'est une variable stoqué en pile et je vais mème te dire mieux n ne signifie rien d'autre pour le compilateur que la valeur stoqué dans une adresse mémoire fixé a l'execution. Alors tu vois que c'est pas si indéfini !
06/09/2007, 04h08
Aszarsha

Citation:

Envoyé par doccpu

c'est valable avec un language comme delphi mais pas en c++ ou en assembleur.

oui dans des cas exceptionnels ou tu a des additions qui se font avec des incrémentations. ELLE EST OU L'ADDITION DANS LE CAS SUS CITÉ ?

ma norme : C/C++ (GNU/GCC, VISUALStudio 6), C#, VB6, VB.NET, Basic, logo, GRAfcet et plus récement Assembleur intel (doc intel processeur)ainsi qu'une licence en informatique industrielle, 3 ans de développement professionels et 19 ans de développements autodidacte et j'ai que 26 ans (j'ai comencé a 7 ans). tu veux un CV ?

que fait tu de la priorité des opérateurs de la norme ?

dans l'ordre décroissant(ligne par ligne):

{},
++,--,
[],
(),
*,/,
+,-,

arrête d'enculer les mouches, c'est pas scalaire t'est pas sous delphi. c'est une variable stoqué en pile et je vais mème te dire mieux n ne signifie rien d'autre pour le compilateur que la valeur stoqué dans une adresse mémoire fixé a l'execution. Alors tu vois que c'est pas si indéfini !

8O8O8O8O8O Oh My God !!!

Tu ne connais même pas l'operateur d'incrémentation et tu es fier...
Pour le coup, c'est toi la mouche en mauvaise posture ; plus sérieusement, tu te mets dans cette position désagréable en clamant de telles inepsies et avec autant de vigueur.
Tu te trompes, sois en sûr !
06/09/2007, 08h41
Luc Hermitte

Hum hum.
"Ligne par ligne". Tu regardes quels sont les deux opérateurs utilisés dans l'exemple de Jean-Marc, et s'ils sont sur la même ligne ou pas.
Oh zut alors, ils sont sur la même ligne. Du coup, ils ont EXACTEMENT LA MÊME priorité.
Que font les compilos ? Ce qu'ils veulent. Chacun des compilos fera toujours la même chose. Mais d'autres feront autre chose (cf le lien que j'ai donné dans l'autre fil). Et ils en ont parfaitement le droit.

Que dit le standard ISO du C++ (et du C aussi) ? Il parle en termes de "points de séquencement", c'est le terme officiel. Jean-Marc a déjà donné un extrait à ce sujet. Les fournisseurs de compilos sont justes tenus de respecter cette approche. Et quand il y "undefined", ils font selon ce qu'ils préfèrent faire. Aujourd'hui, beaucoup font ce que tu constantes avec tes outils, il n'est pas dit que demain un autre outil ne s'y prenne pas autrement sans que cela soit un bug, du compilo, pour autant.

Constater qu'il y a des compilos qui se comportent différemment ne relève en rien de la drosophilie.
06/09/2007, 10h00
Jean-Marc.Bourguet

Citation:

Envoyé par doccpu

c'est valable avec un language comme delphi mais pas en c++ ou en assembleur.

Reference?

Citation:

ma norme : C/C++ (GNU/GCC, VISUALStudio 6), C#, VB6, VB.NET, Basic, logo, GRAfcet et plus récement Assembleur intel (doc intel processeur)ainsi qu'une licence en informatique industrielle, 3 ans de développement professionels et 19 ans de développements autodidacte et j'ai que 26 ans (j'ai comencé a 7 ans). tu veux un CV?

La norme en ce qui concerne le C++, c'est un document de l'ISO intitule ISO 14882:1999 modifie par un autre document de l'ISO datant de 2003.

Au fait, c'est pas bien de faire du tord aux auto-didactes en se reclamant de cet etat. La plupart sont d'ailleurs generalement trop modestes en surestimant ce que le manque d'une formation formelle les prive et il y en a de tres compétents.

Citation:

que fait tu de la priorité des opérateurs de la norme ?

A nouveau,
- ni la norme decrivant le C, ni celle decrivant le C++ ne parle de priorite d'operateurs.
- ni la priorite, ni l'associativite ne fixe de maniere unique un ordre d'evaluation.

Au fait, je ne connais aucun langage fixant un ordre d'evaluation qui le fait comme tu decris...
06/09/2007, 12h53
doccpu

Citation:

Envoyé par Luc Hermitte

Hum hum.
"Ligne par ligne". Tu regardes quels sont les deux opérateurs utilisés dans l'exemple de Jean-Marc, et s'ils sont sur la même ligne ou pas.
Oh zut alors, ils sont sur la même ligne. Du coup, ils ont EXACTEMENT LA MÊME priorité. Que font les compilos ? Ce qu'ils veulent. Chacun des compilos fera toujours la même chose. Mais d'autres feront autre chose (cf le lien que j'ai donné dans l'autre fil). Et ils en ont parfaitement le droit.

oui(même priorité) et non (les compilos font ce qu'ils veulent). dans ce cas (même priorité) ils sont lu par le compilo de gauche a droite et donc ++i sera executé avant --i et de toute facon pour le problème que l'on à traiter (++i * --i) on s'en fout puis que de toutes facon que l'on fasse l'un ou l'autre 'i' aurra toujours la valeur de départ de i donc tout ce débat est un débat d'enculeur de mouche et ne sert qu'a embrouller les nouveaux arrivants avec des problèmes qu'ils ne verrons que 2 ou trois fois dans leur vie alors arretons de se prendre le choux et parlons de trucs plus concrets.

Citation:

Envoyé par Luc Hermitte

Que dit le standard ISO du C++ (et du C aussi) ? Il parle en termes de "points de séquencement", c'est le terme officiel. Jean-Marc a déjà donné un extrait à ce sujet. Les fournisseurs de compilos sont justes tenus de respecter cette approche. Et quand il y "undefined", ils font selon ce qu'ils préfèrent faire. Aujourd'hui, beaucoup font ce que tu constantes avec tes outils, il n'est pas dit que demain un autre outil ne s'y prenne pas autrement sans que cela soit un bug, du compilo, pour autant.

Constater qu'il y a des compilos qui se comportent différemment ne relève en rien de la drosophilie.

Désolé mais si vous avez un peu etudier l'histoire de l'informatique vous sauriez de les outils qui ne respectent pas le standard comportemental et qui ne sont pas compatible avec ce qui a été déjà produit se fait imanquablement ejecter du circuit car je vois mal linux ibm ou aix modifier des centaines de milliers de lignes de codes rien que pour coller aux comportements d'un nouveau compilateur aussi bon soit il.

donc tout ce débat reste un debat de drosphiles compulsifs :pan:

Code:

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 [alpha:~/src]% uname -s -m NetBSD alpha [alpha:~/src]% g++ --version g++ (GCC) 3.3.3 (NetBSD nb3 20040520) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [alpha:~/src]% cat doccpu.cpp #include <iostream> #include <ostream> int main() { int i = 5; std::cout << ++i * --i << std::endl; return 0; } [alpha:~/src]% g++ -Wall -W doccpu.cpp [alpha:~/src]% ./a.out 30 ... [power:~/src]% uname -s -m AIX 00442A5C4C00 [power:~/src]% xlC doccpu.cpp [power:~/src]% ./a.out 30
Citation:

Désolé mais si vous avez un peu etudier l'histoire de l'informatique vous sauriez de les outils qui ne respectent pas le standard comportemental et qui ne sont pas compatible avec ce qui a été déjà produit se fait imanquablement ejecter du circuit car je vois mal linux ibm ou aix modifier des centaines de milliers de lignes de codes rien que pour coller aux comportements d'un nouveau compilateur aussi bon soit il.

Voir ci-dessus ce que donne le compilateur d'IBM pour AIX

Citation:

donc tout ce débat reste un debat de drosphiles compulsifs :pan:

Puisque tu aimes bien, ce genre de choses: :kill:

06/09/2007, 14h17
Médinoc

Citation:

oui dans des cas exceptionnels ou tu a des additions qui se font avec des incrémentations. ELLE EST OU L'ADDITION DANS LE CAS SUS CITÉ ?

Ben non, Ces opérateurs ont toujours des effets de bord: ils modifient une variable.

Citation:

Envoyé par doccpu

oui(même priorité) et non (les compilos font ce qu'ils veulent). dans ce cas (même priorité) ils sont lu par le compilo de gauche a droite et donc ++i sera executé avant --i

perdu, ce n'est pas défini par la norme. S'il n'y a pas de point de séquencement entre les deux (et dans ++n * --n, il n'y en a pas), l'évaluation est libre.
Il n'y a de contrainte "de gauche à droite" que pour les opérateurs booléens ((++n && --n) est défini, et sera vrai si n n'est égal ni à -1 ni à 0)

[HS]

Citation:

Désolé mais si vous avez un peu etudier l'histoire de l'informatique vous sauriez de les outils qui ne respectent pas le standard comportemental et qui ne sont pas compatible avec ce qui a été déjà produit se fait imanquablement ejecter du circuit

Perdu, M$ fait cela et écrase régulièrement les standards existants.
[/HS]

Citation:

car je vois mal linux ibm ou aix modifier des centaines de milliers de lignes de codes rien que pour coller aux comportements d'un nouveau compilateur aussi bon soit il.

Il n'y a pas besoin de modifier son code si l'on n'a aucun comportement indéfini dedans.

Programme de test, Visual Studio 2005 :

Code:

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
static void TestParam2(int n)
{
	std::cout << "n before: " << n;
	int res = ++n && --n;
	std::cout << " - n after: " << n << " - result: " << res << std::endl;
}
 
static void TestParam3(int n)
{
	std::cout << "n before: " << n;
	int res = ++n * --n;
	std::cout << " - n after: " << n << " - result: " << res << std::endl;
}
 
void TestClass(void)
{
	//Pokethulhu pikathulhu("Pikathulhu");
	//Pokethulhu hastursaur("Hasturzarre");
	//
	//AffichPoke(pikathulhu);
	//AffichPoke(hastursaur);
	//
	//int a = TestParam(2, 3);
	//(void)a;
	//Incrementable i1;
	//Incrementable i2 = i1++;
 
	for(int nb = -10 ; nb<10 ; ++nb)
		TestParam2(nb);
	std::cout << "-------------" << std::endl;
	for(int nb = -10 ; nb<10 ; ++nb)
		TestParam3(nb);
}

Sortie dudit programme :

Code:

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
n before: -10 - n after: -10 - result: 1
n before: -9 - n after: -9 - result: 1
n before: -8 - n after: -8 - result: 1
n before: -7 - n after: -7 - result: 1
n before: -6 - n after: -6 - result: 1
n before: -5 - n after: -5 - result: 1
n before: -4 - n after: -4 - result: 1
n before: -3 - n after: -3 - result: 1
n before: -2 - n after: -2 - result: 1
n before: -1 - n after: 0 - result: 0
n before: 0 - n after: 0 - result: 0
n before: 1 - n after: 1 - result: 1
n before: 2 - n after: 2 - result: 1
n before: 3 - n after: 3 - result: 1
n before: 4 - n after: 4 - result: 1
n before: 5 - n after: 5 - result: 1
n before: 6 - n after: 6 - result: 1
n before: 7 - n after: 7 - result: 1
n before: 8 - n after: 8 - result: 1
n before: 9 - n after: 9 - result: 1
-------------
n before: -10 - n after: -10 - result: 100
n before: -9 - n after: -9 - result: 81
n before: -8 - n after: -8 - result: 64
n before: -7 - n after: -7 - result: 49
n before: -6 - n after: -6 - result: 36
n before: -5 - n after: -5 - result: 25
n before: -4 - n after: -4 - result: 16
n before: -3 - n after: -3 - result: 9
n before: -2 - n after: -2 - result: 4
n before: -1 - n after: -1 - result: 1
n before: 0 - n after: 0 - result: 0
n before: 1 - n after: 1 - result: 1
n before: 2 - n after: 2 - result: 4
n before: 3 - n after: 3 - result: 9
n before: 4 - n after: 4 - result: 16
n before: 5 - n after: 5 - result: 25
n before: 6 - n after: 6 - result: 36
n before: 7 - n after: 7 - result: 49
n before: 8 - n after: 8 - result: 64
n before: 9 - n after: 9 - result: 81

Le premier test montre les résultats espérés, mais le second n'affiche que des carrés, indiquant que les deux effets de bord ont été pris en compte avant que les opérandes de la multiplication soient lues (les deux opérandes ont la même valeur, il n'y a donc pas eu de modification "entre").
Et ce comportement reste conforme à la norme.

06/09/2007, 14h48
doccpu
Citation:

Envoyé par Médinoc

Ben non, Ces opérateurs ont toujours des effets de bord: ils modifient une variable.

perdu, ce n'est pas défini par la norme. S'il n'y a pas de point de séquencement entre les deux (et dans ++n * --n, il n'y en a pas), l'évaluation est libre.
Il n'y a de contrainte "de gauche à droite" que pour les opérateurs booléens ((++n && --n) est défini, et sera vrai si n n'est égal ni à -1 ni à 0)

[HS]

Perdu, M$ fait cela et écrase régulièrement les standards existants.
[/HS]

Il n'y a pas besoin de modifier son code si l'on n'a aucun comportement indéfini dedans.

voici un VRAI effet de bord :
Code:

1 2 int i = 5; int x = ++i--i--;
et pour l'enlever il faut faire
Code:

1 2 int i = 5; int x = ++i - (-(i--));
:sm::pan::boulet:

j'ai passé des anées a faire ca : :bug: avec de la théorie fumeuse en informatique la pratique est la meilleure voie car bien souvent les développeurs ont fait ce qu'ils ont interprété de la norme donc la norme est obsolette ! trouve moi un linux qui est certifié 100% posix pour voir ? il n'on jamais passé les test donc il ne peuvent pas etre certifié du tout ! pourtant ils respectent tous posix c'est la difference entre la théorie et la pratique !
06/09/2007, 14h55
Médinoc
Citation:
Envoyé par doccpu

voici un VRAI effet de bord :

Code:

1 2 int i = 5; int x = ++i--i--;
Ne compile pas.
Citation:
Envoyé par doccpu

et pour l'enlever il faut faire

Code:

1 2 int i = 5; int x = ++i - (-(i--));
Il y a toujours des effets de bord ici, tu ne les as en aucun cas retirés.
Par contre, le comportement ne semble plus être indéfini (l'effet de bord de ++i s'applique forcément avant, et celui de i-- forcément après).

PS:

Citation:

arrête d'enculer les mouches, c'est pas scalaire t'est pas sous delphi. c'est une variable stoqué en pile et je vais mème te dire mieux n ne signifie rien d'autre pour le compilateur que la valeur stoqué dans une adresse mémoire fixé a l'execution. Alors tu vois que c'est pas si indéfini !

J'ai l'impression que vous n'avez pas la même définition de "scalaire"...
Et quel rapport entre "scalaire" et l'endroit où est stockée la variable ?
07/09/2007, 10h28
doccpu

Citation:

Envoyé par Médinoc

Ne compile pas.

Il y a toujours des effets de bord ici, tu ne les as en aucun cas retirés.
Par contre, le comportement ne semble plus être indéfini (l'effet de bord de ++i s'applique forcément avant, et celui de i-- forcément après).

PS:

J'ai l'impression que vous n'avez pas la même définition de "scalaire"...
Et quel rapport entre "scalaire" et l'endroit où est stockée la variable ?

laisse tomber j'avais pas lu l'avertissement :/

Voir 40 message(s) de cette discussion en une page