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

Cristian Tibirna tibirna at kde.org
Fri Jun 1 03:56:01 CEST 2012


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.

-- 
Cristian Tibirna
KDE developer .. tibirna at kde.org .. http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/qt-creator/attachments/20120531/cc4bbc1e/attachment.sig>


More information about the Qt-creator mailing list