[Qt-creator] RFC: solving the problem of symbol partition to arbitrary files

[Jochen Becher]

Hi Christian

As a simple work-around in your own code you could add #include
"class.h" to your .icc file. This should work in compiling your file (as
class_h_already_included is already defined when preprocessor tries to
include class.h from .icc file). And it should help Qt Creator to learn
the template declarations within .icc file.

Regards, Jochen


Am Donnerstag, den 31.05.2012, 21:56 -0400 schrieb Cristian Tibirna:
> Hello
> 
> I almost hijaked the "Switch header/source" thread but then I thought better. 
> I guess what follows is a different issue.
> 
> Consider a class with template methods, partitioned as follows:
> 
> MyClass.h
> --------------------
> #ifndef class_h_already_included
> #define class_h_already_included
> 
> class MyClass {
> public:
>   template<typename T> void template_method(const T& pT);
>   void normal_method();
> };
> 
> #include "MyClass.icc"
> 
> #endif
> -----------------------
> 
> MyClass.icc
> -----------------------
> template<typename T> void MyClass::template_method(const T& pT)
> {
> // stg. here
> }
> -----------------------
> 
> MyClass.cc
> -----------------------
> #include "MyClass.h"
> 
> void MyClass::normal_method()
> {
> // stg. else here
> }
> -----------------------
> 
> The (almost?) usual for classes with public template methods. Given the scope 
> of the template method, it has to be available for inclusion, thus defined 
> (and not only declared) in the .h.
> 
> But, of course, for large classes, with many methods, this can potentially 
> polute the .h greatly and thus, a reasonable decision often encountered in 
> large projects is to relegate the template methods to a separate "quasi-
> source" file, included at the end of the .h file.
> 
> This is all typical (if arbitrary) drill and works perfectly with any 
> compiler.
> 
> Now, come QtCreator, the .icc files become unfortunately second-class 
> citizens. Forget the atypical extension. We could use any of the usual: .hpp, 
> .hxx, .hh, .h++, .tpp, .tcc etc (and I tried them). It also doesn't matter to 
> what mimetype we stick the .icc extension: src-c++ or src-hdr.
> 
> The problem is that the incompletely resolved parsing of the template-defining 
> file lets it hanging dry. 
> 
> It's not like the .h, which has its used declarations included (and resolved) 
> from other .h files (with #include directives) or from forward declarations, 
> and it's not like the .cc file, which gets its declarations from its own .h 
> inclusion.
> 
> The use of .icc file introduces problems with symbol following, with 
> completions and more. What works:
> - syntax colorisation (partially -- e.g. class attributes are not colorised)
> - symbol resolution for anything that is resolvable from eventual #include 
> directives present in the .icc file (not exemplified above)
> - local symbol resolution (local variables) 
> 
> What doesn't work:
> - header/quasi-source and quasi-source/header switching (with F2)
> - symbol resolution for class attributes (!)
> - symbol searching (with Ctrl+Shift+U or with Ctrl+Shift+F>C++Symbols
> 
> I checked that when all the contents of .icc file is relocated in the .h file, 
> everything works OK.
> 
> I also checked that, given a bit of include-guard sorcery and adding an 
> #include directive for the corresponding .h file in the .icc file also works 
> around the problems (but this is nor need for the compiler neither in any way 
> beautiful or at least excuseable).
> 
> Ah, and we don't even need template methods. The same is possible when 
> partitioning (this way) inline methods (which also have to provide their 
> definitions for inclusion).
> 
> I can understand why these functionalities fail: the symbol resolution is 
> based on the actual parsing of the full unfolding of the current file. Since 
> an .icc lacks (and doesn't need) an #include of the corresponding .h file, 
> this mechanism fails.
> 
> Unfortunately I know very little of the current parsing code (or the llvm-
> based alternative for what matters).
> 
> Thus my question: is this a known issue? (in fact, I know it should be, I 
> reported it in QTCREATORBUG-2309). Does somebody have an idea for the actual 
> reasons and (mercifully) for eventual solutions?
> 
> Greatly thanks for your attention.
> 
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator