error: initialized if it is a static const integral data member

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

error: initialized if it is a static const integral data member

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

  René

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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: error: initialized if it is a static const integral data member

Douglas Gregor

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.

        - Doug
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: error: initialized if it is a static const integral data member

Rene Rebe

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é

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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: error: initialized if it is a static const integral data member

Douglas Gregor

On Feb 19, 2010, at 8:41 AM, Rene Rebe wrote:

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

If we do that, we'll end up breaking an invariant of the C++ abstract syntax tree, which is that we only have in-class initializers of integral or enumeration type. That has ramifications on other parts of the compiler, which need to be understood.

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

It's not "Clang's liking", it's an ISO standard. Clang aims to be a highly-conformant C++ compiler, and that means following the letter of the standard. We make some concessions to compatibility, but a problem typically has to occur in a lot of code or be extremely hard to work around before we'll consider such a change.

        - Doug
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: error: initialized if it is a static const integral data member

Cédric Venet
In reply to this post by Rene Rebe
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.

regards
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: error: initialized if it is a static const integral data member

Rene Rebe

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

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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: error: initialized if it is a static const integral data member

John McCall
On Feb 19, 2010, at 10:31 AM, Rene Rebe wrote:
>> 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, ...

Don't get me wrong, the effort is appreciated.  I'm just letting you know that we do consider this an error in the user program.  We could probably reasonably support this as an extension in gnuc++98 mode;  we'd have to evaluate its implications, though.

> Shall I open a bugzilla entry for this issue?

Please.  In fact, please file bugs for all of these.

John.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: error: initialized if it is a static const integral data member

Ahmed Charles
In reply to this post by Douglas Gregor
On Fri, Feb 19, 2010 at 8:58 AM, Douglas Gregor <[hidden email]> wrote:
We make some concessions to compatibility, but a problem typically has to occur in a lot of code or be extremely hard to work around before we'll consider such a change.

Do all of these instances produce extension warnings and is there a mode to turn them off? I'm just curious.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: error: initialized if it is a static const integral data member

Douglas Gregor

On Feb 19, 2010, at 4:28 PM, Ahmed Charles wrote:

On Fri, Feb 19, 2010 at 8:58 AM, Douglas Gregor <[hidden email]> wrote:
We make some concessions to compatibility, but a problem typically has to occur in a lot of code or be extremely hard to work around before we'll consider such a change.

Do all of these instances produce extension warnings and is there a mode to turn them off? I'm just curious.

Clang has fine-grained control of warnings; check out the user manual when clang.llvm.org comes back online (also in docs/UsersManual.html, if you have a copy of Clang's source tree).

- Doug

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: error: initialized if it is a static const integral data member

Sebastian Redl
In reply to this post by John McCall
John McCall wrote:
> Don't get me wrong, the effort is appreciated.  I'm just letting you know that we do consider this an error in the user program.  We could probably reasonably support this as an extension in gnuc++98 mode;  we'd have to evaluate its implications, though.
>  
Don't we have to support this for C++0x anyway?

Sebastian
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: error: initialized if it is a static const integral data member

John McCall
On Feb 20, 2010, at 3:06 AM, Sebastian Redl wrote:
> John McCall wrote:
>> Don't get me wrong, the effort is appreciated.  I'm just letting you know that we do consider this an error in the user program.  We could probably reasonably support this as an extension in gnuc++98 mode;  we'd have to evaluate its implications, though.
>>
> Don't we have to support this for C++0x anyway?

Yes, and we will need to evaluate its implications then, too. :)  C++0x constant semantics are a significant extension.

John.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: error: initialized if it is a static const integral data member

Rene Rebe
In reply to this post by John McCall
On 19.02.2010, at 20:06, John McCall wrote:

> On Feb 19, 2010, at 10:31 AM, Rene Rebe wrote:
>>> 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, ...
>
> Don't get me wrong, the effort is appreciated.  I'm just letting you know that we do consider this an error in the user program.  We could probably reasonably support this as an extension in gnuc++98 mode;  we'd have to evaluate its implications, though.
>
>> Shall I open a bugzilla entry for this issue?
>
> Please.  In fact, please file bugs for all of these.


http://llvm.org/bugs/show_bug.cgi?id=6384

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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: error: initialized if it is a static const integral data member

John McCall
On Feb 22, 2010, at 3:47 AM, Rene Rebe wrote:

> On 19.02.2010, at 20:06, John McCall wrote:
>> On Feb 19, 2010, at 10:31 AM, Rene Rebe wrote:
>>>> 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, ...
>>
>> Don't get me wrong, the effort is appreciated.  I'm just letting you know that we do consider this an error in the user program.  We could probably reasonably support this as an extension in gnuc++98 mode;  we'd have to evaluate its implications, though.
>>
>>> Shall I open a bugzilla entry for this issue?
>>
>> Please.  In fact, please file bugs for all of these.
>
> http://llvm.org/bugs/show_bug.cgi?id=6384

Thanks!

John.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev