Bonsoir, comme vous avez remarqué dans le titre, je cherche à savoir la différence entre l'expressions d'incrémentation i++ et ++i?

La différence se fait sur le moment de l'opération.

Exemple simple:

int a = 2, b = 0;

Prenons les 2 cas.

b = ++a;

Dans ce cas, l'incrémentation se fait avant l'affectation. A la fin on a donc a = 3 et b = 3.

b = a++;

Là l'incrémentation se fait après l'affectation. On a a = 3 et b = 2.

Voilà, en espérant avoir répondu à ta question.

Merci beaucoup

Il s'agit de post-incrémentation (x++) et de pré-incrémentation (++x). 
x++ incrémente x et retourne l'ancienne valeur de x 
++x incrémente x et retourne la nouvelle valeur de x. 
Exemple : 
x=5; 
a=x++; /*x vaut 6 et a vaut 5 (ancienne valeur)*/ 

x=5; 
a=++x; /*x vaut 6 et a vaut 6 (nouvelle valeur)*/ 

++i est aussi très légèrement plus rapide (comprendre que c’est négligeable) que i++ car pour la post-incrémentation, il faut mémoriser l’ancienne valeur. De nos jours, avec les optimisations du compilateur c’est plus trop vrai, mais bon.

Cela n’est vrai qu’en C++.

-
Edité par fscorpio 8 juillet 2013 à 11:30:27

fscorpio a écrit:

++i est aussi très légèrement plus rapide (comprendre que c’est négligeable) que i++ car pour la post-incrémentation, il faut mémoriser l’ancienne valeur.

Qu'est-ce qui te fait penser qu'il faudrait la mémoriser?
En pseudo-assembleur

// a = i++;
move   r1, r2
inc    r1


// a = ++i
inc    r1
move   r1, r2

J'ai vu des justifications en C++ avec surcharge d'opérateur, mais sinon pas de souvenir.

J’ai lu ça sur un site (j’ai pas noté l’adresse, c’était dans un cours publié par un enseignant…), il disait qu’il fallait une opération de plus pour la post-incrémentation pour recharger la variable en mémoire ou la copier avant car on ne peut effectuer des opérations que dans les registres et que la valeur chargée était souvent perdu, par exemple avec ce genre de calcul : i++ + j++, i et j sont chargé dans des registres (eax et edx p.ex.) et lors de l’addition des deux, un des deux registres est utilisé pour contenir le résultat, et donc la valeur d’une des variables est perdu et doit donc être rechargé (sauf si on avait fait une copie avant).

Alors que pour incrémenter suffit d’un :

addl    $1, -8(%ebp)

(Dans l’assembleur généré par GCC) Ce qui rend faux l’assertion de départ.

Donc, ce que j’ai dit est faux en effet, je vais corriger ça tout de suite (d’un grand coup de crayon). Merci.

Sur le plan rapidité, c'est surtout avec des objets, je m'explique :

Imaginons on passe un objet dans une fonction qui attend une référence constante sur cet objet.

Tu utilises le post incrémentation, tu dois faire une copie de cette objet pour l'envoyer, puis après incrémenter le réel.

Tu utilises la pré incrémentation, tu dois juste incrémenté, puis envoyer la référence

Sachant que pour des gros objets qui peuvent faire 1Ko, il faudra faire beaucoup de 'mov' en asm afin de tout copier et ce sera "long".

qnope a écrit:

Tu utilises le post incrémentation, tu dois faire une copie de cette objet pour l'envoyer, puis après incrémenter le réel.

Et qu'est-ce qui empêcherait d'envoyer la valeur, exécuter l'appel puis incrémenter ? Ce qui en temps d'exécution reviendrait au même. Sinon, la copie est faite de toute façon.

Pour les data volumineuses, on ne peut pas faire de ++ dessus, non ?

uknow a écrit:

qnope a écrit:

Tu utilises le post incrémentation, tu dois faire une copie de cette objet pour l'envoyer, puis après incrémenter le réel.

Et qu'est-ce qui empêcherait d'envoyer la valeur, exécuter l'appel puis incrémenter ? Ce qui en temps d'exécution reviendrait au même. Sinon, la copie est faite de toute façon.

Pour les data volumineuses, on ne peut pas faire de ++ dessus, non ?

Envoyer la valeur au lieu d'une référence? C'est bien plus lourd avec un gros objet. En C++, la surcharge de l'opérateur ++ peut se faire sur des types volimuneux, pourquoi pas ?

Marc Mongenet a écrit:

Envoyer la valeur au lieu d'une référence? C'est bien plus lourd avec un gros objet. En C++, la surcharge de l'opérateur ++ peut se faire sur des types volimuneux, pourquoi pas ?

Je n'avais pas vu que ca parlait C++ au temps pour moi.

-
Edité par uknow 10 juillet 2013 à 17:19:37