Saucissonage d'un entier long
berfis
Membre
Bonjour,
Il n'y a pas si longtemps encore, quand la place était comptée (peut-être l'est-elle toujours?) je serrai une floppée de flags booléens dans un entier (ou un long) à coup de BITTST, BITSET, BITREV...
J'ai envie de stocker le plus de variables possibles dans le tag d'une view quelconque. Sachant que ces valeurs n'excéderont pas quelques dizaines, j'aimerais savoir:
a- la taille effective d'un tag (je crois que c'est un "long" signé)
b- comment découper et reconstituer.
L'instruction sizeOf (long) retourne 8. Puis-je m'y fier quel que soit le type de Mac?
Dans un long, je devrais pouvoir caser deux int ou 4 short. Vous confirmez?
Les fonctions "legacy" HiWord et LoWord retournent deux int extraites d'un long, exact?
Maintenant comment faire un HiShort et un LoShort sur ces int?
Merci d'avance!
Réponses
une union?
Moi j'utiliserais des bit fields dans une structure C.
http://publib.boulder.ibm.com/infocenter/macxhelp/v6v81/index.jsp?topic=%2Fcom.ibm.vacpp6m.doc%2Flanguage%2Fref%2Fclrc03defbitf.htm
On peut imaginer transtyper un signed long en struct C ?
J'utilise des typedef struct avec des bitfields sans problème sous iOS pour certains projets où la mémoire de mon objet connecté est limitée.
En fait, il y a un tas de facteurs qui entrent en compte; par exemple, ça varie en fonction de la cible de compilation (32 ou 64 bits). Il me semble qu'un NSInteger mesure 32 bits sur un processeur 32 bits et 64 sur un processeur 64 bits.
Les seuls types dont on est sûr de la taille sont les UInt8, SInt8 et compagnie.
Après, tu as aussi les notions de gros et petit-boutien qui rentrent en compte.
Enfin, quel est l'intérêt ? Tu vas compliquer ton code et le cheminement dans l'architecture pour gagner 8 octets ?
Oui, c'est possible.
Le probléme c'est le padding comme expliqué dans le lien que j'ai mis plus haut.
Si tu dois sauvegarder ce tag, tu dois passer par un objet NSNumber pour gérer l'endianess.
Je rejoins Ceroce, peu d'intérêt pour des bugs vicieux potentiels.
Non, la taille elle-même est peu importante, j'ai un nombre raisonnable d'objets. Je peux m'en sortir autrement, c'était simplement de la curiosité. De nostalgie, peut-être...
Quand je faisais de l'informatique industrielle, nous utilisions beaucoup les champs de bits, mais c'était vraiment de la programmation de bas niveau, nous avions une maà®trise totale du matériel, et gagner quelques octets était important.
Un exemple. Aujourd'hui, les formats de fichier binaires n'ont plus la côte. Par exemple, Microsoft a migré tous ses anciens formats vers des formats XML. C'est parce que l'interopérabilité et la compatibilité sont des considérations plus importantes que l'espace mémoire ou le temps de traitement requis.
Mettons que je veuille sauver des variables supplémentaires dans un nib. Puis-je alors utiliser les User Defined Runtime Attributes associées à des propriétés? Genre (j'invente) "couleur de fond", "durée de vie", "poids", etc...?
Mon application, dans sa forme actuelle, n'a pas de documents externes, je n'aime pas trop les userDefaults (de toute façon il faut les recoder au cas où les préférences auraient disparu), du coup je pensais élargir un peu le modèle grâce aux nibs...
Bah, je suis conscient que ça risque d'introduire des variables cachées dans mon code et que dans un mois je me demanderai "mais d'où vient cette valeur?" en ayant oublié de la chercher au plus profond de IB...
Good news! Peut-être que Word pourra enfin relire des fichiers Word !
C'est très exactement leur but. Alors oui. Par contre, je crois que ce n'est compatible que Mac OS 10.8, non ?
Il me semble que c'est compatible 10.6. Je crois me souvenir l'avoir utilisé pour mettre du relief sur un NSTextField.
C'est de plus en plus difficile de trouver de la documentation MacOS, je crois avoir trouvé, et tout à coup il y a un "segue", un "storyboard" ou un "UIMachin" qui m'indique que je ne suis pas au bon endroit. >:(
Il semble que cela soit dispo à partir de 10.6 et IOS 5.0
Sinon y a une doc Apple sur ces User Defined Runtime Attributes
J'ai pas trouvé grand chose ...