Je suis préparé pour un examen SCJP et lorsque vous étudiez une partie d'élargissement, il est donné que l'élargissement bat ces battements de boxe et var-args en surcharge, mais il n'y a aucune explication claire. Essayé de chercher mais n'a pas eu de meilleure réponse. p>
Une réponse que j'ai eu est parce que le compilateur choisit le style plus ancien avant de choisir le style nouveau. Mais je ne suis pas convaincu. P>
Edit: Je sais que l'élargissement est préféré que la boxe et les var-args. Mais pourquoi ma question est-elle? dont je connais un. toute autre raison. p>
7 Réponses :
Je ne sais pas de vous, mais je préférerais beaucoup que le compilateur a passé mon En d'autres termes, la raison est une efficacité. La conception de la langue préfère le mécanisme d'appel plus efficace qui ne nécessite pas qu'il a attribué un élément en boîte. P>
'exige', vous demandez? Les fonctions VARARGS s'attendent à obtenir un tableau de La compatibilité n'est pas une mauvaise raison non plus. P> octet code> en tant que int code> que sous forme octet code >. Considérons les frais généraux. Et Varargs nécessite également la boxe. P>
objet code>, ce qui ne peut pas inclure de type primitif. P>
C'est ce que je demande pourquoi? n'importe quelle raison.
C'est une raison. Laissez-moi réessayer.
@bmargulies - Pourquoi Varargs nécessite-t-il une boxe?
@bmargulies - Je pensais que le compilateur crée un tableau du type donné, que ce soit un objet ou une primitive. Dans Méthode (long ... var) code> var est une gamme de longues longues ...
@Carlos Heuberger je ne pensais pas à ça. Je pensais à (objet ... var)
Oui, le compilateur "choisit le style plus ancien sur le style plus récent", en raison des exigences de compatibilité. Imaginez un certain code, écrit avant la sortie de Java 5, cela avait soudainement un changement de comportement lorsqu'il est compilé sous Java 5! Ce serait mauvais. P>
Les conversions d'élargissement ont été autour depuis l'aube de Java, mais d'autoboxyture et de varargs sont nouvelles pour Java 5. P>
Voici un exemple de celui-ci: de sorte que tout cela signifie qu'il va élargir avant d'autoboxer et d'utiliser des varargs. Si nous avons sorti la méthode d'élargissement avec le paramètre long, il aurait choisi l'autoboxing avant les varargs. P> p>
Le compilateur doit garder la compatibilité avec les versions précédentes de Java. En plus de cela, le compilateur choisit le changement le plus performant / le plus petit de l'argument. Promouvoir à un autre battement primitif Création d'un objet wrapper et qui bat la création d'une matrice en matière d'utilisation et de performance de la mémoire. P>
La raison pour laquelle l'élargissement fonctionne mieux est que c'est une opération simple de signer étendre, une seule instruction pour la plupart des CPP. La boxe nécessite une allocation de tas et des objets en boîte sont plus chers pour accéder, nécessitant au moins un accès supplémentaire de la mémoire. p>
Même sans la question de compatibilité, il me semble que vous voudriez que la langue préfère la surcharge la plus rapide, tant que ce comportement ne crée aucun problème pire. p>
Beats d'élargissement Boxing, Boxing bat les génériques, Les génériques battent Varargs p>
class Widen {
private static widen(long k) {
System.out.println("Converted to long: " + k);
}
private static widen(int ... k) {
System.out.println("Converted to varargs: " + k);
}
private static widen(Integer k) {
System.out.println("Converted to Integer: " + k);
}
public static void main(String ... args) {
int value = 3;
widen(value); // Output: Converted to long: 3
}
}
to solve above mind this:widening beats boxing, boxing beats varargsthe out put will be
Converted to long:3
Ce n'est pas une réponse, juste une copie sale de Réponse de MANGODRUNK avec une déclaration supplémentaire qui devrait être un commentaire. Veuillez vous abstenir de fournir de telles réponses et d'attendre d'avoir au moins 50 représentants pour poster des commentaires sur les questions / réponses.
Il n'a pas besoin d'être une autre raison que de la compatibilité. La compatibilité a été citée comme la raison principale de courter de nombreuses choses autrement «meilleures» à Java; Par exemple, l'utilisation de génériques basées sur l'effacement au lieu de génériques de réifié est totalement une concession à la compatibilité.
Pourquoi ne pas nous dire la raison pour laquelle vous savez pour que nous ne le répétions pas encore et encore.
Celui que je mentionne déjà dans la question elle-même. le style.