dans les pref de l'application , j'ai un PSTextField ou je rentre une valeur ( par exemple 31999 ) , je dois ensuite récupérer cette valeur en hexa soit 0x7CFF
Si la variable qui contient 31999 (de type int) est "valeur". Et si on veut la première partie dans "octet2" et la seconde dans "octet1" (toute les deux de type int)
octet2 = (valeur >> 8 ) & 255 ;<br />octet1 = valeur & 255 ;
Si la variable qui contient 31999 (de type int) est "valeur". Et si on veut la première partie dans "octet2" et la seconde dans "octet1" (toute les deux de type int)
octet2 = (valeur >> 8 ) & 255 ;<br />octet1 = valeur & 255 ;
Dans le cas des opérateurs binaires, on bosse plus volontiers avec des valeurs hexa (bien plus lisible !) :P
octet2 = (valeur >> 8 ) & 0xFF ;<br />octet1 = valeur & 0xFF ;
Oui, mais gardez bien en tête (surtout Lastiko pour qui je suis pas sûr que ce soit clair vu comment la question était posée) que l'hexa n'est qu'une représentation parmi d'autres d'un nombre ! Pour moi la question n'était pas bonne : le truc n'est pas de convertir ton nombre en hexa : l'affichage hexa n'est qu'une représentation du nombre, comme si tu demandais d'afficher un nombre avec des espaces entre les milliers ou pas... ce n'est que pour le rendre plus lisible pour un contexte donné.
Mais toi ce que tu veux faire c'est décomposer ton nombre en octets, sa représentation octet par octet. Après que tu écrives sur ton papier ou dans tes NSLogs ces octets en hexa ou en décimal ou en binaire pour vérifier que tout se passe bien... ça change rien. 32 en décimal, 0x20 en hexa, o040 en octal... tout ça c'est du pareil au même :P
En fait tu parlais de représentation hexa parce qu'il se trouve que cette représentation, comme la représentation binaire (qui est cependant moins lisible pour ton cas), permet ensuite facilement d'isoler les octets. Si un nombre est représenté en hexa par 0xABCD, il est facile de voir que les octets qui le composent sont 0xAB et 0xCD, autrement dit 171 et 205 en décimal. Mais tu n'es pas obligé de passer par cette représentation pour décomposer ton nombre en octets individuels, comme te l'a montré jp :P Tu peux même totalement t'en passer, et utiliser les décalages comme il te le montre pour isoler les octets de ton nombre.
en tout cas merci pour les explications , mon probleme est que je suis pas sur et certain que la machine accepte les commandes si elle sont pas comme elle les attends , enfin j'ai pas tester non plus ....
dans 1241990395:
Tout a fait d'accord avec Ali... Il y a d'ailleurs même les problèmes d'endianness...
Le premier octet de 31999 ne sera pas le même sur une machine Intel et sur une machine PPC par exemple.
par contre la , j'aimerais bien comprendre ? c'est peut etre bon a savoir pour le prochain prog
...................... je viens de tester Alors effectivement si je fais comme expliqué plus haut ca marche nikel
int DeviceHex = 31999 ;<br /> int DeviceHexa1 = (DeviceHex >> 8 ) & 255;<br /> int DeviceHexa2 = DeviceHex & 255;
Par contre dés que je veux utiliser le Setting Bundle ou je rentre cette valeur attendu ( 31999 ici dans l'exemple ) , bon la ca marche carrément pas comme je veux
int DeviceHex = Device_Master_preference;<br /> int DeviceHexa1 = (DeviceHex >> 8 ) & 255;<br /> int DeviceHexa2 = DeviceHex & 255;
la le resultat est 55344 , ( bon pour la bonne nouvelle la machine l'accepte mais bon c'est un coup de pot )
C'est parce que tu récupères ta valeur dans une chaà®ne de caractères et que tu l'utilises ensuite comme un entier ; le compilateur ne t'engueule pas quand tu fais ça ? Il faut utiliser la méthode intValue sur la NSString que tu récupères pour faire la conversion de la chaà®ne de caractères vers un entier :
int DeviceHex = [Device_Master_preference intValue];
octet2 = (valeur >> 8 ) & 255 ;<br />octet1 = valeur & 255 ;
Ne donne pas des octets ordonnés tels qu'ils sont en mémoire, mais plutôt des coefficients en base 256... (c'est d'ailleurs en général le genre de code utilisé pour sérialiser un nombre de manière endian-safe).
C'est parce que tu récupères ta valeur dans une chaà®ne de caractères et que tu l'utilises ensuite comme un entier ; le compilateur ne t'engueule pas quand tu fais ça ? Il faut utiliser la méthode intValue sur la NSString que tu récupères pour faire la conversion de la chaà®ne de caractères vers un entier :
int DeviceHex = [Device_Master_preference intValue];
Réponses
Si vous voulez récupérer dans une NSString la valeur en héxa, il y a la commande : stringWithFormat:@%X.
Eric.
;-)
Mais au moins j'ai essayé.
Dans le cas des opérateurs binaires, on bosse plus volontiers avec des valeurs hexa (bien plus lisible !) :P
Pour moi la question n'était pas bonne : le truc n'est pas de convertir ton nombre en hexa : l'affichage hexa n'est qu'une représentation du nombre, comme si tu demandais d'afficher un nombre avec des espaces entre les milliers ou pas... ce n'est que pour le rendre plus lisible pour un contexte donné.
Mais toi ce que tu veux faire c'est décomposer ton nombre en octets, sa représentation octet par octet.
Après que tu écrives sur ton papier ou dans tes NSLogs ces octets en hexa ou en décimal ou en binaire pour vérifier que tout se passe bien... ça change rien. 32 en décimal, 0x20 en hexa, o040 en octal... tout ça c'est du pareil au même :P
En fait tu parlais de représentation hexa parce qu'il se trouve que cette représentation, comme la représentation binaire (qui est cependant moins lisible pour ton cas), permet ensuite facilement d'isoler les octets. Si un nombre est représenté en hexa par 0xABCD, il est facile de voir que les octets qui le composent sont 0xAB et 0xCD, autrement dit 171 et 205 en décimal. Mais tu n'es pas obligé de passer par cette représentation pour décomposer ton nombre en octets individuels, comme te l'a montré jp :P Tu peux même totalement t'en passer, et utiliser les décalages comme il te le montre pour isoler les octets de ton nombre.
Le premier octet de 31999 ne sera pas le même sur une machine Intel et sur une machine PPC par exemple.
par contre la , j'aimerais bien comprendre ? c'est peut etre bon a savoir pour le prochain prog
......................
je viens de tester
Alors effectivement si je fais comme expliqué plus haut ca marche nikel
Par contre dés que je veux utiliser le Setting Bundle ou je rentre cette valeur attendu ( 31999 ici dans l'exemple ) , bon la ca marche carrément pas comme je veux
la valeur je la récupére comme cela :
et ensuite ( c'est peut etre la mon erreur )
la le resultat est 55344 , ( bon pour la bonne nouvelle la machine l'accepte mais bon
je veux bien comprendre le pourquoi du comment
Il faut utiliser la méthode intValue sur la NSString que tu récupères pour faire la conversion de la chaà®ne de caractères vers un entier :
Bonne lecture :P
En gros, garde en tête que ton code :
Ne donne pas des octets ordonnés tels qu'ils sont en mémoire, mais plutôt des coefficients en base 256...
(c'est d'ailleurs en général le genre de code utilisé pour sérialiser un nombre de manière endian-safe).
Ok ca marche :P
Ben j'avais juste un warning
En tout cas merci beaucoup
M'en vais lire ton wiki Schlum