Question sur la pré incrémentation

Bonjour à tous,

Je viens ici car je me pose une petite question. J'ai du faire un petit programme simple, qui doit calculer le nombre de nombre premier contenu dans un chiffre donnée. Si l'utilisateur saisi 100, je dois afficher 25 ( 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97.)

J'ai un programme qui fonctionne, le voilà :

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

#include <iostream> #include <math.h> using namespace std;   int main() { int a, f = 1, r = 0; cout << "merci de saisir un nombre : " <<endl; cin >> a; for(int j = a; j >= 2; j--){ for(int i = j; i >= 2; i--){ if(j % i == 0 && i != j){ f = 0; i = 0; } } if(f){ r++; } f = 1; } cout << r; }

---

En output, j'ai bien 25 lorsque je saisi 100.

J'ai fais une autre version (qui était celle de base), celle ci :

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

#include <iostream> #include <math.h> using namespace std;   int main() { int a, f = 1, r = 0; cout << "merci de saisir un nombre : " <<endl; cin >> a; for(int j = a; j >= 2; j--){ for(int i = j; i >= 2; --i){ if(j % i == 0){ f = 0; i = 0; } } if(f){ r++; } f = 1; } cout << r; }

---

Ici, je n'ai pas mis la condition i != j , mais j'ai mis une pré incrémentation, mais impossible d'obtenir le bon résultat. Si vous avez une explication, ou si je me suis trompé !

Merci d'avance pour les réponses !

Tu connais le principe de la pré-incrémentation et de la post-incrémentation?

Peux-tu faire ce test? Qu'as tu obtenu?

Code:

---

1 2 3 4 5 6 7 8 9

for (int i = 0; i < 10; ++i) { std::cout << i << ' '; } std::cout << std::endl; for (int i = 0; i < 10; i++) { std::cout << i << ' '; }

---

En effet...

J'avais dans l'idée, qu'avec la pré incrémentation, je passai directement à 1 dans ma boucle for(). Du coup, je ne comprend vraiment pas me principe d'une pré incrémentation dans une boucle for(), et je ne trouve absolument aucune logique dans le fonctionnement.

Il s'agissait de quelque chose de tout bête, merci pour la réponse !

Citation:

---

Envoyé par bloups0

J'avais dans l'idée, qu'avec la pré incrémentation, je passai directement à 1 dans ma boucle for(). Du coup, je ne comprend vraiment pas me principe d'une pré incrémentation dans une boucle for(), et je ne trouve absolument aucune logique dans le fonctionnement.

---

J'ai eu les memes soucis que toi mais, en fait, les 3 options de la boucle for sont:
1 - Condition de début de boucle
2 - Condition de fin de boucle
3 - Evolution de la condition de boucle

Cette 3eme étape ne se fait qu'a la fin de la boucle for.
Donc, que tu post ou pré-incrémente, cela ne change pas grand chose ;) A moins bien sur, qu'il y ait une logique qui m'échappe et que je veux bien connaitre!!

En revanche, dans ton code, tu aurais pu commencer ta 2eme boucle un cran en dessous par exemple ;)

Code:

---

1 2 3 4 5

for(int j = a; j >= 2; j--){ for(int i = j-1; i >= 2; --i){ ... } }

---

En effet, j'avais fais une autre version avec le j-1 ^^.

Merci pour les réponses !

La différence de la pré-incrémentation et post-incrémentation ne se voit que sur des itérateurs.
La pré-incrémentation renvoie une référence sur l'itérateur incrémenté, alors que la post-incrémentation renvoie une copie de l'itérateur, donc dans une boucle for il est toujours plus optimale de faire une pré-incrémentation, plutôt qu'une post-incrémentation (bien que maintenant les compilo peuvent optimiser ça, et que la différence ne se fasse absolument plus ressentir).

En dehors de ça, Bysbobo, à tout dit.

Salut,

Citation:

---

Envoyé par Danny-k

La différence de la pré-incrémentation et post-incrémentation ne se voit que sur des itérateurs.
La pré-incrémentation renvoie une référence sur l'itérateur incrémenté, alors que la post-incrémentation renvoie une copie de l'itérateur, donc dans une boucle for il est toujours plus optimale de faire une pré-incrémentation, plutôt qu'une post-incrémentation (bien que maintenant les compilo peuvent optimiser ça, et que la différence ne se fasse absolument plus ressentir).

En dehors de ça, Bysbobo, à tout dit.

---

En fait, c'est un peu plus complexe que cela...

