Does having constant variables as defines make your program smaller?

Question

Example:

#define Var1 35
static const int Var1( 35);

So while #define replaces everywhere that I've used Var1 with 35 at compile time (which I presume makes the compile time slightly longer, if you have a lot of them, as it parses the code), using a static const int makes the compiler consider it a variable.

Does this mean that when using static const int it'll increase the memory imprint of my program because it has to use memory for all those constants, or is this overhead pretty much optimised out by the compiler anyway?

The reason I ask is because I'm wondering if it'd be better, for situations like this, to have them as static const ints in debug mode (so you can easily see the values while debugging) but make them #defines in release mode so it would make the program smaller.

Answer 1

Using macros to “make the program smaller” is ungood for several reasons:

• Use of macros may instead make the program larger, or have no effect.
• Macros don't follow the scoping rules in C++. You risk inadvertent text replacement.
• Depending on the quality of the tools you may lose debug information.
• The advantageous effect, if it occurs, is marginal.
• The common convention for avoiding macro name clashes, namely ALL UPPERCASE, is an eyesore.

In short this is an example of a premature optimization.

And as Donald Knuth observed, premature optimizations are Evil™.

---

In passing, note that the static in

static const int Var1( 35);

… is redundant if this at namespace scope. A namespace scope constant has internal linkage by default. Just write

const int Var1 = 35;

… for the same effect, but IMHO more clear.

Answer 2

If it is static then the compiler can see that it's only used inside of that translation unit and not have to wonder how it's used externally, which is an advantage. If you don't do anything making it have to be an actual variable (such as creating a pointer to it) then the compiler will often optimize it out.

A friendlier approach could be using enums

enum { Var1 = 35 };

or in C++11, constexpr

constexpr int Var1 = 35;

These also have the advantage of not messing with a variable of the same name in another scope, if you later had

void f() {
    int Var1;
}

The #define would turn it into int 35;

But the difference in memory used will be very small, likely so insignificant it will never have any measurable impact on performance unless you're in an extremely limited environment.

Answer 3

"Does this mean that when using static const int it'll increase the memory imprint of my program because it has to use memory for all those constants, or is this overhead pretty much optimised out by the compiler anyway?"

That's totally dependent on your actual compiler's implementation, and how well optimization features are done with it.

For the case of simple numerical constants, that come within a logical context I'd pefer using enum declarations anyway.
And most of the time I find using a static const int Var1( 35); is the better choice vs a #define'd value, because I have full control over the scope where it should be seen.

Answer 4

Every decent compiler makes constant propagation to see which expression will remain constant. const helps the compiler in this job.

The next thing most compiler do very well is to remove unused parts of the code. This is why const variables which are not visible to the outside neither directly (local variables, static variables) nor indirectly (i.e. the address of the variable was not used as reference of for assigning a value to a pointer) are removed by the optimizer.

Example:

static const int e = 29;
int main() 
{
    int x = e; 
    return x + 1; 
}

Will be compiled by MSVC 2013 in release mode to :

PUBLIC  _main
_TEXT   SEGMENT
_main   PROC                        
    mov eax, 30                 ; optimized the code to return 30
    ret 0
_main   ENDP
_TEXT   ENDS
END                             ;  no place is reserved nowhere for the static.