8
votes

Pourquoi irait-je + = l compile, où je suis int et l est long?

J'ai tacheté Java + =, - =, * =, / = opérateurs d'affectation composés (bonne question :)) , mais il y avait une partie que je ne comprends pas tout à fait. Emprunter à partir de cette question:

int i = 5;
long l = 8;


12 commentaires

Cette question est exactement la même et répond aussi. (C'est-à-dire que c'est parce que j'ai + = l; fait une coulée, c'est la même chose que i = (int) (i + l); si le type de i est INT.


Qu'est-ce que exactement n'avez-vous pas compris la réponse à la question que vous connaissez? Il demande presque exactement la même chose, et les informations dont vous avez besoin devraient tous être là - si vous avez toujours du mal à le comprendre, vous devrez être plus précis!


@nos a raison. Vous ne demandez pas de faire partie de la question, vous la dupliquez exactement. Si vous avez lu cette question et les réponses, vous pourriez peut-être expliquer ce que vous n'avez pas sur la réponse (très votée) donnée.


Dupliqué possible de Java + = opérateur


@nos, je suppose que le point de l'OP est que cette conversion de rétrécissement implicite peut entraîner une perte de données et le compilateur pourrait (devrait) au moins avertir à ce sujet.


Bien que c'est clairement une duplication, la descente semble un peu éruption cutanée, ici.


@RAVELINE: Pourquoi la descendance est-elle en double en double, en particulier lorsque l'OP connaissait la duplicata et il y a à peine quelques heures? Si l'objectif de la baisse des questions est de réduire le bruit et de vous assurer que les questions qui méritent de répondre sont les plus visibles, ne revotez pas la réponse appropriée? L'OP ne devrait pas le prendre personnellement.


@ Pétertörök ​​est correct dans son interprétation de la question. Édité pour clarifier.


Je dois admettre que c'est un peu curieux que cette question ait eu beaucoup d'attention d'une grande attention, mais rien depuis mon (espoir de clarifier) ​​éditer ...


Qu'est-ce que E1 est évalué qu'une fois moyenne? Quelle est la différence entre i + = 5 et i = i + 5? Dans la concurrence java en pratique, il est dit que même i ++; n'est pas une opération atomique.


@AMIRPASHAZADEH, ce n'est pas un commentaire à ma question.


@ Michaelkjörling je sais, mais j'ai été confus.


3 Réponses :


14
votes

Fondamentalement, car i + = l est compilé comme s'il était écrit i = (int) (i + l) . Il existe des "surprises" similaires lors de l'ajout de valeurs int sur octet et char variables - L'opérateur d'affectation fonctionne pendant que l'opérateur d'addition ordinaire ne le fait pas.


3 commentaires

Ceci est déjà expliqué dans la réponse acceptée à la question mentionnée ci-dessus. Je suppose que le point de l'OP est que cette conversion de rétrécissement implicite peut entraîner une perte de données, et le compilateur pourrait (devrait) au moins avertir à ce sujet.


Serait encore mieux pour citer les spécifications Java: java.sun.com/docs/books/jls/third_edition/html/...


Ainsi, sauf si vous manquez quelque chose, quelle partie de sinon, la valeur enregistrée de la variable gauche et la valeur de l'opérande à droite permet d'effectuer l'opération binaire indiquée par l'opérateur d'affectation composé. < / Code> dit que la descente implicite doit être effectuée sans indication que tel est fait? Ou est-ce ailleurs? Si ce dernier, je ne vois pas les réponses à l'autre question d'être nécessairement applicable.



8
votes

Étant donné que cette situation peut très facilement causer une perte de données en raison de la conversion de rétrécissement nécessaire à un moment donné lors de l'exécution de la déclaration (évaluation de l'expression de valeur R ou affectation), pourquoi est-ce que i + = l; pas une erreur de compilation ou au moins un avertissement? P>

Cela devrait probablement être, comme vous l'avez dit, une erreur de compilation ou du moins d'avertissement. La plupart des livres et des tutoriels que je suis au courant d'introduire x + = y; code> comme sténographie pour x = x + y; code>. Honnêtement, je ne sais aucun qui rend la distinction appelée à la section 15.26.2 Opérateurs d'affectation composés de la JLS sauf un. P>

au chapitre 2 (puzzle 9) de Puzzlers Java: pièges, pièges et cas d'angle Les auteurs (Joshua Bloch & Necel Grafter) vous demandent de fournir des déclarations pour x code> et i code> tel qu'il s'agisse d'une instruction légale: p> xxx pré>

et ce n'est pas le cas: p>

x = x + i;


0 commentaires

1
votes

La raison de ceci est donc vous pouvez faire: xxx pré>

si + = = a été étendu à b = b + 1 puis l'expression ne tiendrait pas la vérification car l'expression "B + 1" est de type int. Toutes les expressions intégrées en Java sont au moins le type INT, même si vous ajoutez deux octets ensemble. P>

public class Test {
  public static void main(String[] args) {
    byte b = 1;
    byte c = 2;
    byte d = b + c;
  }
}


Test.java:5: possible loss of precision
found   : int
required: byte
    byte d = b + c;
               ^
1 error


0 commentaires