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 > [email protected] > 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 _______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
