Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Eric Jacoboni
Zouplaz writes:
final byte _fN = 0x80;
Le compilateur coince et me force à écrire
final byte _fN = (byte)0x80;
C'est idiot puisque 0x80 EST un byte...
Ben non, justement... 0x80 tient sur un octet, mais ce n'est pas un byte au sens Java puisque les byte sont signés et vont donc de -128 à +127...
Un peu comme si je devais écrire final int toto = (int)123;
Non, car 123 est un int, ce n'est pas la peine de le transtyper.
final long titi = (long)9000;
9000L devrait suffire (à tester).
C'est normal ?
Oui.
En tout cas c'est casse-pieds parce que ça pollue mon source avec des casts de tous les côtés.
Ce n'est pas casse-pieds : Java essaie de te dire que tu es en train de faire une connerie... Je trouve ça bien, au contraire. -- Éric Jacoboni, né il y a 1414780613 secondes
Zouplaz <pouet@pouet.com> writes:
final byte _fN = 0x80;
Le compilateur coince et me force à écrire
final byte _fN = (byte)0x80;
C'est idiot puisque 0x80 EST un byte...
Ben non, justement... 0x80 tient sur un octet, mais ce n'est pas un
byte au sens Java puisque les byte sont signés et vont donc de -128 à
+127...
Un peu comme si je devais écrire
final int toto = (int)123;
Non, car 123 est un int, ce n'est pas la peine de le transtyper.
final long titi = (long)9000;
9000L devrait suffire (à tester).
C'est normal ?
Oui.
En tout cas c'est casse-pieds parce que ça pollue mon source
avec des casts de tous les côtés.
Ce n'est pas casse-pieds : Java essaie de te dire que tu es en train
de faire une connerie... Je trouve ça bien, au contraire.
--
Éric Jacoboni, né il y a 1414780613 secondes
Ben non, justement... 0x80 tient sur un octet, mais ce n'est pas un byte au sens Java puisque les byte sont signés et vont donc de -128 à +127...
Un peu comme si je devais écrire final int toto = (int)123;
Non, car 123 est un int, ce n'est pas la peine de le transtyper.
final long titi = (long)9000;
9000L devrait suffire (à tester).
C'est normal ?
Oui.
En tout cas c'est casse-pieds parce que ça pollue mon source avec des casts de tous les côtés.
Ce n'est pas casse-pieds : Java essaie de te dire que tu es en train de faire une connerie... Je trouve ça bien, au contraire. -- Éric Jacoboni, né il y a 1414780613 secondes
Eric Jacoboni
Zouplaz writes:
final byte _fN = 0x80;
Le compilateur coince et me force à écrire
final byte _fN = (byte)0x80;
C'est idiot puisque 0x80 EST un byte...
0x80 tient sur un octet, mais ce n'est pas un byte au sens Java puisque les byte sont signés et vont donc de -128 à 127... Comment Java pourrait-il deviner que ce 0x80 signifie une valeur négative ou 128 ?
Un peu comme si je devais écrire final int toto = (int)123;
Non, car 123 est un int, ce n'est pas la peine de le transtyper.
final long titi = (long)9000;
9000L devrait suffire (à tester).
C'est normal ?
Oui.
En tout cas c'est casse-pieds parce que ça pollue mon source avec des casts de tous les côtés.
Ce n'est pas casse-pieds : Java essaie de te dire que tu es peut-être en train de faire une connerie... Je trouve ça bien, au contraire. -- Éric Jacoboni, né il y a 1414780613 secondes
Zouplaz <pouet@pouet.com> writes:
final byte _fN = 0x80;
Le compilateur coince et me force à écrire
final byte _fN = (byte)0x80;
C'est idiot puisque 0x80 EST un byte...
0x80 tient sur un octet, mais ce n'est pas un byte au sens Java
puisque les byte sont signés et vont donc de -128 à 127... Comment
Java pourrait-il deviner que ce 0x80 signifie une valeur négative ou
128 ?
Un peu comme si je devais écrire
final int toto = (int)123;
Non, car 123 est un int, ce n'est pas la peine de le transtyper.
final long titi = (long)9000;
9000L devrait suffire (à tester).
C'est normal ?
Oui.
En tout cas c'est casse-pieds parce que ça pollue mon source
avec des casts de tous les côtés.
Ce n'est pas casse-pieds : Java essaie de te dire que tu es peut-être
en train de faire une connerie... Je trouve ça bien, au contraire.
--
Éric Jacoboni, né il y a 1414780613 secondes
0x80 tient sur un octet, mais ce n'est pas un byte au sens Java puisque les byte sont signés et vont donc de -128 à 127... Comment Java pourrait-il deviner que ce 0x80 signifie une valeur négative ou 128 ?
Un peu comme si je devais écrire final int toto = (int)123;
Non, car 123 est un int, ce n'est pas la peine de le transtyper.
final long titi = (long)9000;
9000L devrait suffire (à tester).
C'est normal ?
Oui.
En tout cas c'est casse-pieds parce que ça pollue mon source avec des casts de tous les côtés.
Ce n'est pas casse-pieds : Java essaie de te dire que tu es peut-être en train de faire une connerie... Je trouve ça bien, au contraire. -- Éric Jacoboni, né il y a 1414780613 secondes
Zouplaz
Eric Jacoboni - :
Zouplaz writes:
final byte _fN = 0x80;
Le compilateur coince et me force à écrire
final byte _fN = (byte)0x80;
C'est idiot puisque 0x80 EST un byte...
0x80 tient sur un octet, mais ce n'est pas un byte au sens Java puisque les byte sont signés et vont donc de -128 à 127... Comment Java pourrait-il deviner que ce 0x80 signifie une valeur négative ou 128 ?
D'accord, je vois... En fait c'est le unsigned byte qui manque à l'appel sinon t'as raison c'est logique !
Eric Jacoboni - jaco@neottia.net :
Zouplaz <pouet@pouet.com> writes:
final byte _fN = 0x80;
Le compilateur coince et me force à écrire
final byte _fN = (byte)0x80;
C'est idiot puisque 0x80 EST un byte...
0x80 tient sur un octet, mais ce n'est pas un byte au sens Java
puisque les byte sont signés et vont donc de -128 à 127... Comment
Java pourrait-il deviner que ce 0x80 signifie une valeur négative ou
128 ?
D'accord, je vois... En fait c'est le unsigned byte qui manque à l'appel
sinon t'as raison c'est logique !
0x80 tient sur un octet, mais ce n'est pas un byte au sens Java puisque les byte sont signés et vont donc de -128 à 127... Comment Java pourrait-il deviner que ce 0x80 signifie une valeur négative ou 128 ?
D'accord, je vois... En fait c'est le unsigned byte qui manque à l'appel sinon t'as raison c'est logique !
Vincent Cantin
D'accord, je vois... En fait c'est le unsigned byte qui manque ?l'appel sinon t'as raison c'est logique !
Je ne pense pas qu'ils l'aient oublie. Ils ont surement compris qu'on peut s'en passer et que ca arrange plein de monde compare a ceux qui le veulent ... pour une raison de sucre syntaxique.
D'accord, je vois... En fait c'est le unsigned byte qui manque ?l'appel
sinon t'as raison c'est logique !
Je ne pense pas qu'ils l'aient oublie. Ils ont surement compris qu'on peut
s'en passer et que ca arrange plein de monde compare a ceux qui le veulent
... pour une raison de sucre syntaxique.
D'accord, je vois... En fait c'est le unsigned byte qui manque ?l'appel sinon t'as raison c'est logique !
Je ne pense pas qu'ils l'aient oublie. Ils ont surement compris qu'on peut s'en passer et que ca arrange plein de monde compare a ceux qui le veulent ... pour une raison de sucre syntaxique.
Bonjour, j'ai quelques problèmes avec la manipulation des bytes...
Lorsque j'écris :
final byte _fN = 0x80;
Le compilateur coince et me force à écrire
final byte _fN = (byte)0x80;
C'est idiot puisque 0x80 EST un byte... Un peu comme si je devais écrire final int toto = (int)123; ou final long titi = (long)9000;
C'est normal ? En tout cas c'est casse-pieds parce que ça pollue mon source avec des casts de tous les côtés.
Si vous avez un avis... Merci
Ô joie de l'unsigned en java En fait la notation hexa est interprétée comme un int donc oui il faut mettre un cast. Dans ton cas, 0x80 vaut 128 en int mais -128 en byte, et java tend a garder la valeur representée et non le stockage interne, ce qui parait logique, mais est assez énervant quand on veut faire du non signé. D'ailleurs, -(-128)=-128 :o)
Zouplaz wrote:
Bonjour, j'ai quelques problèmes avec la manipulation des bytes...
Lorsque j'écris :
final byte _fN = 0x80;
Le compilateur coince et me force à écrire
final byte _fN = (byte)0x80;
C'est idiot puisque 0x80 EST un byte... Un peu comme si je devais écrire
final int toto = (int)123;
ou
final long titi = (long)9000;
C'est normal ? En tout cas c'est casse-pieds parce que ça pollue mon source
avec des casts de tous les côtés.
Si vous avez un avis... Merci
Ô joie de l'unsigned en java
En fait la notation hexa est interprétée comme un int donc oui il faut
mettre un cast.
Dans ton cas, 0x80 vaut 128 en int mais -128 en byte, et java tend a
garder la valeur representée et non le stockage interne, ce qui parait
logique, mais est assez énervant quand on veut faire du non signé.
D'ailleurs, -(-128)=-128 :o)
Bonjour, j'ai quelques problèmes avec la manipulation des bytes...
Lorsque j'écris :
final byte _fN = 0x80;
Le compilateur coince et me force à écrire
final byte _fN = (byte)0x80;
C'est idiot puisque 0x80 EST un byte... Un peu comme si je devais écrire final int toto = (int)123; ou final long titi = (long)9000;
C'est normal ? En tout cas c'est casse-pieds parce que ça pollue mon source avec des casts de tous les côtés.
Si vous avez un avis... Merci
Ô joie de l'unsigned en java En fait la notation hexa est interprétée comme un int donc oui il faut mettre un cast. Dans ton cas, 0x80 vaut 128 en int mais -128 en byte, et java tend a garder la valeur representée et non le stockage interne, ce qui parait logique, mais est assez énervant quand on veut faire du non signé. D'ailleurs, -(-128)=-128 :o)
BJB
Zouplaz wrote:
Eric Jacoboni - :
Zouplaz writes:
final byte _fN = 0x80;
Le compilateur coince et me force à écrire
final byte _fN = (byte)0x80;
C'est idiot puisque 0x80 EST un byte...
0x80 tient sur un octet, mais ce n'est pas un byte au sens Java puisque les byte sont signés et vont donc de -128 à 127... Comment Java pourrait-il deviner que ce 0x80 signifie une valeur négative ou 128 ?
D'accord, je vois... En fait c'est le unsigned byte qui manque à l'appel sinon t'as raison c'est logique !
Bonjour, Le unsigned a été colontairement "oublié" de la spécification Java. Car dans la vrai vie, il n'est pas si utile que ça. Seul les API d'entrée sortie peuvent te permettre de lire des entiers non-signés (pour des raisons de compatibilité ascendente avec certains formats de fichiers par exemple)
Perso, j'aurais bien aimé : une synthaxe B comme il existe une synthaxe L pour les long, mais nul ne sait pourquoi elle n'existe pas ;-)
Voili ... A+ JB
Zouplaz wrote:
Eric Jacoboni - jaco@neottia.net :
Zouplaz <pouet@pouet.com> writes:
final byte _fN = 0x80;
Le compilateur coince et me force à écrire
final byte _fN = (byte)0x80;
C'est idiot puisque 0x80 EST un byte...
0x80 tient sur un octet, mais ce n'est pas un byte au sens Java
puisque les byte sont signés et vont donc de -128 à 127... Comment
Java pourrait-il deviner que ce 0x80 signifie une valeur négative ou
128 ?
D'accord, je vois... En fait c'est le unsigned byte qui manque à l'appel
sinon t'as raison c'est logique !
Bonjour,
Le unsigned a été colontairement "oublié" de la spécification Java.
Car dans la vrai vie, il n'est pas si utile que ça. Seul les API
d'entrée sortie peuvent te permettre de lire des entiers non-signés
(pour des raisons de compatibilité ascendente avec certains formats de
fichiers par exemple)
Perso, j'aurais bien aimé :
une synthaxe B comme il existe une synthaxe L pour les long,
mais nul ne sait pourquoi elle n'existe pas ;-)
0x80 tient sur un octet, mais ce n'est pas un byte au sens Java puisque les byte sont signés et vont donc de -128 à 127... Comment Java pourrait-il deviner que ce 0x80 signifie une valeur négative ou 128 ?
D'accord, je vois... En fait c'est le unsigned byte qui manque à l'appel sinon t'as raison c'est logique !
Bonjour, Le unsigned a été colontairement "oublié" de la spécification Java. Car dans la vrai vie, il n'est pas si utile que ça. Seul les API d'entrée sortie peuvent te permettre de lire des entiers non-signés (pour des raisons de compatibilité ascendente avec certains formats de fichiers par exemple)
Perso, j'aurais bien aimé : une synthaxe B comme il existe une synthaxe L pour les long, mais nul ne sait pourquoi elle n'existe pas ;-)
