Re: [boost] wave lexed_tokens sample gives an unexpected answer

From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2008-01-16 22:10:09

Leo, 

> >> I built the Wave preprocessing lib out of CVS head today using GCC 
> >> 4.2.1 on Linux x86 box (openSUSE 10.3).  I then built the 
> >> lexed_tokens sample
> >> and ran it on the attached header file.   The unexpected 
> >> answer was how
> >> the 'defined' keyword was treated.  I expected it to treat it as 
> >> T_DEFINED, but it seems to return T_IDENTIFIER as shown by this 
> >> output
> >> fragment:
> >>
> >> ...
> >> PP_IF            (#370) at foo.h (  4/ 1): >#if<
> >> SPACE            (#393) at foo.h (  4/ 4): > <
> >> IDENTIFIER       (#381) at foo.h (  4/ 5): >defined<
> >> SPACE            (#393) at foo.h (  4/12): > <
> >> IDENTIFIER       (#381) at foo.h (  4/13): >BAR<
> >> NEWLINE          (#395) at foo.h (  4/16): >\n<
> >> ...
> > 
> > That's (at least a documentaion) bug. The token T_DEFINED 
> get's never 
> > generated and should be removed from the implementation. 
> 'defined' has 
> > a special meaning to the preprocessor only and _is_ a 
> identifier for 
> > the compiler (it's not a keyword). So the bottomline is that the 
> > lexed_tokens example behaves correctly, but I need to remove the 
> > T_DEFINED token-id from the implementation to avoid further 
> confusion.
> 
> OK.  FYI, *C, A Reference Manual* calls 'defined' an operator 
> in the context of #if and #elif.

Yes you're right. That's exactly what I meant with 'has a special meaning
for the pp only'. Wave doesn't return preprocessor specific tokens to the
caller, so 'defined' has to be handled as a normal identifier.

Regards Hartmut