Java et C++: importance des operateurs assignation

bonjour, je suis entrain d'apprendre Java, mais la j'ai un peu de peine a comprendre le resultat d'un bout de code en Java.

en C, ce petit bout de code renvoie 16, ce que je comprends:

Code:

---

1 2 3

int i=2; i *=(i=4);

---

tandis qu'en Java (Java7), il me renvoie 8.

Je n'arrive pas a comprendre l'ordre des operations proprement dites dans le cas de Java finalement. je pensais que le petit code ci-dessus se divisait en les etapes suivantes:
i=4, ensuite il est eleve au carre et renvoie 16.
Est-ce que quelqu'un aurait une explication sur l'approche Java ici?
Dois-je lire de gauche vers la droite les operations? Le bouquin que j'ai n'est pas tres clair a ce sujet.

Merci d'avance.(desole, mais je ne comprends pas vraiment la logique finalement).

Salut,

pour moi, mais c'est une question de point de vue, le résultat java est plus logique.

L'expression i *= (i=4) correspond à faire :

i = i * ( i=4)

lorsqu'on exécute le code, i vaut 2

donc c'est comme si on écrivait i = 2 * ( i = 4 ),

donc comme si on écrivait i = 4, puis i = 2 * 4

qui vaut bien 8.

Je ne vois pas ou il y aurait une notion de mise au carré dans cette expression.

l'expression (i = 4) vaut 4, mais i est affecté à 4, mais ensuite 2 * 4 est affecté à i, qui remplace 4, et qui vaut finalement 8.

Si l'expression était i *= (i = 4)*i;

dans ce cas, le dernier i vaut 4 au moment il est utilisé pour le calcul, et le résultat est bien 32 .
c'est comme si on écrivait i = 2 * ((i=4)*i), soit comme si on écrivait i=4, suvi de i = 2 * ( 4 * i ),

et si on a i *= i = 4*i; alors le résultat est 16, à cause de la précédence de l'opérateur * sur =
c'est comme si on écrivait i = 2 * ( i = (4*2 ) ), donc i = (4*2), suivi de i =2 * ( 4 * 2 )


Personnellement, je préfère éviter d'utiliser ce type d'expressions "confusantes". La clartée du code est utile à la compréhension et chercher à écrire des formules tordues contribue à des erreurs toujours difficiles à détecter. Je ne vois même pas comment la résolution d'un problème pourrait amener à écrire une opération avec des termes qui sont modifiés au cours de l'opération.

Pourquoi ne pas écrire par exemple i *= i + i % 3 != 0 ? i *= (i=4)%2 == 0 ? i *= i *= i << i : i : i, histoire de donner un bon mal au crane à celui qui aura à modifier le code un jour ;)

Il y a un cas que j'ai oublié :

si tu avais écrit i *= i = 4, la question serait éventuellement plus légitime.

Mais la précédence de l'opérateur *= sur l'opérateur = fait que c'est comme si on écrivait i *= (i=4), donc ça vaut 8 aussi.

bonjour,
merci pour le detail de l'explication. Je suis d'accord qu'ecrire les commandes de facon "trop" concise est generateur de confusion.
Je suis entrain simplement de suivre page a page un livre qui aborde cet aspect et j'ai du mal a comprendre la logique Java par rapport a celle de C qui est plus intuitive a mon humble avis.
Ce qui me derange c'est surtout que la logique suivie par Java ici me parait pas vraiment naturelle (certainement car je suis c++-biased), puisqu'on aboutit a des resultats differents suivant qu'on utilise Java ou bien un autre langage, ici en l'occurence C.
merci pour votre reponse.

Sans parler de la théorie, la logique que j'applique pour comprendre une expression est la suivante :

1) je calcule toutes les sous expressions de plus bas niveau en premier (donc entre parenthèses, le plus bas niveau étant celles n'ayant pas de terme entre parenthèses ) et je remonte, en supprimant les parenthèses pour obtenir un nouveau niveau le + bas
2) pour calculer une expression, je cherche l'opérateur qui a la précédence la plus importante et je mets tout le reste entre parenthèse ( chaque opérande en fonction du type d'opérateur ), et je redescend à l'intérieur en appliquant le 1)
3) tout opérande calculé l'est forcément dans le cadre d'une opération déjà en cours, et on évalue les opérandes de gauche à droite, donc l'affectation d'une variable dans un opérande ne peut qu'affecter les opérandes suivants (situé à sa droite) pour l'opérateur courant

ça me semble relativement intuitif.

En C les compilateurs se sont peut-être tous mis d'accord pour gérer ça comme ça (ça m'étonnerait.)
Mais ce n'est écrit nulle part. La seule manière de le savoir est d'essayer et prier pour que les autres compilateurs fassent pareil.

Il n'y a pas de "logique de C" sur ce point. Il ne faut pas l'écrire, pas seulement parce que c'est incompréhensible, mais aussi parce que ce n'est pas portable.