Pourquoi l'API Java utilise int au lieu de short ou byte?java


Answers

(Presque) Toutes les opérations sur byte , short les promeut en int , par exemple, vous ne pouvez pas écrire:

short x = 1;
short y = 2;

short z = x + y; //error

Les arithmétiques sont plus faciles et plus simples lorsque vous utilisez int , pas besoin de lancer.

En termes d'espace, cela fait une très petite différence. byte et short compliqueraient les choses, je ne pense pas que cette micro optimisation en vaille la peine puisque nous parlons d'un nombre fixe de variables.

byte est pertinent et utile lorsque vous programmez des périphériques intégrés ou que vous traitez des fichiers / réseaux. De plus, ces primitives sont limitées, et si les calculs pouvaient dépasser leurs limites dans le futur? Essayez de penser à une extension pour la classe Calendar qui pourrait évoluer vers de plus grands nombres.

Notez également que dans un processeur 64 bits, les variables locales seront sauvegardées dans des registres et n'utiliseront aucune ressource, donc l'utilisation de int , short et d'autres primitives ne fera aucune différence. De plus, de nombreuses implémentations Java alignent les variables * (et les objets).

* byte et short occupent le même espace que int s'ils sont des variables locales , des variables de classe ou même des variables d' instance . Pourquoi? Parce que dans la plupart des systèmes informatiques, les adresses de variables sont alignées , par exemple si vous utilisez un seul octet, vous finirez avec deux octets - un pour la variable elle-même et un autre pour le remplissage.

D'un autre côté, dans les tableaux, l' byte prend 1 octet, short prend 2 octets et int prend quatre octets, parce que dans les tableaux seulement le début et peut-être la fin doit être aligné. Cela fera une différence dans le cas où vous voulez utiliser, par exemple, System.arraycopy() , alors vous remarquerez vraiment une différence de performance.

Question

Pourquoi l'API Java utilise-t-elle int , alors que short ou byte suffirait?

Exemple: Le champ DAY_OF_WEEK de la classe Calendar utilise int .

Si la différence est trop minime, alors pourquoi ces types de données ( short , int ) existent-ils?




Si vous utilisiez la philosophie où les constantes intégrales sont stockées dans le plus petit type, alors Java aurait un problème sérieux: chaque fois que les programmeurs écrivent du code en utilisant des constantes intégrales, ils doivent faire attention à leur code pour vérifier les constantes sont importantes, et si c'est le cas, recherchez le type dans la documentation et / ou faites les conversions de type nécessaires.

Alors maintenant que nous avons décrit un problème sérieux, quels avantages pourriez-vous espérer réaliser avec cette philosophie? Je ne serais pas surpris si le seul effet observable à l'exécution de ce changement serait quel type vous obtenez quand vous regardez la constante par réflexion. (et, bien sûr, quelles que soient les erreurs introduites par les programmeurs paresseux / inconscients ne prenant pas correctement en compte les types de constantes)

Peser les avantages et les inconvénients est très facile: c'est une mauvaise philosophie.




En fait, il y aurait un petit avantage. Si tu as un

class MyTimeAndDayOfWeek {
    byte dayOfWeek;
    byte hour;
    byte minute;
    byte second;
}

puis sur une JVM typique, il lui faut autant d'espace qu'une classe contenant un seul int . La consommation de mémoire est arrondie à un multiple suivant de 8 ou 16 octets (IIRC, c'est configurable), donc les cas où il y a de vraies économies sont plutôt rares.

Cette classe serait légèrement plus facile à utiliser si les méthodes Calendar correspondantes Calendar un byte . Mais il n'y a pas de telles méthodes de Calendar , seulement get(int) qui doit retourner un int cause d'autres champs. Chaque opération sur des types plus petits favorise int , donc vous avez besoin de beaucoup de casting.

Très probablement, vous allez abandonner et passer à un int ou écrire des setters comme

void setDayOfWeek(int dayOfWeek) {
    this.dayOfWeek = checkedCastToByte(dayOfWeek);
}

Alors le type de DAY_OF_WEEK n'a pas d'importance, de toute façon.