Question

J'écris un OutputStream, je viens de le remarquer dans l'interface OutputStream,

   public abstract void write(int b) throws IOException;

Cet appel écrit un octet dans le flux, mais pourquoi prend-il un entier comme argument?

Était-ce utile?

La solution

En fait, je travaille un peu avec les octets ces derniers temps et ils peuvent être agaçants. Ils se convertissent en ints à la moindre provocation et il n’ya pas de désignation pour transformer un nombre en octet - par exemple, 8l vous donnera une valeur longue 8, mais pour octet, vous devez dire (octet) 8

En plus de cela, ils seront (à peu près) toujours stockés en interne en tant que ints, sauf si vous utilisez un tableau (et peut-être même alors… pas sûr).

Je pense qu'ils supposent à peu près que la seule raison d'utiliser un octet est une entrée / sortie où vous avez réellement besoin de 8 bits, mais en interne, ils s'attendent à ce que vous utilisiez toujours ints.

Au fait, un octet peut être moins performant puisqu'il doit toujours être masqué ...

Au moins je me souviens d'avoir lu qu'il y a des années, cela aurait pu changer maintenant.

Comme exemple de réponse à votre question spécifique, si une fonction (f) prend un octet et que vous avez deux octets (b1 et b2), alors:

f(b1 & b2)

ne fonctionnerait pas, car b1 & amp; b2 serait converti vers le haut en int, et l'int ne pourrait pas être automatiquement converti (perte de précision). Il vous faudra donc coder:

f( (byte)(b1 & b2) )

Ce qui serait irritant.

Et ne vous inquiétez pas de demander POURQUOI b1 & amp; b2 up-convertis - J'ai jeté un œil dessus un peu ces derniers temps moi-même!

Autres conseils

Vous pouvez donc signaler EOF:

"Notez que read () renvoie une valeur int. Si l'entrée est un flux d'octets, pourquoi read () ne renvoie-t-il pas une valeur d'octet? Utiliser un int comme type de retour permet à read () d'utiliser -1 pour indiquer qu'il a atteint la fin du flux. "

http://java.sun.com/docs/ livres / tutorial / essential / io / bytestreams.html

selon le javadoc pour OutputStream , les 24 bits de poids fort sont ignorés par cette fonction. Je pense que la méthode existe pour des raisons de compatibilité: vous n'avez donc pas besoin de convertir d'abord en octet et vous pouvez simplement passer un entier.

salutations

Les classes Java IOStream font partie de Java depuis la version 1.0. Ces classes ne traitent que des données 8 bits. Je suppose que l'interface a été conçue comme ceci, de sorte que la méthode one write (int b) soit appelée pour les valeurs int, short, byte et char. Ce sont tous promus à un int. En fait, comme la plupart des machines virtuelles Java s'exécutent sur des machines 32 bits, la primitive int est le type le plus efficace. Le compilateur est libre de stocker des types tels que des octets en utilisant 32 bits de toute façon. Fait intéressant, byte [] est réellement stocké sous forme d'une séquence d'octets de 8 bits. Cela a du sens puisqu'un tableau peut être assez grand. Toutefois, dans le cas de valeurs primitives uniques telles que int ou byte, l’espace ultime occupé à l’exécution n’a aucune importance, tant que le comportement est conforme à la spécification.

Plus de contexte:

http://www.java-samples.com/showtutorial.php ? tutorialid = 260

L’hypothèse pour les classes IOStream est que l’appelant ne se soucie que des 8 bits de données les plus bas, même lorsqu’il passe dans un int. Cela convient tant que l'appelant sait qu'il s'agit vraiment d'octets, mais cela devient un problème lorsque les données sous-jacentes sont réellement du texte qui utilise un autre codage de caractères tel que Unicode multi-octets. C'est pourquoi les classes Reader ont été introduites avec Java 1.1. Si vous tenez aux données texte et aux performances, les classes IOStream sont plus rapides, mais les classes Reader sont plus portables.

C'est peut-être parce que les octets sont signés par défaut et que les fichiers les stockent sous forme de valeurs non signées. C’est pourquoi read () retourne un int - pour donner 255 au lieu de -1 pour $ FF. Pareil avec write (int) , vous ne pouvez pas stocker $ FF en tant que 255 dans un octet.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top