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.
