Message-ID: <001e01c06627$9c95e200$9508893e@oemcomputer>
From: "Stephen Silver" <djgpp AT argentum DOT freeserve DOT co DOT uk>
To: <djgpp-workers AT delorie DOT com>
Subject: Re: ctype.h in C++
Date: Thu, 14 Dec 2000 23:43:05 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:

>> >Then why doesn't the C++ compiler disable the macros in its <ctype>
>> >(or is it <cctype>?) header?
>> 
>> At the moment, the <cctype> supplied with DJGPP just #includes <ctype.h>.
>
><cctype> is not part of the DJGPP project, it is part of the GCC port.  I 
>wonder how come GCC maintainers didn't pay attention to this issue.

Probably because fixing <cctype> is only a half-solution, since it
doesn't fix <ctype.h>.  On the other hand, if <ctype.h> does it right,
then <cctype> doesn't need fixing.

>I wonder what happens with other C libraries.  Does glibc, for instance, 
>define inline versions depending on __cplusplus?

I downloaded glibc 2.1.3 to check this.  Only tolower() and toupper() are
ever defined as inline functions.  (But this is done even in C.  They use
__inline instead of inline, so that it works even when the -ansi switch
is used.  Perhaps this would be the solution for DJGPP.  Or is there some
advantage to macros in C?)  The other functions seem to always be defined
as macros, although this can be turned off by defining __NO_CTYPE.

I also looked at Borland C++ 5.5.1.  They use neither macros nor inline
functions.  (There are macros in there, but they aren't compiled in
either C or C++.)

>> Disabling the macros in <cctype> would cause the non-inline versions
>> of these functions to be used, so it's not an ideal solution.
>
>You don't need to disable macros by #undef.  You could provide inline 
>versions in <cctype>, for example.

True.  So this would fix <cctype>, but <ctype.h> still wouldn't work
properly.

Another problem that the macros cause has occurred to me: programs
that attempt to overload any of the ctype functions will fail to
compile.


There is another, more general, problem with the DJGPP header files
in C++ which doesn't matter at the moment, but will once the GCC C++
library does things properly: they don't deal with namespace std.
What is supposed to happen is that the <c*> headers define their stuff
in namespace std (except for macros, which are always global).  Then
the <*.h> headers do something equivalent to this (taking <ctype.h> as
an example):

#include <cctype>
using std::isalnum;
using std::isalpha;
using std::iscntrl;
using std::isdigit;
using std::isgraph;
using std::islower;
using std::isprint;
using std::ispunct;
using std::isspace;
using std::isupper;
using std::isxdigit;
using std::tolower;
using std::toupper;

I've searched the archives of this list, but there doesn't seem to
have been any discussion of how this is going to be done in DJGPP.

Stephen