[cfe-dev] Expression Templates for AST matchers

Richard legalize at xmission.com
Thu Apr 9 10:15:02 PDT 2015


In article <CAOsfVvmev4Y7Q=Wr=8RJQFs49S94J0OE97-iJyaWRZVvCD60Jg at mail.gmail.com>,
    Manuel Klimek <klimek at google.com> writes:

> We actually went from a more expression templatey to a less expression
> templatey design.

Interesting!  So far, I feel like what I've been trying to match is
completely expressable at compile-time and deferring things to runtime
is making things slow.  This seems to be consistent with the findings
of the imlpementors of OCLint and why they make the statement I quoted
earlier.

> On Tue, Apr 7, 2015, 3:31 PM Sean Silva <chisophugis at gmail.com> wrote:
> 
> > Although I'm mostly an armchair spectator right now w.r.t. clang tooling
> > stuff, I think that use cases like clang-query and in general the dynamic
> > AST matchers suggests that expression templates aren't a very good solution
> > because they will require reimplementing things from scratch for the
> > "dynamic" case.

When I look at a library like Boost.Spirit that heavily uses
expression templates I don't see how I'm losing the dynamic case at
all.  Maybe I'm misunderstanding what you're saying.

> Sam has worked on making clang tidy use cases faster. I
> expect in the end the right thing is to do less duplicate work which I
> think we will be able to do with modules.

While modules are nice, I don't think it's reasonable to expect that
modules will be deployed over a significant chunk of the world's C++
code anytime soon.  So it doesn't seem practical to say "modules will
fix this".

> > Regardless, I don't think that the primary bottleneck is not doing enough
> > at compile time (of the matchers). Rather we aren't effectively indexing
> > the underlying data set we are trying to query (right now, we're more like
> > grep and less like google). [...] (a
> > good example is using a trigram index to prune the search space for regexp
> > matching http://swtch.com/~rsc/regexp/regexp4.html).
> >
> > * "multiple" here also scales numerically with the number of TU's. An
> > index can avoid visiting certain TU's at all in many cases.

Thanks for that link Sean, that was an interesting read.  I couldn't
find it "live" on the web, but was able to get it via the wayback
machine on archive.org.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
         The Terminals Wiki <http://terminals.classiccmp.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>



More information about the cfe-dev mailing list