* [Bug libstdc++/48891] std functions conflicts with C functions when building with c++0x support.
2011-05-05 21:50 [Bug libstdc++/48891] New: std functions conflicts with C functions when building with c++0x support alexis.menard at openbossa dot org
@ 2011-05-05 21:44 ` alexis.menard at openbossa dot org
2011-05-05 22:08 ` [Bug libstdc++/48891] std functions conflicts with C functions when building with c++0x support (and using namespace std) redi at gcc dot gnu.org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: alexis.menard at openbossa dot org @ 2011-05-05 21:44 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48891
--- Comment #1 from Alexis Menard <alexis.menard at openbossa dot org> 2011-05-05 21:35:55 UTC ---
glibc 2.13-5.
binutils 2.21-7
Archlinux.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/48891] std functions conflicts with C functions when building with c++0x support (and using namespace std)
2011-05-05 21:50 [Bug libstdc++/48891] New: std functions conflicts with C functions when building with c++0x support alexis.menard at openbossa dot org
2011-05-05 21:44 ` [Bug libstdc++/48891] " alexis.menard at openbossa dot org
@ 2011-05-05 22:08 ` redi at gcc dot gnu.org
2011-05-05 22:22 ` alexis.menard at openbossa dot org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2011-05-05 22:08 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48891
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-05-05 22:03:55 UTC ---
(In reply to comment #0)
>
> and build it with : g++ main.cpp -std=c++0x -std=gnu++0x -o test
There's no point specifying two -std options, only the last one takes effect.
> If I deactivate the c++0x support it works.
Because in C++98 there is no std::isnan, so you only get the version in the
global namespace from <math.h>
> The real issue is that the c++0x standard removes the prohibition on C++
> headers declaring C names in the global namespace. The problem here is that
> math.h is included therefore the declarations are in the global namespace.
I don't think that's the problem, because libstdc++ has always declared the
names in the global namespace even though it wasn't valid in C++03 - we haven't
changed that for C++0x (all that happened is the standard was relaxed to
reflect the reality of actual implementations)
> I'm not really sure how the compiler can solve that but this new "feature" of
> c++0x seems to be very annoying. I could solve it by not using namespace std
> but let say the project is huge, it will requires lot of modifications.
>
> Basically any time you use using namespace std, you may have conflicts with the
> underlaying C libraries, it's even more annoying with your own namespace
> because your functions can conflict with all the stuff in the global namespace
> put by C libraries and it's very common in a cpp file to use "using namespace
> foo;"
>
> Any suggestions on how I could "workaround" that?
Qualify isnan explicitly, by calling either ::isnan or std::isnan
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/48891] std functions conflicts with C functions when building with c++0x support (and using namespace std)
2011-05-05 21:50 [Bug libstdc++/48891] New: std functions conflicts with C functions when building with c++0x support alexis.menard at openbossa dot org
2011-05-05 21:44 ` [Bug libstdc++/48891] " alexis.menard at openbossa dot org
2011-05-05 22:08 ` [Bug libstdc++/48891] std functions conflicts with C functions when building with c++0x support (and using namespace std) redi at gcc dot gnu.org
@ 2011-05-05 22:22 ` alexis.menard at openbossa dot org
2011-05-05 22:47 ` paolo.carlini at oracle dot com
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: alexis.menard at openbossa dot org @ 2011-05-05 22:22 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48891
--- Comment #3 from Alexis Menard <alexis.menard at openbossa dot org> 2011-05-05 22:17:36 UTC ---
(In reply to comment #2)
> (In reply to comment #0)
> >
> > and build it with : g++ main.cpp -std=c++0x -std=gnu++0x -o test
>
> There's no point specifying two -std options, only the last one takes effect.
>
> > If I deactivate the c++0x support it works.
>
> Because in C++98 there is no std::isnan, so you only get the version in the
> global namespace from <math.h>
That explain.
>
> > The real issue is that the c++0x standard removes the prohibition on C++
> > headers declaring C names in the global namespace. The problem here is that
> > math.h is included therefore the declarations are in the global namespace.
>
> I don't think that's the problem, because libstdc++ has always declared the
> names in the global namespace even though it wasn't valid in C++03 - we haven't
> changed that for C++0x (all that happened is the standard was relaxed to
> reflect the reality of actual implementations)
>
Sorry for my ignorance.
>
> > I'm not really sure how the compiler can solve that but this new "feature" of
> > c++0x seems to be very annoying. I could solve it by not using namespace std
> > but let say the project is huge, it will requires lot of modifications.
> >
> > Basically any time you use using namespace std, you may have conflicts with the
> > underlaying C libraries, it's even more annoying with your own namespace
> > because your functions can conflict with all the stuff in the global namespace
> > put by C libraries and it's very common in a cpp file to use "using namespace
> > foo;"
> >
> > Any suggestions on how I could "workaround" that?
>
> Qualify isnan explicitly, by calling either ::isnan or std::isnan
Well that requires me to modify my entire project, namely WebKit :(. But the
more I'm stuck on that issue, the more it seems to be the only solution.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/48891] std functions conflicts with C functions when building with c++0x support (and using namespace std)
2011-05-05 21:50 [Bug libstdc++/48891] New: std functions conflicts with C functions when building with c++0x support alexis.menard at openbossa dot org
` (2 preceding siblings ...)
2011-05-05 22:22 ` alexis.menard at openbossa dot org
@ 2011-05-05 22:47 ` paolo.carlini at oracle dot com
2011-05-05 23:16 ` paolo.carlini at oracle dot com
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: paolo.carlini at oracle dot com @ 2011-05-05 22:47 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48891
--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-05 22:46:39 UTC ---
Just wanted to add that the real reason the issue is more subtle now in C++0x
mode than it used to be (and still is) in C++03 mode as an extension, is that
we now provide the functions in namespace std with the mandated return type,
that is bool, whereas in C++03 mode, as an extension, the return type is int,
like in C99. Frankly, *given* the usual, well known, limits of our way of
dealing with the underlying *.h C headers (included as implementation detail
anyway), I don't see any reasonably simple way of solving this family of
problems.
Actually, anyway, modulo a C++ front-end issue I filed some time ago, I think
the <cmath> header isn't *that* far from dispensing with including math.h, the
most important blocking issue being the constants FP_NAN, FP_INFINITE,
FP_NORMAL, FP_SUBNORMAL, FP_ZERO, which, the last time I asked, Joseph, if I
remember correctly, said are very tricky to obtain outside math.h...
Anyway, given the different return types in C++0x and C99, the problem would
resurface quite unavoidably with:
#include <cmath>
#include <math.h>
using namespace std;
of course, if we only fix <cmath> still without fully controlling math.h. Don't
hold your breath ;)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/48891] std functions conflicts with C functions when building with c++0x support (and using namespace std)
2011-05-05 21:50 [Bug libstdc++/48891] New: std functions conflicts with C functions when building with c++0x support alexis.menard at openbossa dot org
` (3 preceding siblings ...)
2011-05-05 22:47 ` paolo.carlini at oracle dot com
@ 2011-05-05 23:16 ` paolo.carlini at oracle dot com
2012-04-29 13:17 ` marc.glisse at normalesup dot org
2015-04-09 14:35 ` redi at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: paolo.carlini at oracle dot com @ 2011-05-05 23:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48891
Paolo Carlini <paolo.carlini at oracle dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #5 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-05-05 23:13:43 UTC ---
Jakub, wrt my Comment #4, would it make sense in your opinion to implement a
mechanism requiring cooperation between glibc & libstdc++ similar to the
__CORRECT_ISO_CPP_STRING_H_PROTO mechanism you implemented for memchr & co back
in 2009-01-30?
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/48891] std functions conflicts with C functions when building with c++0x support (and using namespace std)
2011-05-05 21:50 [Bug libstdc++/48891] New: std functions conflicts with C functions when building with c++0x support alexis.menard at openbossa dot org
` (4 preceding siblings ...)
2011-05-05 23:16 ` paolo.carlini at oracle dot com
@ 2012-04-29 13:17 ` marc.glisse at normalesup dot org
2015-04-09 14:35 ` redi at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: marc.glisse at normalesup dot org @ 2012-04-29 13:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48891
--- Comment #6 from Marc Glisse <marc.glisse at normalesup dot org> 2012-04-29 13:15:40 UTC ---
I don't think it matters that much whether the return type is int or bool,
compared to the inconvenience of having 2 functions that conflict.
The constexpr qualifier is nice, but not required by the standard, and not even
by gcc which recognizes that extern "C" int isnan(double) is a builtin (note
that it doesn't recognize it anymore if you change the return type to bool,
that should be fixed).
For the same reason (recognized as a builtin), there is no performance
advantage to having it inline.
So I think:
* glibc could change the return type of isnan to bool in C++ (there would be a
regression in that ::isnan wouldn't be constexpr and inline until g++ is taught
the right prototype)
* libstdc++ could import ::isnan in std::, assuming isnan exists. Maybe that
requires a configure test. Maybe that test would be rather fragile (depends on
feature macros). Maybe that's where this stops being a good idea :-(
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libstdc++/48891] std functions conflicts with C functions when building with c++0x support (and using namespace std)
2011-05-05 21:50 [Bug libstdc++/48891] New: std functions conflicts with C functions when building with c++0x support alexis.menard at openbossa dot org
` (5 preceding siblings ...)
2012-04-29 13:17 ` marc.glisse at normalesup dot org
@ 2015-04-09 14:35 ` redi at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2015-04-09 14:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48891
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-04-09
Ever confirmed|0 |1
Known to fail| |4.8.3, 4.9.2, 5.0
^ permalink raw reply [flat|nested] 8+ messages in thread