Why can't I have a non-integral static const member in a class?

Question

I noticed C++ will not compile the following:

class No_Good {   static double const d = 1.0; }; 

However it will happily allow a variation where the double is changed to an int, unsigned, or any integral type:

class Happy_Times {   static unsigned const u = 1; }; 

My solution was to alter it to read:

class Now_Good {   static double d() { return 1.0; } }; 

and figure that the compiler will be smart enough to inline where necessary... but it left me curious.

Why would the C++ designer(s) allow me to static const an int or unsigned, but not a double?

Edit: I am using visual studio 7.1 (.net 2003) on Windows XP.

Edit2:

Question has been answered, but for completion, the error I was seeing:

error C2864: 'd' : only const static integral data members can be initialized inside a class or struct 

Answer 1

The problem is that with an integer, the compiler usually doesn't have to ever create a memory address for the constant. It doesn't exist at runtime, and every use of it gets inlined into the surrounding code. It can still decide to give it a memory location - if its address is ever taken (or if it's passed by const reference to a function), that it must. In order to give it an address, it needs to be defined in some translation unit. And in that case, you need to separate the declaration from the definition, since otherwise it would get defined in multiple translation units.

Using g++ with no optimization (-O0), it automatically inlines constant integer variables but not constant double values. At higher optimization levels (e.g. -O1), it inlines constant doubles. Thus, the following code compiles at -O1 but NOT at -O0:

// File a.h class X {  public:   static const double d = 1.0; };  void foo(void);  // File a.cc #include <stdio.h>  #include "a.h"  int main(void) {   foo();   printf("%g\n", X::d);    return 0; }  // File b.cc #include <stdio.h>  #include "a.h"  void foo(void) {   printf("foo: %g\n", X::d); } 

Command line:

g++ a.cc b.cc -O0 -o a   # Linker error: ld: undefined symbols: X::d g++ a.cc b.cc -O1 -o a   # Succeeds 

For maximal portability, you should declare your constants in header files and define them once in some source file. With no optimization, this will not hurt performance, since you're not optimizing anyways, but with optimizations enabled, this can hurt performance, since the compiler can no longer inline those constants into other source files, unless you enable "whole program optimization".

Answer 2

I see no technical reason why

struct type {     static const double value = 3.14; }; 

is forbidden. Any occasion you find where it works is due to non-portable implementation defined features. They also seem to be of only limited use. For integral constants initialized in class definitions, you can use them and pass them to templates as non-type arguments, and use them as the size of array dimensions. But you can't do so for floating point constants. Allowing floating point template parameters would bring its own set of rules not really worth the trouble.

Nonetheless, the next C++ version will allow that using constexpr:

struct type {     static constexpr double value = 3.14;     static constexpr double value_as_function() { return 3.14; } }; 

And will make type::value a constant expression. In the meantime, your best bet is to follow the pattern also used by std::numeric_limits:

struct type {     static double value() { return 3.14; } }; 

It will not return a constant expression (value is not known at compile time), but that only matters theoretical, since practical the value will be inlined anyway. See the constexpr proposal. It contains

4.4

Floating-point constant expressions

Traditionally, evaluation of floating-point constant expression at compile-time is a thorny issue. For uniformity and generality, we suggest to allow constant-expression data of floating point types, initialized with any floating-point constant expressions. That will also increase compatibility with C99 [ISO99, §6.6] which allows

[#5] An expression that evaluates to a constant is required in several contexts. If a floating expression is evaluated in the translation envi- ronment, the arithmetic precision and range shall be at least as great as if the expression were being evaluated in the execution environ- ment.