Sorry, maybe my  representation is not quite clear.
I mean that I didn't define ACE_HAS_NONSTATIC_OBJECT_MANAGER at all, so the 
preprocesser should not process "#elif (ACE_HAS_NONSTATIC_OBJECT_MANAGER == 
0)", the following simple cpp can reproduce the problem.

Test.cpp
==========
#if !defined (ACE_HAS_NONSTATIC_OBJECT_MANAGER)
# define ACE_HAS_NONSTATIC_OBJECT_MANAGER
#elif (ACE_HAS_NONSTATIC_OBJECT_MANAGER == 0)
# undef ACE_HAS_NONSTATIC_OBJECT_MANAGER
#endif /* ACE_HAS_NONSTATIC_OBJECT_MANAGER */

int main(int argc, char *argv[])
{
 return 0;
}
==========

the compile command is:
gcc -Wall -o "Test.exe" "Test.cpp" -lstdc++ -s

and the error message is:
Test.cpp:3:41: error: operator '==' has no left operand


----- Original Message ----- 
From: "John Graham" <johngavingra...@googlemail.com>
To: <gcc@gcc.gnu.org>
Sent: Friday, October 23, 2009 10:03 PM
Subject: Re: Why does GCC Preprocessor NOT support such macro?


> 2009/10/23 Zhang Lin <zhanglin0...@163.com>:
> > Hello,
> > I have encountered an issue when building ACE with MinGW and GCC 4.4.1
> > The following macro was not accepted by the preprocessor and it reported 
> > such an error: "error: operator '==' has no left operand".
> >
> > #if !defined (ACE_HAS_NONSTATIC_OBJECT_MANAGER)
> > # define ACE_HAS_NONSTATIC_OBJECT_MANAGER
> > #elif (ACE_HAS_NONSTATIC_OBJECT_MANAGER == 0)
> > # undef ACE_HAS_NONSTATIC_OBJECT_MANAGER
> > #endif /* ACE_HAS_NONSTATIC_OBJECT_MANAGER */
> >
> > As I think, since ACE_HAS_NONSTATIC_OBJECT_MANAGER isn't defined, the #elif 
> > branch should not be processed.
> > This macro is accepted by VC7.1 and Sun Studio 12.
> >
> > Thanks.
> >
> > Best Regards,
> > Lin Zhang
> > 2009-10-23
> 
> You'll get this error if ACE_HAS_NONSTATIC_OBJECT_MANAGER is defined,
> but has a null value - i.e. if somewhere before it was:
> 
> #define ACE_HAS_NONSTATIC_OBJECT_MANAGER
> 
> and not:
> 
> #define ACE_HAS_NONSTATIC_OBJECT_MANAGER 1
> 
> (for example)
> 
> I'm not sure if there's a way to test for a macro being null, but if
> you change your previous declarations to defining it so something
> instead of nothing, everything should be dandy.
> 
> John G
> 

Reply via email to