[Qt-creator] QtCreator C++ code parser and clang integration status

André Pönitz andre.poenitz at mathematik.tu-chemnitz.de
Wed Feb 1 22:29:18 CET 2012

On Wed, Feb 01, 2012 at 06:45:52AM -0800, Jonathan S. Shapiro wrote:
> 2012/1/31 Andr  P nitz <andre.poenitz at mathematik.tu-chemnitz.de>
>     But [Clang] wouldn't come for free. On the Creator side there
>     suddenly _needs_ to be a way to persist code models with all the
>     ugly problems that brings regarding storage, synchronisation and
>     housekeeping. There's suddenly an "upstream" and the need to
>     explain why stuff in SLOT(...) should be handled as function
>     signature, and not the string literal that the compiler sees....
> Andr :
> Please forgive my ignorance, but there is obviously something here
> that I am failing to understand.
> I understand why interacting with CLang requires a model like the one
> that you describe, but I would think that any compiler front end would
> need this. Which raises two questions:
> 1. How is the current processing approach avoiding this requirement?

Qt Creator uses Roberto's C++ parser which is geared towards use in
IDEs in general and specifically adapted for use in Qt Creator. 
This is essentially a C++ compiler without actual code generation and
a couple of compromises in the speed-vs-exactness arena. It is fast,
so we can index on-the-fly when projects are loaded.

The problem here is that this parser currently handles only a part of
C++11. If compilers start shipping headers that assume a C++11 compiler
is reading them, it is likely to choke. So the parser would need some
maintenance to be "future proof", even for code that's not actively
using C++11.

The main benefit a clang based model _might_ bring is that "someone
else" (the clang makers...) hopefully would care for C++11 part.
_Right now_ it is not there yet. The hope that it will get there
_sometime_ stems from the fact that XCode relies/will rely on it. 

> 2. It seems that much of this has been solved in Eclipse (for some
> value of "solved"). We obviously can't adopt their code, but would it
> be useful to adopt some of their data model?

The goal is to not regress, so the absolute minimum is a reasonably
correct and complete code model that is able to stay up-to-date on C++
code bases of the size of, say, Qt Creator or Qt, as-you-type, fully
indexes them in a time span measured in seconds, and does not impose
restrictions on the way a user organizes his project.


More information about the Qt-creator mailing list