Boost logo

Boost :

Subject: Re: [boost] Scalpel: a Spirit&Wave-powered C++ source code analysis library
From: Dave Abrahams (dave_at_[hidden])
Date: 2010-09-07 07:04:51

On Sun, Sep 5, 2010 at 12:35 PM, Doug Gregor <doug.gregor_at_[hidden]> wrote:
> On Fri, Sep 3, 2010 at 3:57 PM, Dave Abrahams <dave_at_[hidden]> wrote:
> > On Fri, Sep 3, 2010 at 6:22 PM, Florian Goujeon
> > <florian.goujeon_at_[hidden]> wrote:
> >> All competition is stimulating. It's beneficial for everyone. All
> >> competitors are different from each other and aim to bring a surplus
> >> value. As I said, Scalpel brings high homogeneity with Boost. It has
> >> its own unique design and I also plan to endow it with round-trip
> >> engineering capabilities.
> >
> >
> > One area that scalpel could conceivably find a niche, depending on how
> > you do it, would be in analyzing source code without seeing the full
> > translation unit (as you might for syntax-coloring purposes). Since
> > CLANG is really built to be a compiler, I don't think it can do that.
> Clang does syntax coloring [*], although it does so with knowledge of
> the full translation unit.

And you know I know that ;-)

> > Of course I realize you can't always get a correct analysis if you
> > don't see the whole TU, but especially if you're willing to do
> > nondeterministic parsing/backtracking, you could very easily do a
> > really good job.
> Perhaps, although I completely disagree with the "very easily" bit.
> C++ is a ridiculously ambiguous language.

Perhaps I overstated the case a *wee little* bit ;-)

> Note that a compiler could implement these same techniques along its
> recovery path to both improve diagnostics and improve support for
> syntax coloring.

Now it's my turn to be a little skeptical. I can't imagine a compiler would
ever try to do error recovery by throwing out all the information from
#include files you had already processed.

Dave Abrahams
BoostPro Computing

Boost list run by bdawes at, gregod at, cpdaniel at, john at