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