Discussion :

[yan]

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 C++ :

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

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?

[Jean-Marc.Bourguet]

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

On va etre clair:

Code :

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

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

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

[aoyou]

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.

[Aszarsha]

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 !

[aoyou]

oui oui paresseux

[doccpu]

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 C++ :

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

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

[doccpu]

On va etre clair:

Code :

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

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.

[yan]

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é

[Jean-Marc.Bourguet]

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.

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

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 :

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

1
2
 
   x = ++n * --n

il n'y a pas de points de sequencement. Donc le paragraphe deja cite s'applique:

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.

[doccpu]

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.

++ 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É ?

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 ?

dans l'expression

Code :

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

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

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

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 !

[Aszarsha]

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 !

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 !

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

[Jean-Marc.Bourguet]

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

Reference?

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.

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

[doccpu]

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.

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

[Jean-Marc.Bourguet]

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

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

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

Puisque tu aimes bien, ce genre de choses:

[Médinoc]

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.

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]

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]

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.

[Médinoc]

Programme de test, Visual Studio 2005 :

Code C++ :

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
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 X :

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

[doccpu]

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 :

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

1
2
int i = 5;
int x = ++i--i--;

et pour l'enlever il faut faire

Code :

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

1
2
int i = 5;
int x = ++i - (-(i--));

j'ai passé des anées a faire ca : 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 !

[Médinoc]

voici un VRAI effet de bord :

Code :

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

1
2
int i = 5;
int x = ++i--i--;

Ne compile pas.

et pour l'enlever il faut faire

Code :

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

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:

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 ?

[doccpu]

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 :/