Farid Zaripov wrote:
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED]
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
