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

[André Pönitz]

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
is ;-)]

> > 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.

etc, etc. 

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.

Andre'