Re: Merge cpplib and front end hashtables, part 1

[Daniel Berlin <dan at cgsoftware dot com>]

Neil Booth <neil@daikokuya.demon.co.uk> writes:

> Daniel Berlin wrote:-
> 
> > At the point we go to do the macro expansion, we have already
> > converted the expression into a bunch of opcodes that get evaluated by
> > gdb in a stack machine.  The parser has done it's work, and thus, we
> > don't have a parser to hand it back to.  The language dependent code
> > is done, in other words.
> 
> But what if the macro contains unmatched parentheses or operators or
> other nasties?  Then you're screwed, no?

Yup.
But it wouldn't have compiled, right?

Remember, we get the macros from the *debug info*.
If we compiled all the way through, ....
> 
> > Because we have no parser to hand it back to, with context and all, at
> > this point. 
> 
> > In other words, macro expansion ain't done in the parser, it's called
> > by the evaluator.  It would be a serious hunk of work to move it back
> > into the parser, and then make the parser use cpplib internally.
> > 
> > It would be less work to write a good macro expander then it would to do
> > the above.
> 
> But I think making the expression parser use cpplib is the only
> correct solution if you want to handle macros properly.  Anything else
> is half-baked IMO.


I never claimed it wasn't.
But we don't need anywhere near the full power of CPPLIB, and
rewriting most of the expression parser just to do that, doesn't seem
to be worth it.

> 
> Neil.

-- 
"My girlfriend does her nails with white-out.  When she's asleep,
I go over there and write misspelled words on them.
"-Steven Wright