Mail Archives: djgpp-workers/2001/02/12/03:20:37
On Sat, 10 Feb 2001, Stephen Silver wrote:
> > I understand that if we use these wrappers, all the non-standard
> > functions are not in the std namespace, right?
>
> That's right. They are also not visible in the global namespace
> (even using .h headers) which is probably worse from the point of view
> of breaking existing code.
Yes, it's worse.
> A using directive ('using namespace _C_legacy') in namespace std might
> suffice to make the non-standard symbols visible in namespace std,
> but it's not possible to do the same in the global namespace, because
> of all the ambiguities it would cause if the user does the usual
> 'using namespace std'.
I don't feel I know enough about these issues to discuss them
intelligently. Would someone who knows C++ please join the discussion?
One thing we need to decide is in what namespace(s) do we want the
non-standard C library functions to be available to C++ programs. Are
there any guidelines about this in the C++ standard? Is it reasonable
to have them only in the global namespace? What do other implementations
do about this?
Once this is decided, we should see how best to implement this in our
system headers.
I'm not sure we should continue committing changes to the headers before
we make those decisions, because that might mean waste of Stephen's time
and efforts, in case those changes are incompatible with libstdc++ v3.
(I assume that libstdc++ v3 will be released before DJGPP 2.04; if that's
not true, we could ignore libstdc++ v3 for now.)
> namespace std {
> using _C_legacy::foo;
> using _C_legacy::baz;
> }
> using _C_legacy::foo;
> using _C_legacy::baz;
>
> namespace _C_legacy {
> extern "C" {
> #endif /* _IN_C_LEGACY_ */
>
> Unfortunately, this brings the non-standard symbols into the
> global namespace even if the <c*> form of the header is used.
Why is this unfortunate? Is this verboten by the C++ standard?
> It also means that the DJGPP headers would depend quite heavily
> on the way the libstdc++ headers work, which may change from one
> version to the next.
This became a major issue with the current attitude of the GCC
developers, not only wrt C++ headers. However, I don't see how can we do
anything to avoid this danger, given that the GCC maintainers don't give
a damn about our (or anyone else's) concerns.
> Another problem with these libstdc++ wrappers is that wchar.h,
> cwchar, wctype.h and cwctype will not compile, as they rely on
> all the standard prototypes that DJGPP doesn't have.
That might mean we need trivial implementations of the missing functions
anyway.
- Raw text -