delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/02/12/03:20:37

Date: Mon, 12 Feb 2001 09:21:19 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Stephen Silver <djgpp AT argentum DOT freeserve DOT co DOT uk>
cc: DJGPP Workers <djgpp-workers AT delorie DOT com>
Subject: Re: namespace std and libstdc++ V3
In-Reply-To: <000201c0939e$1b15c020$0560893e@oemcomputer>
Message-ID: <Pine.SUN.3.91.1010212090940.12969B-100000@is>
MIME-Version: 1.0
Note-from-DJ: This may be spam
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019