Peut-on supposer des valeurs de tableau par défaut en Java? Par exemple, supposons qu'un tableau int soit défini sur tous les zéros?

Question

En pratique, est-ce que je peux supposer que tous les tableaux int de Java commenceront par être remplis de zéros? pour toutes les machines sur lesquelles la machine virtuelle Java est exécutée?

Est-ce vrai pour tous les types? carboniser? booléen? enums?

Où est-ce officiellement documenté?

Les manuels que j'ai indiquent que les tableaux int sont définis sur zéro, mais ils recommandent également d'écrire une boucle for pour définir toutes les valeurs sur zéro, "simplement pour être plus clair".

Answer 1

Java Langage de Spécification est le bon endroit pour chercher des informations:

Composants de la baie sont sans nom des variables qui sont créés et initialisés à des valeurs par défaut (§4.12.5) chaque fois qu'un nouvel objet qui est un tableau est créé

Les valeurs par défaut sont eux-mêmes donnés dans la section 4.12.5.

• Pour le type d'octets, la valeur par défaut est zéro, c'est la valeur de (byte)0.
• Pour le type court, la valeur par défaut est zéro, c'est la valeur de (court)0.
• Pour le type int, la valeur par défaut est zéro, c'est 0.
• Pour le type long, la valeur par défaut est zéro, qui est, 0L.
• Pour le type float, la valeur par défaut est positive, zéro, qui est, 0.0 f.
• Pour le type double, la valeur par défaut est positive, zéro, qui est, 0.0 d.
• Pour le type char, la valeur par défaut est le caractère nul, c'est-à, '\u0000'.
• Pour le type boolean, la valeur par défaut est false.
• Pour tous les types référence, la valeur par défaut est null.

Answer 2

Oui. Les types primitifs en Java sont toujours initialisés à zéro. Les références sont également initialisées à null.

Answer 3

Il convient de Java Language Specification §4.12.5 Valeurs Initiales des Variables. au lieu de §4.5.5

"Pour le type d'octets, la valeur par défaut est zéro, c'est la valeur de (byte)0.
Pour le type court, la valeur par défaut est zéro, c'est la valeur de (court)0.
Pour le type int, la valeur par défaut est zéro, c'est 0.
Pour le type long, la valeur par défaut est zéro, qui est, 0L.
Pour le type float, la valeur par défaut est positive, zéro, qui est, 0.0 f.
Pour le type double, la valeur par défaut est positive, zéro, qui est, 0.0 d.
Pour le type char, la valeur par défaut est le caractère nul, c'est-à, '\u0000'.
Pour le type boolean, la valeur par défaut est false.
Pour tous les types de référence (§4.3), la valeur par défaut est null."

Answer 4

Votre livre est faux! La rédaction d'un tel code est inutile, et un gaspillage de votre temps à taper et les ordinateurs moment de l'exécution.

Comme d'autres l'ont dit, le compilateur garantit que les variables en dehors de méthodes (classe/variables d'instance) donne une valeur de 0, false ou null. Comme vous le savez probablement, le compilateur ne donne pas de variables à l'intérieur des méthodes de valeurs, et au lieu de cela vous oblige à leur donner une valeur, avant de servir.

Vous trouverez, si vous faites les choses "droit" qu'environ 90% -95% de votre "variables" ne jamais changer une fois qu'ils sont donné une valeur. Cependant, les nouveaux programmeurs ont tendance à faire les choses comme ceci:

int x = 0;

// some code that never uses x

x = 5;

// more code that only reads x and never modifies it.

cela vous empêche d'être en mesure de marque x "final". Si vous êtes en mesure de marque x "final" alors il empêche toute modification accidentelle de la valeur, ce qui empêche de bugs.

Je voudrais écrire le code comme:

final int x;

// some code that never uses x

x = 5;

// more code that only reads x and never modifies it.

Cela s'appelle un vide final (une dernière variable qui n'a pas de valeur si elle est déclarée).

Si vous vous souvenez de cette classe/instance variables sont initialisées par le moteur d'exécution puis vous permettra, je l'espère, de ne pas écrire du code pour initialiser avec jeter des valeurs, et puis vous pouvez les marquer comme final.

Ma pratique personnelle est de toujours marquer tout comme définitive jusqu'à ce que je trouve que j'ai besoin de le modifier, et de ne jamais initialiser une variable jusqu'à ce que je connais la vraie valeur que je veux qu'il ait. Ce faisant rendre le code plus rapide (pas perceptible, car les missions sont en général très rapide) et plus sûr depuis que j'ai rarement accidentellement modifier une valeur où je ne devrais pas.