[Bug libstdc++/51749] Including <algorithm> pollutes global namespace

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #20)
> (In reply to Jakub Jelinek from comment #19)
> > Has anyone checked recently what exactly we still need -D_GNU_SOURCE for in
> > the public headers (as opposed to just the libstdc++ code), as compared to
> > say _ISOC99_SOURCE for glibc, at least for C++11?
> 
> I haven't checked, it would be useful to do so.  There is some stuff used by
> the --enable-clocale=gnu code such as uselocale (which is now part of POSIX
> but not C99) but it might be possible to only require that from .cc files
> not in headers.

In __gnu_cxx namespace:
  extern "C" __typeof(uselocale) __uselocale;
and in std namespace:
  typedef __locale_t            __c_locale;

suggests that it really is looking for the uselocale function just to get the
prototype and declares the function itself, and we need an alternative to
__locale_t.  We can't include xlocale.h, because that would make locale_t
symbol visible, and can't typedef __locale_t, because that could clash with
<locale.h>
definition -D_GNU_SOURCE etc.
Thus it would need to be something like:
// Hackish forward declaration in global namespace.
struct __locale_struct;
and then just do:
  extern "C" __locale_struct *__uselocale (__locale_struct *);
in __gnu_cxx namespace and
  typedef __locale_struct *      __c_locale;
in std namespace.