[cfe-dev] error: initialized if it is a static const integral data member

[John McCall]

On Feb 19, 2010, at 9:14 AM, Rene Rebe wrote:

> 
> On 19.02.2010, at 18:07, Cédric Venet wrote:
> 
>> Le 19/02/2010 17:41, Rene Rebe a écrit :
>>> 
>>> On 19.02.2010, at 17:34, Douglas Gregor wrote:
>>> 
>>> 
>>>> On Feb 19, 2010, at 7:50 AM, Rene Rebe wrote:
>>>> 
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> still getting some production code to compile the next error is:
>>>>> 
>>>>> test.cc:5:26: error: in-class initializer has non-integral, non-enumeration type 'double'
>>>>> 
>>>>> While the type is a double in this case. This is tested in the clang testsuite:
>>>>> 
>>>>> test/SemaTemplate/instantiate-static-var.cpp
>>>>> 
>>>>> template<typename T>
>>>>> class Y {
>>>>> static const T value = 0; // expected-error{{'value' can only be initialized if it is a static const integral data member}}
>>>>> };
>>>>> 
>>>>> Y<float>  fy; // expected-note{{in instantiation of template class 'class Y<float>' requested here}}
>>>>> 
>>>>> G++ (even 4.4) does not even warn about this on neither -Wall, nor -Wextra, only with -pedantic. I assume due to this other POD initialization, especially of FP types will occur in quite some shipping code and thus suggest making it a warning, likewise.
>>>>> 
>>>> 
>>>> Or they are treating it like an out-of-class initializer. It's hard to tell.
>>>> 
>>>> But the code is clearly wrong, and Clang is right to diagnose it.
>>>> 
>>> 
>>> I did not mean to remove the diagnostic, but make it a warning. Personally I find those arbitrary and artificial C++ limitations just annoying. We certainly can not expect the world's source code to be rewritten to match clang's liking when other compiler accept the code.
>>> 
>>> René
>>> 
>>> 
>> 
>> Not all compiler accept this code (i.e. MSVC). It is a good things that by default, clang try to be as standard compliant as possible. You can always have/use a dialect gnu-c++ if you want to use some extension but it decrease the portability of the code.
> 
> 
> Currently I just want to check the state of Clang++ and AFAICS there is currently no option to compile this kind of code anyway.
> 
> Given that even the latest GCC-4.4.x does not even warn about it at -Wall or -Wextra, only at -pedantic I'd not be surprised to see it in wide use. It's certainly not that technologically challenging to initialize a static const float or double, ...

It's not that technologically challenging to write a lisp interpreter, either, and yet clang has the temerity to reject my code if I write (lambda (x) x).  Standards are how we adjudicate differences between implementations.

We very well might eventually implement a "heinous g++ compatibility mode", but I hope you can understand that it is not our current focus.  This is far from the most important compatibility problem that will face C++ code written against g++'s extremely lax implementation;  two-phase lookup problems are much more prevalent and cannot just be patched over without severely compromising the design, efficiency, and diagnostic quality of our template system.

John.