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

[eike.ziller at nokia.com]

On 1 Feb 2012, at 12:53, ext 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".
> 
>> 
>> 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.
> But then you need all the build flags at parse time.

Mind that for some features you actually want *more* than the compiler sees. E.g. when doing "Follow Symbol" your preferred destination is the definition of whatever you follow, not a forward declaration or some declaration in some header. But the definition is in most cases not "seen" by the compiler when it compiles your current unit.

>> clang won't solve that kind of problems. clang would bring in the
>> remaining bits of C++, clang would bring Objective C and C++. But it
>> 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. The user suddenly has to use precompiled headers and
>> his CPU is suddenly really busy.
> 
> Yes, I forgot all the Qt macros which are not only "macros".
> For this stuff the existing parser could be used. But having
> two parsers running also complicates things.
> 
>> 
>> To cut it short: There's a whole lot of cost associated with the clang
>> approach beyond the pure performance issue, and I am personally very
>> sceptical that this would be a net gain. On the other hand, it might
>> just work. But we'll only know after someone actually implemented it...
>> 
>> Andre'
>> 
> 
> -- 
> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator

-- 
Eike Ziller
Principal Software Engineer

Nokia, Qt Development Frameworks

Nokia gate5 GmbH
Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany
Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B
Umsatzsteueridentifikationsnummer: DE 812 845 193
Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori