Fonctionnement bit de signe, décalage [Résolu]

[atha2]

Bonjour,

J'aurai besoin d'aide pour la compréhension d'un code manipulant des bits. Le but du code est de récupérer le quartet de poids fort d'un byte (pour décoder du BCD). Ce code est générer automatiquement par un IDE mais j'ai un doute sur sa complexité:

Code :

1
2
3
byte b1 = ....;
byte b2 = (byte) ((((b1 & (byte) 0xF0) & (short) 0x00FF) >> (byte) 4) & (byte) 0x0F);

ne peut-on pas écrire simplement:

Code :

1
2
byteb2 = ((b1 & (byte) 0xF0) >> (byte) 4) & (byte) 0x0F;

??

voir même

Code :

1
2
byteb2 = (b1 >> (byte) 4) & (byte) 0x0F;

Ou alors il y a vraiment une embrouille avec le bit de signe dans certain cas ?

[dinobogan]

Les cast pour les opérateurs & et >> sont inutiles car les opérateurs seront toujours castés en int.

Le code suivant :

Code :

byte b2 = (byte) ((((b1 & (byte) 0xF0) & (short) 0x00FF) >> (byte) 4) & (byte) 0x0F)

devrait être simplifiable en :

Code :

byte b2 = (byte) ((b1 & 0xF0 ) >> 4 )

équivalent à :

Code :

byte b2 = (byte)( (b1 >> 4) & 0xF )

[atha2]

Merci pour ta réponse dinobogan

Envoyé par dinobogan

Les cast pour les opérateurs & et >> sont inutiles car les opérateurs seront toujours castés en int.

Je travail en JavaCard et selon les cartes, le type int n'est pas toujours disponible, d'où le cast de 4 en byte (ou short peu importe). Je ne l'avais pas précisé mais d'après https://forums.oracle.com/forums/thr...readID=1749150, l'opération est faite sur 32bits de la même façon qu'en Java standard.

Envoyé par dinobogan

Code :

byte b2 = (byte) ((b1 & 0xF0 ) >> 4 )

C'est pas plutôt :

Code :

byte b2 = (byte) ((b1 & 0xF0 ) >>> 4 )

? Pour éviter la propagation du bit de signe ?

[thelvin]

Envoyé par atha2

C'est pas plutôt :

Code :

byte b2 = (byte) ((b1 & 0xF0 ) >>> 4 )

? Pour éviter la propagation du bit de signe ?

En principe il n'y a pas de signe à propager, puisque l'opération & se fait sur 32 bits et que le 0xF0 s'assure que seuls les bits de 4 à 7 puissent être à autre chose que zéro. Le bit de signe, 31, est donc forcément à zéro et le résultat forcément positif.

En principe. Mais j'avoue ne pas savoir comment une techno Java s'adapte à la non-existence du type int.

[atha2]

Oui c'est vrai.
Merci.