First lets look at the code generated with some simple examples.
extern int global_writable_var = 9; // a.cpp extern const int global_const_var = 9; // a.cpp
Generate the assembly source with
cl /c /Fa a.cpp # MSVC: /c means compile only, don't link. /Fa means output assembly
gcc -c -S a.cpp # GCC: -c means compile only, don't link. -S means output assembly
And we get:
// MSVC : a.asm PUBLIC ?global_writable_var@@3HA ; global_writable_var PUBLIC ?global_const_var@@3HB ; global_const_var CONST SEGMENT ?global_const_var@@3HB DD 09H ; global_const_var CONST ENDS _DATA SEGMENT ?global_writable_var@@3HA DD 09H ; global_writable_var _DATA ENDS // GCC : a.s .globl global_writable_var ; attributes of the variable .data .align 4 .type global_writable_var, @object .size global_writable_var, 4 global_writable_var: .long 9 ; variable definition .globl global_const_var .section .rodata .align 4 .type global_const_var, @object .size global_const_var, 4 global_const_var: .long 9
The key thing to notice here is that the compiler puts constant data into a separate areas (try adding more variables). Typically these areas (known as the _data and _const segments on windows, known as .data and .rodata sections on unix) will have different memory protection bits enabled – thus writes to global_const_var would cause a hardware exception. Also if you’re compiling a shared library or have several executables running, then each time the library is loaded the data segment is duplicated, but the constant section may be shared between all instances.
Thus if you have a library (dll) which is linked many times (as is very common in linux for instance – try “ldd /path/to/executable” on some programs), the overhead can really add up.