Data types : Différences entre les architectures Intel et PPC

Eddy58Eddy58 Membre
07:47 modifié dans API AppKit #1
Le texte ci-dessous, provenant de la doc "UB programming guidelines", partie "Architectural Differences : Data Types", ne me laisse pas sans questions.


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]

Réponses

  • AliGatorAliGator Membre, Modérateur
    07:47 modifié #2
    Non avec le codeur ça ne posera pas de problèmes.
    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 ;)
  • Eddy58Eddy58 Membre
    07:47 modifié #3
    Ok Ali, je me dis la même chose, normalement NSCoder doit nous isoler de ce problème. En faites en examinant cette doc, ils parlent du fonctionnement de la directive @encode(), et ils disent que cette directive transforme les types en chaines en faites, donc je pense que ça règle le problème. 8)
  • muqaddarmuqaddar Administrateur
    07:47 modifié #4
    Je reviens sur cette histoire de BOOL...

    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...
  • BruBru Membre
    07:47 modifié #5
    dans 1146685070:

    if (!([[NSFileManager defaultManager] fileExistsAtPath:_folderPath isDirectory:&repExist]) && !repExist)


    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 :
    <br />BOOL repExist, isRep;<br />repExist=[[NSFileManager defaultManager] fileExistsAtPath:_folderPath isDirectory:&amp;isRep];<br />if (repExist==NO || isRep==NO) <br />{<br />&nbsp; &nbsp; // ...<br />}<br />
    


    Par contre, pour moi le type BOOL n'est pas en cause.

    .
  • BruBru Membre
    07:47 modifié #6
    dans 1144158423:

    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]


    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 ?

    .
  • LeChatNoirLeChatNoir Membre, Modérateur
    07:47 modifié #7
    Ca devient crade vos histoires de bool....

    Ok, ok, I'm living...  :(renaud):
  • 07:47 modifié #8
    dans 1146734571:

    Ok, ok, I'm living...  :(renaud):


    J'espère pour toi, sinon t'es mort!
  • LeChatNoirLeChatNoir Membre, Modérateur
    07:47 modifié #9
    "leaving", sorry master  o:)
  • Eddy58Eddy58 Membre
    07:47 modifié #10
    @Bru : Merci pour les précisions, j'utilise le même code qu'hoksitan, donc j'aimerais bien savoir la finalité de la chose sur Intel. :)

    @LeMatouNoir : Mais non, ce n'est pas sale...;D
  • muqaddarmuqaddar Administrateur
    07:47 modifié #11
    Merci Bru, je vais faire ton test... ;-)
Connectez-vous ou Inscrivez-vous pour répondre.