C++ Semantics of 'Static Const' VS 'Const'

C++ semantics of `static const` vs `const`

At file scope, no difference in C++. const makes internal linkage the default, and all global variables have static lifetime. But the first variant has the same behavior in C, so that may be a good reason to use it.

Within a function, the second version can be computed from parameters. In C or C++ it doesn't have to be a compile-time constant like some other languages require.

Within a class, basically the same thing as for functions. An instance const value can be computed in the ctor-initializer-list. A static const is set during startup initialization and remains unchanged for the rest of the program. (Note: the code for static members looks a little different because declaration and initialization are separated.)

Remember, in C++, const means read-only, not constant. If you have a pointer-to-const then other parts of the program may change the value while you're not looking. If the variable was defined with const, then no one can change it after initialization but initialization can still be arbitrarily complex.

Is there difference between a static const and const variable inside a c++ class in terms of its storage

I suppose, technically, if the compiler knew that you never performed sizeof on modbus, and never took the address of these members through different modbus* pointers, and knew that they were only ever initialised with the exact same trivial value, it might use the "as-if" rule to merge them into one and remove them from the class in terms of storage. (If it couldn't guarantee just one of these things, the rules of the language would be violated.)

But that's a tall order (particularly when you consider multiple translation units), and would not really be useful.

So no. I don't expect that this would ever happen.

You should indeed make those things static const (with perhaps a sprinkling of constexpr).

Class scope constants: const vs static const

I'd prefer 2nd variant, provided the const in the 1st case is private.

Why should one pollute the class declaration with redundant information?
Consider, you are implementing a protocol parser, with many many constants. How will the class declaration look like?

Another issue is, why should you type the name of the const twice? I try to keep definition and initialization as close as possible.

Just an opinion.

What does 'const static' mean in C and C++?

It has uses in both C and C++.

As you guessed, the static part limits its scope to that compilation unit. It also provides for static initialization. const just tells the compiler to not let anybody modify it. This variable is either put in the data or bss segment depending on the architecture, and might be in memory marked read-only.

All that is how C treats these variables (or how C++ treats namespace variables). In C++, a member marked static is shared by all instances of a given class. Whether it's private or not doesn't affect the fact that one variable is shared by multiple instances. Having const on there will warn you if any code would try to modify that.

If it was strictly private, then each instance of the class would get its own version (optimizer notwithstanding).

static const VS const local variable, which one performs better?

Why I can't say (and don't trust anybody who claims otherwise) which one is faster without profiling on a particular system, it is worthy to consider performance implications in both cases, assuming customary optimizations.

In your second case, you will be creating a std::unordered_map with every function entrance. I know of no optimizer which might convert this auto variable into static one, and I can't imagine how it even might be possible for a compiler to figure out. The major performance hits there would be memory allocation (quite significant in multithreading environment, much less so in single threaded ones) and a cost of initializing the map with three elements - likely, another memory allocation for map nodes, and possibly memory allocation for strings, unless SSO is enabled on target platform.

First version will not suffer from performance issues described above - it will perform all necessary memory allocations only once, when the function is called first time.

However, it will be affected by something else - since initialization of static locals is thread-safe since 2011, there would be a cost of checking the hidden boolean flag. There is also a question of memory synchronization involved, but since any sane compiler will use double-checked locking here, those questions should not be of relevance. As is, all that remains is the check for the boolean on each entrance and a branch. Hopes are, branch predictor is going to kick in pretty soon and do a good job for us, so all that remains is simple comparison cost, which is pretty much nothing.

---

Related Topics