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.
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….