On considère généralement que la pré incrémentation et la post incrémentation sont des instructions "atomiques" (qui ne peuvent pas être subdivisée d'avantage), mais ce n'est vrai que pour la pré-incrémentation. Et, d'une certaine manière, la post incrémentation est, quant à elle, une ineptie pure et simple, justement, parce qu'il ne s'agit pas d'une opération "atomique".

En effet, la pré incrémentation ne nous posera jamais de problème, car, comme je viens de le dire, elle est atomique, si bien que, si tu as un code proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

void foo(int i){ std::cout<<"in foo, i = "<<i<<"\n"; } int main() { int i{10}; std::cout<<"using pre incrementation ...\n"; foo(++i); std::cout<<"after pre incrementation, i = "<<i<<"\n"; return 0; }

---

on obtiendra l'affichage

Code:

---

1 2 3

using pre incrementation... in foo, i = 11 after pre incrementation, i = 11

---

ce qui est, d'une certaine manière exactement le comportement auquel nous sommes tout à fait en droit de nous attendre ;)

Par contre, la post incrémentation va permettre à "tout ce qui pourra" récupérer la valeur de la variable incrémentée de récupérer la valeur de cette variable... AVANT qu'elle ne soit effectivement incrémentée.

Ainsi, en modifiant un tout petit peu le code pour lui donner la forme de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

void foo(int i){ std::cout<<"in foo, i = "<<i<<"\n"; } int main() { int i{10}; std::cout<<"using post incrementation ...\n"; foo(i++); std::cout<<"after post incrementation, i = "<<i<<"\n"; return 0; }

---

on obtiendra l'affichage

Code:

---

1 2 3

using post incrementation... in foo, i = 10 after post incrementation, i = 11

---

ce qui a très largement de quoi surprendre une personne (trop) peu attentive

Et l'on ne peut même pas dire qu'il faudrait préférer ce code à un code proche de

Code:

---

1 2 3 4 5 6 7

int main(){ /* je retire l'affichage par concision */ int i{10}; foo(i); ++i; }

---

car le code assembleur généré serait strictement identique, si bien que le seul avantage (si tant est que l'on puisse le considérer comme tel serait)... d'économiser une ligne de code.

Bien sur, le nombre de lignes de code composant une fonction est un sujet qui a toujours fait (et qui fera sans doute toujours) polémique, et je ne tiens pas à relancer ce débat.

Mais, si pour respecter des règles aberrantes à force d'être trop strictes sur ce point, on en vient à décider de recourir à la post incrémentation, au lieu de pré incrémenter la variable après l'appel de la fonction, on devrait sans doutes envisager le fait que la fonction en fasse déjà trop sans même avoir recours à ce sucre syntaxique.

Car il s'agit bien ici d'un sucre syntaxique dans toute sa splendeur, dans le sens où il permet (très certainement) d'écrire un code plus "conçis", mais aussi dans le sens où l'avantage que l'on en tire est largement contrebalancé par la difficulté qu'il ajoute à la compréhension du code ;)

Merci koala pour ces explications mais qu entends-tu par "instructions atomiques"?
Apres, je t avouerai que je comprends tout a fait l argumentation mais je ne saisis pas le concept de la difficulté.
Pour moi, il s agit d un outil puissant pour ne pas bourrer le code de "+=1"

D un coté:

Code:

---

1 2 3 4

cout << i++; // équivaut a cout << i; i += 1;

---

Et a contrario

Code:

---

1 2 3 4

cout << ++i; // équivaut a i += 1; cout << i;

---

=> Si, au niveau de l assembleur, il semble que cela fasse la meme chose, leur utilité peut s avérer intéressante en fonction des cas de figure.

Certes, les neurones en prennent un coup et les erreurs peuvent apparaitre assez vite mais je sais que, rarement, j ai eu la possibilité d utiliser la post ou la pré-incrémentation et ce n est pas forcément plus dégueulasse. Si effectivement, on ne connait pas la différence, mieux vaut s en passer.

Une instruction atomique c'est une instruction qui se produira entièrement à tous les coups, sans aucun risque que l'os puisse switch de thread au milieu.
C'est le B.A.BA de la programmation multithread et de toute concurrence.
https://fr.wikipedia.org/wiki/Atomic...(informatique)

Sur un type primitif je ne doute pas de son atomicité, sur un type perso avec surcharge de l'opérateur, je dirais que ça dépend de son implémentation.

Hello

Le terme "atomique" utilisé par Koala prête à confusion. L'atomicité au sens strict n'est pas garantie si on n'utilise pas un std::atomic, même si elle se produit la plupart du temps. Je ne sais pas quel est le terme exact cependant qui correspondrait mieux.

Citation:

---

Envoyé par jblecanard

L'atomicité au sens strict n'est pas garantie si on n'utilise pas un std::atomic

---

Il suffit de voir le code assembleur généré, il me semble que l'incrémentation est un simple inc, une seule ligne d'asm, ça sera toujours atomique (avec les types triviaux bien entendu).

Oula attention, "une seule ligne d'ASM" n'est pas du tout équivalent à "atomique" :aie:. Si deux coeurs tentent d'incrémenter la même variable au même moment, il y a une race condition et un des deux incréments peut passer à la trappe ! Type primitif ou pas. Il faut des conditions d'ordonnancement de la mémoire explicites pour obtenir l'atomicité.

Edit: je viens de tester d'ailleurs, ce n'est pas toujours le cas. Avec GCC sur x86 64bits, un pré-incrément ne fait qu'une instruction lorsque compilé en optimisé, pas en debug. Du coup, même si on partait du principe que 1 instruction == atomique, le programme deviendrait faux en debug :mrgreen:.

D'ailleurs, ++i + ++i reste tout aussi indéterminé que i++ + i++, ce qui ne serait pas le cas si c'était garanti atomique.

En fait, je n'arrive pas à le confirmer complêtement. Les règles ont changé en C++11, et ca recommencera avec C++17.
En C++17, par exemple, f(++i, ++i) n'est pas un undefined behaviour.

C++17 fixe l'ordre d'évaluation des paramètres d'une fonction?

Non, mais ce n'est plus un "undefined behaviour" pour autant.
Les arguments sont "indeterminately sequenced" (et non "unsequenced"), ce qui signifie qu'ils sont intégralement séquencés, mais que l'ordre de séquençage peut changer d'une évaluation à l'autre.
En principe, les instructions des sous-expressions "unsequenced" peuvent être s'entrelacées, mais pas celles des sous-expressions "indeterminately sequenced".

Remarque: les deux parties de ++i sont séquencées: incrémentation de i puis retour de la référence sur i.

Deux sous-expressions "unsequenced" portant sur le même objet provoque un "undefined behaviour".
Pour être précis, c'est lorsqu'il y a deux effets de bords "unsequenced" sur un même objet, ou un effet de bord et une evalutation de valeur "unsequenced" du même objet.

Bref, ce n'est plus un "undefined behaviour", mais je ne vois pas bien ce qu'on y gagne :aie:
Pour int i = 0; f(++i, ++i);, on peut avoir f(1,2); f(2,1), mais plus f(2,2). :weird:

Et bientôt quelques pensionnaires de plus à l'asile des développeurs de compilateurs C++.. :roll:

Citation:

---

Envoyé par Médinoc

D'ailleurs, ++i + ++i reste tout aussi indéterminé que i++ + i++, ce qui ne serait pas le cas si c'était garanti atomique.

---

Et le comportement est tout autant indéterminé si i est un std::atomic, je ne vois donc pas ce que tu essayes de prouver ici ni le rapport avec l'atomicité ? :weird:

Citation:

---

Envoyé par Bysbobo

Merci koala pour ces explications mais qu entends-tu par "instructions atomiques"?
Apres, je t avouerai que je comprends tout a fait l argumentation mais je ne saisis pas le concept de la difficulté.
Pour moi, il s agit d un outil puissant pour ne pas bourrer le code de "+=1"

D un coté:

Code:

---

1 2 3 4

cout << i++; // équivaut a cout << i; i += 1;

---

Et a contrario

Code:

---

1 2 3 4

cout << ++i; // équivaut a i += 1; cout << i;

---

=> Si, au niveau de l assembleur, il semble que cela fasse la meme chose, leur utilité peut s avérer intéressante en fonction des cas de figure.

Certes, les neurones en prennent un coup et les erreurs peuvent apparaitre assez vite mais je sais que, rarement, j ai eu la possibilité d utiliser la post ou la pré-incrémentation et ce n est pas forcément plus dégueulasse. Si effectivement, on ne connait pas la différence, mieux vaut s en passer.

---

Attention, je parle de la post incrémentation uniquement lorsque je dis qu'elle a "quelque chose de contre nature"...

La pré incrémentation a en effet un résultat "tout à fait cohérent" avec ce à quoi l'on est en droit de s'attendre : si x vaut 10, le fait d'appeler une fonction en lui passant ++x fera que la fonction sera bel et bien avec la valeur 11.

Or, comme le démontre le code que j'ai présenté plus haut, la post incrémentation appellera la même fonction avec la valeur ... 10 et fera en sorte que x ne valle 11 que... pour l'instruction suivante qui aurait à utiliser x.

Citation:

---

Envoyé par jblecanard

Hello

Le terme "atomique" utilisé par Koala prête à confusion. L'atomicité au sens strict n'est pas garantie si on n'utilise pas un std::atomic, même si elle se produit la plupart du temps. Je ne sais pas quel est le terme exact cependant qui correspondrait mieux.

---

Effectivement, le terme atomique utilisé dans mon explication est sujet à confusion, et j'aurais sans doute du le mettre entre guillemets :P

Ce que je voulais surtout indiquer, c'est le fait que la pré incrémentation apporte la garantie que la modification (le fait d'incrémenter la valeur de la variable) sera bel et bien effectuée quoi qu'il advienne par la suite, alors que la post incrémentation laisse justement la possibilité, "dans certaines circonstances", d'utiliser "valeur d'origine" (comprenez: avant que l'incrémentation n'ait lieu).

Malheureusement, il n'existe aucun autre terme proche de "atomique" qui puisse exprimer ce fait ;)