Quelques questions connexes ici. P>
Selon le titre, pourquoi est-il une exigence si nous spécifions le type de variable aussi long ou float, double? Le compilateur n'évalue-t-il pas le type de la variable au moment de la compilation? P>
Java considère tous les littéraux intégraux comme int code> - est-ce que cela diminuera le coup de déchets de mémoire inadvertance? Et tous les littéraux de points flottants comme
double code> - pour assurer la précision la plus élevée? P>
3 Réponses :
Je crois que c'est simplement d'éviter la confusion. Comment le compilateur saura-t-il que 1,5 est censé être un flotteur ou double s'il n'y a pas de valeur par défaut pour tomber? En ce qui concerne l'évaluation des variables, veuillez noter que les variables! = Littéraux.
EDIT 1 strong> Edit 2 strong> < BR>
Et bien sûr, il y a p>
En ce qui concerne certains commentaires, je pense qu'il y a des moments où vous ne voudriez pas que le compilateur traduit automatiquement le littéral sur la droite au type de variable à gauche. P>
Bien sûr, si vous passez le littéral par opposition à une variable dactylographiée, c'est-à-dire somme (1L, 2L); code> - mais si je défini la variable avec un type, c'est-à-dire
long A = 1 (? L); long b = 2 (? l); somme (a, b); code>?
Dans un monde parfait, le compilateur ne serait-il pas simplement capable de le comprendre en fonction de ce que le type devrait être i>? Bien sûr, cela pourrait ne pas être réalisable de la conception de Java, mais je ne pense pas que ce soit impossible en général.
Je ne sais pas pourquoi ils appellent le "contexte libre" de la grammaire, mais au moins cela coïncide avec le principe général selon lequel le sens d'une expression est évident, non dépendant de son contexte.
Cela a du sens si vous envisagez de littéraux dans le contexte des littéraux. Bien que, plus souvent, je me trouve vouloir que le littéral soit le type défini pour la variable - il semble redondant de devoir la spécifier dans ce cas.
@ wulfgar.pro Conception d'une langue de programmation proche de l'intuition des programmeurs serait très agréable; mais aussi très difficile. Une demande de fonctionnalité semble très simple à elle seule; Mais l'ajout à la spécification qui est déjà de 700 pages de 700 pages sans casser quoi que ce soit n'est pas une tâche facile.
@ hirreputable - une grammaire sans contexte est une grammaire où les résultats de l'analyse ne dépendent pas d'informations contextuelles. C'est bon, mais cela ne signifie pas que le Signification B> de certains arbres d'analyse ne dépend pas du contexte. (Ce serait absurde ...)
Cela devient important lorsque vous faites plus qu'une simple affectation. Si vous prenez p>
float x = 0,1 * 3.0; p>
Cela fait une différence si l'ordinateur effectue la multiplication en double précision, puis convertit à une précision unique ou s'il convertit les nombres à une précision unique, puis multiplie. P>
EDIT: Pas dans ce cas explicite 0.1 et 3.0, mais si vos chiffres deviennent assez complexes, vous rencontrez des problèmes de précision qui montrent des différences entre flotteurs et doubles. Rendre explicite au compilateur s'ils sont censés être doubles ou float évitant l'ambiguïté. P>
Lorsque vous avez une constante, il existe des différences subtiles entre la valeur qui ressemblent à la même chose, mais ne le sont pas. De plus, étant donné que l'autoboxage a été introduit, vous obtenez un résultat très différent de moins.
Considérez ce que vous obtenez si vous multipliez 0,1 par 0,1 par flotteur ou comme double et convertissez en un flotteur. P>
a= 1000000001 b= 1000000000.99999988079071044921875 a == b is false