stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: svn commit: r597425 - in /incubator/stdcxx/branches/4.2.x: include/ansi/cwchar tests/strings/21.cwchar.cpp
Date Fri, 30 Nov 2007 00:50:36 GMT
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com] 
>> Sent: Wednesday, November 28, 2007 7:00 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: svn commit: r597425 - in 
>> /incubator/stdcxx/branches/4.2.x: include/ansi/cwchar 
>> tests/strings/21.cwchar.cpp
>>
>> No, I mean when _RWSTD_STRICT_ANSI is not #defined but getwc 
>> and putwc are. Then we might end up with something like this:
>>
>>    #define getwc()   (stdin->__wide_char)
>>    ...
>>    using ::getwc;
>>
>> expanding to
>>
>>    using ::(stdin->__wide_char);
> 
>   Yes, potentially here might be a problems.

So maybe we need to rethink the original strategy of #undefining
the macros only when _RWSTD_STRICT_ANSI is #defined. Or is there
a way to prevent the expansion of the macros in the using
declarations?

Btw., it occurs to me that if they are defined as function macros
(i.e., #define getwc() as opposed to #define getwc, without the
parentheses), mentioning getwc w/o an argument list as is done
in using declarations will not cause them to be expanded. So
the problem only exists for object macros (i.e., those that
aren't defined with parentheses).

> 
>   BTW in ansi/cctype and ansi/cmath headers the masking macros
> are #undefined unconditionally.
> 
>  I think first we need to collect information how these macros are
> implemented
> on different platforms and then decide what should we do.

I suppose we should do that. But either way we decide we should be
consistent. So if there already are unconditional #undefs in several
other headers we might as well follow suit with cwchar (and wchar.h)
until we gather more information and decide to change all the other
headers to #undef all the other macros conditionally.

> 
>   In example the MSVC implements getwc() thus fgetwc() (the getwc macro
> is
> defined fo fgetwc and getwc() crt function just calls fgetwc()). So we
> can safely
> #undefine these macros on MSVC without functional changes or performance
> penalty (I suppose that in release the getwc() function should be
> implemented
> as "jmp _fgetwc").

Makes sense to me.

Martin

Mime
View raw message