tags:

views:

121

answers:

3

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.

+5  A: 

It's precisely because of the debugger that you would do such a thing. Most debuggers can show memory as ASCII, something like:

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

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

Carl Norum
Ah. I don't think I've ever needed to view the value of an enum field in a memory window for a live debug session, but I guess this could be helpful in offline memory dumps. Different endian-ness would definitely makes it hard/impossible to use though.
psychotik
@psychotik, memory stompers are the best case. Imagine a structure filled with such enumerations blowing over your stack. Now when you look at memory with the debugger, you can hope to identify what happened. Endianness is not *that* big a deal - you get used to reading them backwards.
Carl Norum
+3  A: 

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.

MSN
A: 

In gdb, you can check the constant by doing:

print (char[4]) val

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.

dreamlax