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-04 13:45:48


On Fri, Sep 3, 2010 at 9:50 PM, OvermindDL1 <overminddl1_at_[hidden]> wrote:
>> 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.
>>
>> 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.
>
> I do not think it can do that either, without seeing the whole
> translation unit then you are going to see a *LOT* of undefined
> symbols, no clue if they are a type, function, etc... etc....

By exploring all possible valid parses you can usually deduce the role
of a symbol from all the contexts in which it is used. Humans do it
all the time.

> It is
> impossible to have any kind of decent syntax-coloring without that
> (see the difference between the fully parsed and complete Visual
> Assist VS add-in compared to emacs/vi/VS/etc...), and refactoring
> becomes all but impossible.

emacs, vi, and VS only make local decisions about each symbol. You
ought to be able to do much better by taking in an entire file and
throwing out the possibilities that result in invalid parses. I know
this approach works for natural language, which is full of the same
kinds of ambiguities (homonyms/homophones). Actually the NLP case is
much harder because a word doesn't have to be used consistently across
sentences.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk