[Bug libstdc++/59087] New: including complex.h in C++11/1y mode should not include C's complex.h

[Bug libstdc++/59087] New: including complex.h in C++11/1y mode should not include C's complex.h

[kikairoya at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087

            Bug ID: 59087
           Summary: including complex.h in C++11/1y mode should not
                    include C's complex.h
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kikairoya at gmail dot com

working draft N3691 says:

 26.4.10 Header <ccomplex>
  The header behaves as if it simply includes the header <complex>.

 D.5 C standard library headers
  Every C header, each of which has a *name* of the form *name.h*, behaves as
  if each name placed in the standard library namespace by the corresponding
  *cname* header is placed within the global namespace scope.


so, including <complex.h> should behaves as same as including <complex>
except namespace scope, but libstdc++'s one includes system's
<complex.h> unnecessarily.

[Bug libstdc++/59087] including complex.h in C++11/1y mode should not include C's complex.h

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
That's an extension, it is done on purpose for compatibility with C code. IMHO
the standard's decision to replace C's complex.h with something completely
unrelated was nonsense.

Did that cause real problems for you?

[Bug libstdc++/59087] including complex.h in C++11/1y mode should not include C's complex.h

[kikairoya at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087

--- Comment #2 from Tomohiro Kashiwada <kikairoya at gmail dot com> ---
C's <complex.h> provides a macro named 'I' and this breaks existing codes.

ext/pod_char_traits.h
gcc4.8.2) http://melpon.org/wandbox/permlink/qb87YqrI7I4BAQRw
gcc4.7.3) http://melpon.org/wandbox/permlink/ighn7hGeL2tFXj16

boost/iterator/iterator_facade.hpp
gcc4.8.2) http://melpon.org/wandbox/permlink/VERBb6mK69nva2ML
gcc4.7.3) http://melpon.org/wandbox/permlink/ujalJUbClOd9FjFg


and, anyway, C's complex doesn't work on C++11 mode.
gcc4.8.2 c++11) http://melpon.org/wandbox/permlink/CnsddYRxUohlCGF1
gcc4.8.2 c++03) http://melpon.org/wandbox/permlink/QrBInjH6rlRs2Jdl


Or, if C++'s <complex.h> includes C's one, I think also <ccomplex> should
behave so (I think 26.4.10 is incomprehensible.)

[Bug libstdc++/59087] Issues including complex.h in C++11/1y mode because of C's complex.h

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-11-12
                 CC|                            |glisse at gcc dot gnu.org
            Summary|including complex.h in      |Issues including complex.h
                   |C++11/1y mode should not    |in C++11/1y mode because of
                   |include C's complex.h       |C's complex.h
     Ever confirmed|0                           |1

--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> ---
Thanks, there are several issues.

> C's <complex.h> provides a macro named 'I' and this breaks existing codes.

Well, just include <complex> if that's what you need, and if you include
<complex.h>, expect its natural content (except possibly for the macro
"complex").

> ext/pod_char_traits.h

This needs uglifying indeed.

> boost/iterator/iterator_facade.hpp

They should use a less risky name.

> and, anyway, C's complex doesn't work on C++11 mode.
> gcc4.8.2 c++11) http://melpon.org/wandbox/permlink/CnsddYRxUohlCGF1

Ah, user-defined literals... I'll let the experts comment.

> gcc4.8.2 c++03) http://melpon.org/wandbox/permlink/QrBInjH6rlRs2Jdl
> 
> 
> Or, if C++'s <complex.h> includes C's one, I think also <ccomplex> should
> behave so (I think 26.4.10 is incomprehensible.)

