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

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é

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

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é

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

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

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.

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

class Y {

static const T value = 0; // expected-error{{‘value’ can only be initialized if it is a static const integral data member}}

};

Y fy; // expected-note{{in instantiation of template class ‘class Y’ 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?

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.

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

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

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

John.

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

Thanks!

John.