Using gcc 4.9
I found that types generated with type literal for complex numbers are not the same as when created by conventional means, i.e.:
t
The behaviour of the program depends on the language standard mode of gcc:
There is a gcc extension for a built-in literal suffix i that produces C99 complex numbers. Those are distinct built-in types like _Complex double
, as opposed to the "user-defined" class (template specialization) std::complex<double>
used in C++.
In C++14, C++ now has a user-defined literal suffix i
for complex numbers. That is, a function complex<double> operator"" i(long double)
within the std::literals::complex_literals
inline namespace.
Those two literal suffixes are competing:
In C++11 mode, only the built-in extension is possible, but it is an extension. Hence, gcc only allows it in -std=gnu++11
mode and even warns you about it. Strangely enough, clang allows it even in -std=c++11
mode.
In strict C++14 mode (-std=c++14
or -std=c++1y
), the built-in extension must be disabled to remove ambiguity (as far as I can tell), hence both gcc and clang selecting the user-defined literal suffix.
In the gnu-extension-C++14 mode -std=gnu++14
, gcc chooses the built-in suffix (for backwards-compatibility?), whereas clang chooses the user-defined suffix. This looks strange, and I'd suggest looking for or filing bug reports here.
Depending on which literal suffix is chosen, you either get the built-in type _Complex double
or some std::complex<double>
.