Re: [boost] BOOST_NO_CTYPE_FUNCTIONS?

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2001-09-23 10:01:53

On Sunday, September 23, 2001, at 06:55  AM, John Maddock wrote:

>
>> When getting the regex library to compile under Mac OS X, I ran into a
>> problem with the BSD <ctype.h>. This file doesn't have the functions
>> required by the C standard for things like isspace(), just macros. I
> imagine
>> other older Unix platforms might have the same mistake.
>
> Ouch, that's against the requirements of the C, C++ and POSIX 
> standards...
>
>> Does it seem OK to add a macro to Boost.Config to indicate this 
>> problem?
> Is
>> the name BOOST_NO_CTYPE_FUNCTIONS ok? It's not 100% precise, because
> tolower
>> and toupper are still functions.
>
> OK, but it will involve major surgery - all those std:: prefixes to 
> isXXX
> will have to change, so will the section in boost/regex/config.hpp that
> undef's the macros to get at the C API's.  Are you completely sure that
> there are no real declarations?

There's a technique for converting macros into inlines that I came up 
with and used in the Metrowerks C++ lib to deal with this problem.  If 
someone wants to apply this technique in boost, I have no objections:

#ifdef isspace
        inline int __isspace_imp(int x) {return isspace(x);}
        #undef isspace
        inline int isspace(int x) {return __isspace_imp(x);}
#endif

If isspace is a macro, then create a helper inline that does nothing but 
call the isspace macro.  Then #undef isspace.  Finally create an isspace 
inline that calls the helper inline.

To combat conflicting with an existing isspace function in the C library 
one can make this inline extern "C++" and put it in a namespace if 
desired.

Use of this technique might reduce the required surgery a bit.  Beware 
that on Mac OS X (mach target) you run the risk of conflicting with the 
C++ lib which is already playing this game in <localeimp> which is 
included in all of the I/O related standard C++ headers.

-Howard