Maybe (it mostly shouldn't have existed in the first place), indeed. Might be
as simple as making it include complex.h instead of complex.

[Bug libstdc++/59087] Issues including complex.h in C++11/1y mode because of C's complex.h

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087

--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> ---
Author: glisse
Date: Wed Nov 13 15:47:04 2013
New Revision: 204750

URL: http://gcc.gnu.org/viewcvs?rev=204750&root=gcc&view=rev
Log:
2013-11-13  Marc Glisse  <marc.glisse@inria.fr>

    PR libstdc++/59087
    * include/ext/pod_char_traits.h: Uglify V, I and S.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/include/ext/pod_char_traits.h

[Bug libstdc++/59087] Issues including complex.h in C++11/1y mode because of C's complex.h

[3dw4rd at verizon dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087

Ed Smith-Rowland <3dw4rd at verizon dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |3dw4rd at verizon dot net

--- Comment #5 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
complex.h
---------
...
#define _Complex_I    (__extension__ 1.0iF)
...

So yes, this looks to C++11 etc. like a user-defined literal suffix.  Except
that the user-defined literal suffix interpretation is supposed to let standard
suffixes and implementation-defined suffixes get first crack.  Maybe there's a
hole in that logic?

Now figure out what __extension__ does and see if it can be used somehow to
intercept the usual suffix processing?  That just suppresses -pedantic.

Just thinking aloud.  I'm on it.

[Bug libstdc++/59087] Issues including complex.h in C++11/1y mode because of C's complex.h

[3dw4rd at verizon dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087

--- Comment #6 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
Strangely, head works: http://melpon.org/wandbox/permlink/CnsddYRxUohlCGF1
Although mine still gets the error.

I did something that might have helped for 4.9.  If I can prove that the fix
worked I might try to get it in 4.8.

Still investigating.

[Bug libstdc++/59087] Issues including complex.h in C++11/1y mode because of C's complex.h

[3dw4rd at verizon dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087

--- Comment #7 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
OK, it took me a while to remember this (even though I put it in myself).

By default, g++ -std=c++11/1y intercepts numeric suffixes for C++11
user-defined literals.

By default g++ -std=gnu++11/1y allow complex and fixed-point literals suffixes
to be interpreted by the implementation - Allowing iF suffix for example to be
_Complex.

This is why http://melpon.org/wandbox/permlink/CnsddYRxUohlCGF1 "worked" and my
tree (where I used -std=c++1*) "didn't work".

See http://gcc.gnu.org/gcc-4.8/changes.html.

Using g++ -std=c++11 -fext-numeric-literals allows your code.
Using g++ -std=gnu++11 -fno-numeric-literals allows iF to be searched for
user-defined literal (there isn't one so error).

g++ is working as intended.

[Bug libstdc++/59087] Issues including complex.h in C++11/1y mode because of C's complex.h

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087

--- Comment #8 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Ed Smith-Rowland from comment #7)
> g++ is working as intended.

Thanks a lot for the investigation. Do you think the error message: "unable to
find numeric literal operator" could additionally point out that
-fext-numeric-literals or -std=gnu++11 would allow the code to work, for
suffixes for which that is the case? That would have saved you a lot of
investigation time ;-)

[Bug libstdc++/59087] Issues including complex.h in C++11/1y mode because of C's complex.h

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087

--- Comment #9 from Marc Glisse <glisse at gcc dot gnu.org> ---
Author: glisse
Date: Thu Jan  2 22:45:56 2014
New Revision: 206304

URL: http://gcc.gnu.org/viewcvs?rev=206304&root=gcc&view=rev
Log:
2014-01-02  Marc Glisse  <marc.glisse@inria.fr>

    PR c++/59087
gcc/cp/
    * parser.c (cp_parser_userdef_numeric_literal): Mention
    -fext-numeric-literals in the message.


Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/parser.c

[Bug libstdc++/59087] Issues including complex.h in C++11/1y mode because of C's complex.h

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087

--- Comment #10 from Marc Glisse <glisse at gcc dot gnu.org> ---
It seems to me that this is ok now.

* If you want <complex>, include that, not <complex.h>
* <complex.h> contains the C stuff for compatibility with C code, C code
doesn't include <ccomplex>, so <ccomplex> doesn't need that stuff (it wouldn't
make sense to move those non-standard functions to namespace std)
* The error message now advertises the option that lets complex suffixes
compile
* The files using unsafe identifiers (conflicts with macros) now use uglified
names instead

I am not planning to do a backport myself of those 2 trivial patches, but if
anyone wants to, feel free to do it.

We may have to revisit some decisions when the standard (C++14? C++17?) will
provide UDLs that conflict with the complex suffixes.

[Bug libstdc++/59087] Issues including complex.h in C++11/1y mode because of C's complex.h

[vlovich at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087

Vitali <vlovich at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vlovich at gmail dot com

--- Comment #11 from Vitali <vlovich at gmail dot com> ---
I ran into this problem as I included lapacke.h & indirectly, via including <
boost/exception/all.hpp> picked up boost's iterator_facade.hpp.

All of this is out of my control to resolve.  lapacke correctly includes
complex.h (since it is C code).  iterator_facade correctly uses I as the name
for a template   argument (just as easily could have been used as a variable
name).  The combination results in code that doesn't work.

I had to #undef I.

I'm not sure if that's a GCC bug as opposed to something the standard needs to
resolve.

[Bug libstdc++/59087] Issues including complex.h in C++11/1y mode because of C's complex.h

[vlovich at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087

--- Comment #12 from Vitali <vlovich at gmail dot com> ---
Actually, http://en.cppreference.com/w/cpp/header seems to indicate that when
compiling as C++, complex.h should be equal to including ccomplex in a global
namespace.  It seems like the inclusion of C99 complex.h is a GNU extension &
should only be done if GNU extensions are enabled.

[Bug libstdc++/59087] Issues including complex.h in C++11/1y mode because of C's complex.h

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087

--- Comment #13 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Vitali from comment #12)
> It seems like the inclusion of C99 complex.h is a GNU
> extension & should only be done if GNU extensions are enabled.

That would be a possibility, but do you think your lapack header will
appreciate it if the complex.h it includes suddenly doesn't contain what it
expects at all? It will break even worse.

C++ code has 0 reason to include complex.h, only C code does, and thus it makes
sense if it contains what C says. We do #undef complex but only because we are
forced to do it.

As for boost, reusing the name of a standard C macro is not the best idea for
interoperability. If you report it to them, I hope they would be fine with
replacing all 'I' with 'It'.

[Bug libstdc++/59087] Issues including complex.h in C++11/1y mode because of C's complex.h

[vlovich at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087

--- Comment #14 from Vitali <vlovich at gmail dot com> ---
Actually, found a better workaround for lapacke.

Adding
#include <ccomplex>
#define lapack_complex_float std::complex<float>
#define lapack_complex_double std::complex<double>

before I include <lapacke.h> causes lapacke.h to avoid including complex.h &
this is the officially supported mechanism for lapacke.  It's strange that they
don't just do that automatically.

[Bug libstdc++/59087] Issues including complex.h in C++11/1y mode because of C's complex.h

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087

--- Comment #15 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Vitali from comment #14)
> Actually, found a better workaround for lapacke.

Good.

> #include <ccomplex>

Please save one character and include <complex> instead.

[Bug libstdc++/59087] Issues including complex.h in C++11/1y mode because of C's complex.h

[vlovich at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087

--- Comment #16 from Vitali <vlovich at gmail dot com> ---
Yup - I caught that on a self code-review.