Data types : Différences entre les architectures Intel et PPC
Eddy58
Membre
Le texte ci-dessous, provenant de la doc "UB programming guidelines", partie "Architectural Differences : Data Types", ne me laisse pas sans questions.
Le type "bool" y est décrit comme étant sujet à problèmes, surtout lors de l'enregistrement de structures de données sur la mémoire de masse. N'ayant pas de machine Intel sous la main pour vérifier s'il y a problème ou non, je me demande donc si une variable Bool faisant partie d'une classe modèle encodée avec NSCoder puis archivée avec NSArchiver sous PPC, poserait problème une fois le désarchivage et le décodage effectué sous Intel ? ???
[tt]
[coder encodeValueOfObjCType:@encode(BOOL) at:&variableBool];
[/tt]
A long double is 16 bytes on both architectures, but only 80 bits are significant in long double data types on Intel-based Macintosh computers.
A bool data type is a single byte on an x86 system, but four bytes on a PowerPC architecture. This size difference can cause alignment problems. You should use fixed-size data types to avoid alignment problems. (The bool data type is not the Carbon Boolean type, which is a fixed size of 1 byte.)
Existing document formats that include the bool data type as part of a data structure that is written directly to disk can be problematic because the data structure might not be laid out the same on both architectures. If you update the data structure definition to use the UInt32 data type or another fixed-size four-byte data type, the structure should then be portable, although you must swap bytes appropriately.
Le type "bool" y est décrit comme étant sujet à problèmes, surtout lors de l'enregistrement de structures de données sur la mémoire de masse. N'ayant pas de machine Intel sous la main pour vérifier s'il y a problème ou non, je me demande donc si une variable Bool faisant partie d'une classe modèle encodée avec NSCoder puis archivée avec NSArchiver sous PPC, poserait problème une fois le désarchivage et le décodage effectué sous Intel ? ???
[tt]
[coder encodeValueOfObjCType:@encode(BOOL) at:&variableBool];
[/tt]
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
C'est pour les cas où tu lis par exemple un fichier binaire à la main (entête de fichier image que tu lirais toi-même au lieu d'utiliser les classes Cocoa), où dans un cas une structure contenant un "bool" prendrait 3 octets de moins (1 octet pour le bool au lieu de 4) et décalerait la structure.
Mais c'est poru du bas niveau, de ce côté.
Avec les codeurs ça devrait pas poser de problèmes... Quoique si tu passes un fichier encodé sur Mac PPC et que tu le lis avec ton appli sous Mac Intel (ou vice-versa) ?? Mais je pense que de ce côté ils ont bien côté leurs NSCoders
Avant je fais ça :
BOOL repExist;
if (!([[NSFileManager defaultManager] fileExistsAtPath:_folderPath isDirectory:&repExist]) && !repExist)
{
}
et ça rentrait dans mon if...
Maintenant sur Intel, j'ai l'impression que je suis obligé d'initialiser BOOL repExist à NO pour que ça marche...
Cette ligne est une astuce C pour éviter d'écrire 2 IF...
Maintenant, je ne sais pas comment la version intel de GCC compile ça, alors essaie de redécomposer le test pour voir si ça passe :
Par contre, pour moi le type BOOL n'est pas en cause.
.
Attention !
Ne pas confondre le type bool et le type BOOL !
Le BOOL utilisé par Objective-C est un [tt]typedef char BOOL[/tt] (avant 10.2) et un [tt]typedef signed char BOOL[/tt] (à partir de 10.2). Voir dans le fichier objc.h.
Or, à ce qu'il me semble, le type char est de taille immuable (1 octet) quelque soit la platerforme, non ?
.
Ok, ok, I'm living... :(renaud):
J'espère pour toi, sinon t'es mort!
@LeMatouNoir : Mais non, ce n'est pas sale...;D