Patch to improve cpplib's C++ support

Jason Merrill
Sat Jul 10 18:02:00 GMT 1999

>>>>> Zack Weinberg <> writes:

 > I have no problem with the addition of .*, ->*, <?, >?.  (I thought <? and
 > >? were only in C++ though.)

Looks like you're right.  I'll make that dependent on cplusplus, too.

 > It is not clear to me what cpp_unget and ->redirected_input_p do, and they
 > fall in areas where I was planning to change the API.  What exactly
 > does the C++ front end need here?

C++ basically requires that parsing of method bodies be deferred until the
class definition is complete.  g++ currently has an internal mechanism for
handling this, but that defeats the tokenization that cpplib does.  It
makes more sense to use the cpplib buffer support directly.

cpp_unget is necessary because parsing sometimes looks ahead at the next
token to determine how to proceed.  Normally, this is fine, but when we're
switching to a different input stream, we need to put the lookahead token
back into the buffer where we found it so that it will be there when we
return to reading from that file.

Actually, it occurs to me that it's the lexer, not the parser, that's
looking ahead in this case, and that I can probably avoid that by taking
better advantage of our pre-knowledge of token lengths.  I'll give that a

redirected_input_p tells cpplib that this is an artificial input stream,
and does not flow naturally back into the previous input like leaving an
#include file.  It is up to the C++ frontend to pop the input buffer.  We
do it like this so we can insert other tokens between the methods, though
it may be possible to make things work without this support.


More information about the Gcc-patches mailing list