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

[Rene Rebe]

On 19.02.2010, at 19:14, John McCall wrote:

> 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.

Though I was not talking about LISP.

> 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.

Of course I understand that. I was just trying to help by running TOT over some real world code, and frankly that was just the first (C++) one I tried, ...

Shall I open a bugzilla entry for this issue?

-- 
  René Rebe, ExactCODE GmbH, Jaegerstr. 67, DE-10117 Berlin
  http://exactcode.com | http://t2-project.org | http://rene.rebe.name

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100219/167edd43/attachment.html>