\nConsider a class with\na bunch of \nYou might be tempted to convert the \nSince a \nHow much did that savings cost you, and how much did you save anyway?\n<\/P>\n \nLet’s look at the cost of that savings.\nCode that updated the plain \nOn the other hand, when it’s a bitfield, updating it becomes trickier:\n<\/P>\n \nExercise<\/B>: Figure out how the above trick works.\n<\/P>\n \nConverting a \nbecomes\n<\/P>\n \nThe bitfield version is bigger by nine bytes.\n<\/P>\n \nLet’s sit down and do some arithmetic.\nSuppose each of these bitfielded fields is accessed six times\nin your code, three times for writing and three times for reading.\nThe cost in code growth is approximately 100 bytes.\nIt won’t be exactly 102 bytes because the optimizer may be able\nto take advantage of values already in registers for some operations,\nand the additional instructions may have hidden costs in terms of\nreduced register flexibility.\nThe actual difference may be more, it may be less, but for a\nback-of-the-envelope calculation let’s call it 100.\nMeanwhile,\nthe memory savings was 15 byte per class.\nTherefore, the breakeven point is seven.\nIf your program creates fewer than seven instances of this class,\nthen the code cost exceeds the data savings: Your memory optimization\nwas a memory de-optimization.\n<\/P>\n \nEven if you manage to come out ahead in the accounting ledger,\nit may be a win of just a few hundred bytes.\nThat’s an awful lot of extra hassle to save a few hundred bytes.\nAll somebody has to do is add an icon to a dialog box and your\nsavings will vanish.\n<\/P>\nBOOL<\/CODE> members:\n<\/P>\n\n\/\/ no nitpicking over BOOL vs bool allowed\nclass Pear {\n …\n BOOL m_peeled;\n BOOL m_sliced;\n BOOL m_pitted;\n BOOL m_rotten;\n …\n};\n<\/PRE>\nBOOL<\/CODE> fields\ninto bitfields:\n\nclass Pear {\n …\n BOOL m_peeled:1;\n BOOL m_sliced:1;\n BOOL m_pitted:1;\n BOOL m_rotten:1;\n …\n};\n<\/PRE>\nBOOL<\/CODE> is typedef’d as INT<\/I> (which on\nWindows platforms is a signed 32-bit integer),\nthis takes sixteen bytes and packs them into one.\nThat’s a 93% savings!\nWho could complain about that?\n<\/P>\nBOOL<\/CODE>\nm_sliced<\/CODE> member could do it by simply storing the result\ninto the member.\nSince it was a normal field,\nthis could be accomplished directly:\n<\/P>\n\n mov [ebx+01Ch], eax ; m_sliced = sliced\n<\/PRE>\n
\n add eax, eax ; shift “sliced” into the correct position\n xor eax, [ebx+01Ch] ; merge “sliced” with other bits\n and eax, 2\n xor [ebx+01Ch], eax ; store the new bitfield\n<\/PRE>\n
BOOL<\/CODE> to a single-bit field saved three bytes\nof data but cost you eight bytes of code when the member is assigned\na non-constant value.\nSimilarly, extracting the value gets more expensive.\nWhat used to be\n<\/P>\n\n push [ebx+01Ch] ; m_sliced\n call _Something@4 ; Something(m_sliced);\n<\/PRE>\n
\n mov ecx, [ebx+01Ch] ; load bitfield value\n shl ecx, 30 ; put bit at top\n sar ecx, 31 ; move down and sign extend\n push ecx\n call _Something@4 ; Something(m_sliced);\n<\/PRE>\n