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

["glisse at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot 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.