[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