Définition des valeurs d'énumération sur des chaînes de 4 octets - pourquoi?

j'ai vu un code similaire à ceci dans le Mac OS SDK:Définition des valeurs d'énumération sur des chaînes de 4 octets - pourquoi?

enum { 
    kAudioFileStreamProperty_ReadyToProducePackets = 'redy', 
    kAudioFileStreamProperty_FileFormat    = 'ffmt', 
    kAudioFileStreamProperty_DataFormat    = 'dfmt', 
    kAudioFileStreamProperty_FormatList    = 'flst', 
    kAudioFileStreamProperty_MagicCookieData   = 'mgic', 
    kAudioFileStreamProperty_AudioDataByteCount  = 'bcnt', 
    kAudioFileStreamProperty_AudioDataPacketCount  = 'pcnt', 
    kAudioFileStreamProperty_MaximumPacketSize  = 'psze', 
    kAudioFileStreamProperty_DataOffset    = 'doff', 
    kAudioFileStreamProperty_ChannelLayout   = 'cmap', 
    kAudioFileStreamProperty_PacketToFrame   = 'pkfr', 
    kAudioFileStreamProperty_FrameToPacket   = 'frpk', 
    kAudioFileStreamProperty_PacketToByte    = 'pkby', 
    kAudioFileStreamProperty_ByteToPacket    = 'bypk', 
    kAudioFileStreamProperty_PacketTableInfo   = 'pnfo', 
    kAudioFileStreamProperty_PacketSizeUpperBound  = 'pkub', 
    kAudioFileStreamProperty_AverageBytesPerPacket = 'abpp', 
    kAudioFileStreamProperty_BitRate     = 'brat' 
};

C'est la première fois que je l'ai vu - je suppose que le compilateur attribue l'entier de 32 bits équivalent des chaînes aux valeurs ENUM. Je ne peux pas penser à une seule bonne raison pour laquelle cela pourrait être préféré à l'utilisation d'entiers simples. Il semble hideux dans un débogueur (comment dites-vous laquelle de ces valeurs correspond à 1919247481?) Et rend le débogage juste difficile en général. Donc, y a-t-il une raison pour attribuer de telles chaînes aux valeurs d'énumération?

Source

2010-03-29 psychotik

Je ne comprends pas le caractère littéral multi-caractères –

Une constante de caractère entier de plusieurs caractères est autorisée (par C99 au moins), mais la valeur est définie par l'implémentation (section 6.4.4.4). –

C'est précisément parce que du débogueur que vous feriez une telle chose. La plupart des débogueurs peuvent montrer la mémoire comme ASCII, quelque chose comme:

00000000: 12 34 56 78 90 12 45 67 12 34 56 78 89 ab cd ef .4Vx..Eg.4Vx....

être en mesure d'identifier les structures, les constantes, et ainsi de suite en regardant simplement à une décharge de la mémoire est très pratique. En particulier si l'une de ces structures et/ou constantes écrasait un tas de mémoire, vous ne le vouliez pas ...

Source

2010-03-29 23:55:51

Ah. Je ne pense pas que j'ai jamais eu besoin de voir la valeur d'un champ enum dans une fenêtre de mémoire pour une session de débogage en direct, mais je suppose que cela pourrait être utile dans les vidages mémoire hors ligne. Différent endian-rendrait certainement difficile/impossible à utiliser si. – psychotik

@psychotik, les stompers de mémoire sont le meilleur des cas. Imaginez une structure remplie de telles énumérations soufflant sur votre pile. Maintenant, quand vous regardez la mémoire avec le débogueur, vous pouvez espérer identifier ce qui s'est passé. L'endianisme n'est pas * un gros problème - vous vous êtes habitué à les lire à l'envers. –

Ce format est appelé un code à quatre caractères, ou FOURCC. Incidemment, il provient d'Apple avec le Macintosh, et c'est très pratique si vous pouvez voir la mémoire en caractères ASCII. C'est aussi un moyen pratique d'incorporer des identifiants de 4 octets dans un fichier, bien qu'il soit rétrogradé en raison d'une convention little-endian.

Source

2010-03-29 23:59:36 MSN

gdb, vous pouvez vérifier la constante en faisant:

print (char[4]) val

Bien sur Intel et d'autres systèmes peu endian les personnages seront inversés. Les ordinateurs Macintosh plus anciens qui utilisaient des processeurs PowerPC ou 68k affichaient les caractères dans le bon ordre lors de l'affichage d'une image mémoire.

Source

2010-03-30 00:03:04 dreamlax

Définition des valeurs d'énumération sur des chaînes de 4 octets - pourquoi?

Répondre

Questions connexes