[Qt-creator] QtCreator C++ code parser and clang integration status
andre.poenitz at mathematik.tu-chemnitz.de
Wed Feb 1 23:01:00 CET 2012
On Wed, Feb 01, 2012 at 12:53:34PM +0100, Peter Kuemmel wrote:
> > >
> > > I didn't know there is a contest :)
> > It's a contest. The better solution wins. And "better" in the strictly
> > practical sense. If one approach is implemented, and the other not,
> > the implemented one is better.
> I'm still skeptical. To often I've heard (at other places)
> "but we don't like it".
[Seems unrelated. But I think it is safe to assume that an implemented
solution will trump a non-implemented one, no matter what the problem
> > The assumption that a clang based code model would be perfect "because
> > it is a real compiler" comes up often, but is wrong. There will always
> > be "unclean" #ifdef'd blocks, bunches of .cpp that only compile when
> > #include'd in a defined order, or a specific namespace, headers that are
> > included multiple times with different #defines set, etc.
> > Any non-trivial code base has examples for things like that.
> I don't see the problem here. I only wanna see what the compiler sees.
I am pretty sure you do not. And I am not even talking about expanded
or not-expanded preprocessor macros.
Most of the time during normal editing your code is in a non-compilable
state. The compiler is typically given code that's compilable, or close
to it. This is a completely different setup.
You would also not be happy if <F2> brings you to a class declaration,
and not to the actual class definition, even if the compiler "acts"
on the declaration.
The assumption that a "full c++ compiler" would magically meet all
needs of an IDE is simply wrong.
> But then you need all the build flags at parse time.
Seems unrelated. And of course we have to ask the compiler about
built-in defines etc already now.
More information about the Qt-creator