My basic situation: I have an include file that has something like #define foo (Flag1 | Flags2 | Flag3), so it’s a predefined combination of bit flags. For the sake of type-safety, I wanted to replace these #defines by static consts, i.e. static const int foo = (Flag1 | Flag2 | Flag3) (or similar). This include file is included in dozens of places in the program.
Now when I’m doing a release build with all relevant optimisation options enabled (using the C++ compiler of VS2010), replacing the #defines seems to increase the executable by a few KiB, depending on how many constants I replaced.
Why does this happen? To my knowledge, integer constants are supposed to be “inlined” into the ASM code that is produced if possible, and I don’t see how using a static const vs #define would make a difference here. Clearly, the variable isn’t inlined as the disassembly shows:
#define:
01325041 or eax,0FFD87FE0h
static int:
011E5451 or eax,dword ptr [CMainFrame::s_TemplateModulePaths+38h (151F008h)]
So the final question is: How can I avoid #define but still rely on the variable being inserted directly into the generated assembly?
As seen in the comments, the typesafe operator| overloading for my enums seems to prevent VC++ from inlining the ORed value. I guess I’ll keep using the
#defineversion as I hate increasing the executable size if there’s no benefits (no, this is not premature optimization) – after all, it doesn’t increase readability, and since the combination of flags is already of my flagset enum type, I also don’t lose any type-safety, I guess.