Date: Mon, 12 Feb 2001 09:21:19 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Stephen Silver cc: DJGPP Workers Subject: Re: namespace std and libstdc++ V3 In-Reply-To: <000201c0939e$1b15c020$0560893e@oemcomputer> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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 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.