Regarding the second comment, squash aims to be that bridge between the ast and the source-code. It’s tricky, but if I succeed, it could make C++ a lot easier to refactor.

On the other hand, reading preprocessed code and then going back and blindly patching the source seems error-prone from the start.

I feel like I’ve seen this problem before. When I hack XML, I want to use a high-level API, but I also want round-tripping. The high-level libraries always seem to throw away the low-level information only needed for round-tripping, like whitespace around attributes. (Some parsers go further, irreversibly expanding entity references, throwing away comments, etc. Your CPP problem is similar to the problem of handling entity references in XML.)

What you really need is a library that keeps the (low-level) raw source code–and can fix it up for whatever (high-level) AST changes you make.

So, are you planning to write an Elkhound-based CPP for Elsa? The word “integrate” makes it sound like you’re going to integrate an existing CPP, and I don’t understand how that will solve your problem.

I don’t mean to encourage you to do the “easy” thing, but it’s pretty easy to auto-detect this bug when it happens, right? Just compare the .i line you *think* you’re modifying against the .cpp line you’re actually modifying. So… How often does this come up? How often would it come up if you special-cased nsnull? Can’t your tool easily detect this kind of bug and spit out error markers which a human can then review?

I don’t mean to pester you, just very interested in this problem.