complex support when using -std=c++11

[Marc Glisse]

On Thu, 12 Nov 2015, D Haley wrote:

> I am currently trying to understand an issue to do with complex number 
> support in gcc.
>
> Consider the following code:
>
> #include <complex.h>
> int main()
> {
>        float _Complex  a = _Complex_I;
>
> }
>
> Attempting to compile this with  these commands is fine:
> $ g++ tmp.cpp -std=gnu++11
> $ g++ tmp.cpp
>
> Clang is also fine:
> $ clang tmp.cpp -std=c++11

Not here, I am getting the same error with clang (or "use of undeclared 
identifier '_Complex_I'" with libc++). This probably depends more on your 
libc.

> Attempting to compile with c++11 is not:
> $ g++ tmp.cpp -std=c	++11
> In file included from /usr/include/c++/5/complex.h:36:0,
>                 from tmp.cpp:2:
> tmp.cpp: In function ‘int main()’:
> tmp.cpp:5:29: error: unable to find numeric literal operator ‘operator""iF’
>         float _Complex  a = _Complex_I;
>                             ^
> tmp.cpp:5:29: note: use -std=gnu++11 or -fext-numeric-literals to enable more 
> built-in suffixes
>
> I'm using debian testing's gcc:
> $ gcc --version
> gcc (Debian 5.2.1-17) 5.2.1 20150911
> ...
>
>
> I discussed this on #gcc, and it was suggested (or I misunderstood) that this 
> is intentional, and the library should not support c-type C++ primitives - 
> however I can find no deprecation notice for this, nor does it appear that 
> the c++11 standard (as far as I can see from a quick skim) has changed the 
> behaviour in this regard.
>
> Is this intended behaviour, or is this a bug? This behaviour was noticed when 
> troubleshooting compilation behaviours in mathgl.
>
> https://groups.google.com/forum/?_escaped_fragment_=topic/mathgl/cl4uYygPmOU#!topic/mathgl/cl4uYygPmOU

C++11, for some unknown reason, decided to hijack the C header complex.h 
and make it equivalent to the C++ header complex. The fact that you are 
still getting _Complex_I defined is already a gcc extension, as is 
providing _Complex in C++.

The C++ standard introduced User Defined Literals, which prevents the 
compiler from recognizing extra suffixes like iF in standard mode (why are 
so many people using c++11 and not gnu++11?).

Our support for complex.h in C++11 in gcc is kind of best-effort. In this 
case, I can think of a couple ways we could improve this

* _Complex_I is defined as (__extension__ 1.0iF). Maybe __extension__ 
could imply -fext-numeric-literals?

* glibc could define _Complex_I some other way, or libstdc++ could 
redefine it to some other safer form (for some reason __builtin_complex is 
currently C-only).

-- 
Marc Glisse