[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Introducing the PDOM
|
Hi Doug,
Here are some issues we ran into while developing a source-to-source
transformer for C/C++ that also included a persistence engine.
1. Host environment and preprocessor options (parser options) can change
the shape of (i.e. invalidate) the db. It is very difficult to produce a
valid db for a set of headers on one system and ship it off to be used
elsewhere on another, if you need to regenerate the translation unit
(TU) without changing the semantics. But you may not require the latter,
and if your db includes a model of the un-preprocessed source, you may
be OK.
2. Our attempt to incrementally update the db after a change in the
original source was not a complete success for two reasons:
- complexity of managing C++ templates (we addressed ~90% of these
issues, but we didn't have the resources to achieve 100%)
- in our db we merged the state of multiple TUs into a single model
-- although this was space effecient, I would advise against this. Stick
to a db that is organized by TU and provide indexes for cross-referencing.
3. Performance and scalability are always an issue for large projects.
Our tool is used for library-specific interprocedural (global)
optimization and instrumentation. All modules except the parser (EDG)
are written in Java. We pay a relatively high price (~2-3s per TU) in
transforming EDG-IL into our own model using JNI, even with PCH enabled.
But once imported, the code can be refactored, instrumented, etc. and
exported to a new set of TUs.
Cheers
Matthias
PS. Are any of you familiar with the D programming language? I would say
it's not ready for prime time, but it has the advantage of being close
to the machine (systems programming language), C-compatible, eliminates
the need for preprocessing, provides a module system, templates, etc.,
and would probably scale beautifully in an environment like eclipse. A
DDT could be a killer-app.
Doug Schaefer wrote:
Hi Sumit,
This is definitely something else to consider. I know some at IBM have
this requirement as well where the source files reside on a remote
machine. One option was to have the indexer run remotely. With the PDOM,
this should be possible and would provide functionality for all parser
based features (not just the index based ones). Since I'm using SQL for
queries, we should be able to easily handle that on the local side. We
would need to figure out how to package up the remote agent, though.
I'll make sure I document this as a requirement.
Thanks,
Doug
