将枚举值设置为 4 字节字符串 - 为什么？
我在 Mac OS SDK 中看到了与此类似的代码：
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'
};
这是我第一次看到此代码 - 我假设编译器将与字符串等效的 32 位整数分配给枚举值。我想不出为什么这可能比使用简单整数更好的理由。它在调试器中看起来很丑陋（你如何判断这些值中的哪一个对应于1919247481？）并且通常使调试变得困难。
那么，是否有任何理由将这些字符串分配给枚举值实际上是有意义的。
I saw code similar to this in the Mac OS SDK:
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'
};
It's the first time I've seen this - I assume the compiler assigns the 32-bit integer equivalent of the strings to the enum values. I cannot think of a single good reason why this might be preferred over using simple integers. It looks hideous in a debugger (how do you tell which of these values corresponds to 1919247481?) and makes debugging just hard in general.
So, is there any reason where assigning such strings to enum values actually makes sense.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
正是因为调试器，您才会做这样的事情。大多数调试器可以将内存显示为 ASCII，例如：
通过查看内存转储即可识别结构、常量等，这非常方便。特别是如果这些结构和/或常量之一覆盖了一堆您不希望的内存......
It's precisely because of the debugger that you would do such a thing. Most debuggers can show memory as ASCII, something like:
Being able to identify structures, constants, and so forth by just looking at a memory dump is pretty handy. Particularly if one of these structures and/or constants overwrote a bunch of memory you didn't want it to....
该格式称为四字符代码，或
FOURCC。顺便说一句，它起源于 Apple 的 Macintosh，如果你能以 ASCII 字符查看内存，那就非常方便了。这也是在文件中嵌入 4 字节标识符的便捷方法，尽管它会向后查找小端约定。That format is called a four-character code, or
FOURCC. Incidentally, it originated from Apple with the Macintosh, and it's pretty convenient if you can view memory in ASCII characters. It's also a convenient way to embed 4-byte identifiers in a file, although it will look backwards given a little-endian convention.在 gdb 中，您可以通过执行以下操作来检查常量：
尽管在 Intel 和其他小端系统上字符将被反转。使用 PowerPC 或 68k 处理器的老式 Macintosh 计算机在查看内存转储时会以正确的顺序显示字符。
In gdb, you can check the constant by doing:
Although on Intel and other little-endian systems the characters will be reversed. Older Macintosh computers that used PowerPC or 68k processors would show the characters in the correct order when viewing a memory dump.