[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Hi Michi,
> B<5> b5; // open declaration does not point to specialization
I assume you are trying to open declaration with the caret just
before or just after the 'B'. In these cases, CDT associates the
open declaration with just the template name 'B', rather than
the template-id 'B<5>', and so always finds the primary template.
If, however, you try doing open declaration with the caret being
inside the template parameter list, for example just before or
just after the '5', or with the entire template-id selected, you
will find that CDT does indeed find the correct specialization.
Perhaps it would be more user-friendly to go to the specialization
even if you're beside the 'B' (or inside it, for longer names)?
We'd have to be careful about where we do this, though - for
example, in the *definition* of the specialization, it's useful
to be able to do open declaration on the 'B' and get to the
primary template.
> B<0> b0; // Type Hierarchy not resolved
> B<5> b5; // Type Hierarchy not resolved (again no specialization)
> B<20> b20; // Type Hierarchy not resolved
It looks like there is no support at all for getting the type
hierarchy of a template instance. CDT just tries to compute the
type hierarchy of the template class (and in this case, the base
type of the template class is dependent, so there isn't really
anything to show for that).
I filed bug 413383 [1] for this.
> b0.bb() // code completion works - uses proper conditional
> b5.cc(); // code completion works - uses specialization
> b20.aa(); // code completion works - uses proper conditional
Right. CDT knows what specialization is chosen in each case, and
what its base classes are. The deficiencies you observe exist
only in the Type Hierarchy implementation.
> b20.test(); // this is off topic, but I think it should generate a
> warning (linker problem) - unnoticed when building a library
We could add a codan checker that gives a warning if a function is
declared but not defined anywhere in the project. It would probably
have to be off by default, as there are many cases where the
implementation of some methods is not included in the project.
I filed bug 413384 [2] for this.
Regards,
Nate
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=413383
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=413384