Let me begin by declaring my intention. In the old (C ++) days, we would have code like:
class C { public: enum {SOME_VALUE=27}; };
Then we could use SOME_VALUE in all of our code as a compile-time constant, and wherever the compiler sees C::SOME_VALUE , it simply inserts the literal 27.
Now, it seems more acceptable to change this code to something like:
class C { public: static constexpr int SOME_VALUE=27; };
It looks a lot cleaner, gives SOME_VALUE well-defined type, and seems to be the preferred approach with C ++ 11. The problem (unforeseen, at least for me) is that it also causes scripts in which SOME_VALUE needed make external. That is, in some cpp file we need to add:
constexpr int C::SOME_VALUE;
Cases that lead to this occur when SOME_VALUE links are SOME_VALUE , which is quite common in the code of the C ++ standard library (see the example at the bottom of this question). By the way, I use gcc 4.7.2 as my compiler.
Due to this dilemma, I have to revert to defining SOME_VALUE as an enum (i.e. old school) to avoid having to add a definition to the cpp file for some, but not all of my static constexpr member variables. Is there no way to tell the compiler that constexpr int SOME_VALUE=27 means that SOME_VALUE should be considered only as a compile-time constant and never an object with external connection? If you see a link to the constant used with it, create a temporary one. If you see its address, generate a compile-time error, if necessary, because it is a compile-time constant and nothing else.
Here is some seemingly benign code sample that forces us to add a definition for SOME_VALUE to the cpp file (once again, checked with gcc 4.7.2):
Adding the following line to the code in the file area will result in an error:
constexpr int C::SOME_VALUE;