Mail Archives: djgpp-workers/2001/02/10/08:39:01
Eli Zaretskii wrote:
> > In order to allow my namespace std patches to work with the libstdc++ V3
> > wrappers, I propose the following changes.
>
> Is it possible first to outline what libstdc++ v3 does with its
> wrappers?
The <c*> headers work by #including the native <*.h> headers into a
namespace called _C_legacy like this:
namespace _C_legacy {
extern "C" {
# define _IN_C_LEGACY_
# undef __need_FILE
# pragma GCC system_header
# include_next <stdio.h>
}
They then import all the standard symbols into namespace std. There
are also shadow <*.h> headers that #include the corresponding <c*>
headers and lift the standard symbols into the global namespace.
All this works well from the point of view of standard compliance -
they even fix macros that should be functions and functions that should
be macros, and they add the overloaded functions to cmath and math.h,
etc. The big drawback is that most of the non-standard functions that
DJGPP provides end up only in namespace _C_legacy, so that they can't
be used without a _C_legacy:: qualifier (except in a few cases where
Koenig look-up comes to the rescue). This happens even if you use
the <*.h> headers rather than the <c*> ones.
> For example, does the installation of libstdc++ headers change the
> library's system headers in any way? Are we up against the invasive
> nature of GCC again?
>
> It is also not clear to me whether installing the libstdc++ headers
> automatically means that the system C headers are wrapped with its
> wrappers, even if the program includes stdio.h, not cstdio.
The headers that I've described above wrap all the standard C library
headers (plus a few non-standard ones), so that it's impossible to
#include the DJGPP ones directly. However, these wrappers are optional.
There are also two other sets of <c*> wrappers provided, neither
of which hides the DJGPP <*.h> headers. One of these sets does
more-or-less nothing (like the current ones), and should therefore work
with my patches. The other set provides a rough simulation of standard
compliance. This won't work with my namespace std patches, but is of
no interest anyway.
The change that I'm proposing would allow the first set of wrappers to
be used, which is good for people who want maximum standard compliance
and don't care about all the non-standard stuff being buried in
namespace _C_legacy.
Stephen
- Raw text -