Re: Some (small) c++ compilation profiling data (oprofile)

[Zack Weinberg <zack at codesourcery dot com>]

On Tue, May 21, 2002 at 07:36:47AM +0100, Neil Booth wrote:
> 
> While we're on the subject, the current method we have interfacing
> cpplib / C++ is a dog.  There are 2 problems I see:
> 
> 1) Tokens from macro expansion don't have the right line / col info.
>    This can be solved 2 ways: a) we copy tokens during macro expansion
>    in cpplib, and when it's finished go back and correct the line / col
>    info of the remaining tokens to the position of the invoking identifier.

But that's *not* the correct line/col info.  We should be reporting
tokens from macro expansion as being located where the macro
definition was.  The only reason we don't do that now - more
accurately, the only reason why the front end ignores that information -
is because the front end wasn't/isn't prepared to handle it.  I vote
we rip out the code that smashes the location information and fix
whatever breaks.

> 2) The front end has a lot of infrastructure to go back and forth
>    in the token stream.  To do this it has copied a lot of tokens I
>    think.  It would be nice if it just had to maintain a couple of
>    pointers or offsets into an array.

Referring to the C++ front end here, right?  cp/spew.c, or the (much
less disgusting) stuff in the new parser?  I don't see why we need to
worry about token locations in order to let the front end say "hang
onto these, I'm still using them..."

Come to think of it, this is exactly the sort of problem that was
resolved in the compiler proper by garbage collection.  Maybe we
should have token allocation indirect through a callback, with a
library-provided default that uses the pools, so that when it's being
used as part of GCC we can just garbage-collect them all and not worry
about it.

> I also would like to introduce a CPP_WHITESPACE token when doing
> CPP output.  That would allow the removal of the CPP_PADDING
> nastiness, and handle the CPP_COMMENT stuff for -C and -CC more
> elegantly.  It would also mean ISO CPP can retain the form of
> whitespace in the input file (as has been often requested, and
> is a major reason people still want tradcpp).

No objection here.  It would mean marginally more complexity in token
paste but that's not a huge problem.

> FWIW I think cpplib would benefit from lexing tokens a logical line
> at a time.

I tried that once in some experimental code... never got done with it,
but the principle seemed sound.

zw