[Geany-devel] C++ Symbols problem

Lex Trotman elextr at xxxxx
Tue Mar 13 00:48:36 UTC 2012

Hi All,

There is a problem with symbols in some C++ programs which causes some
class members to appear and disappear or move in the sidebar.
Needless to say this is *very* distracting.

The minimal program to demonstrate this is:

template<bool b>class problem;

template<> class problem<false> {

template<> class problem<true> {
	int i_change;

The member i_change changes each time the symbols pane is updated,
correctly showing as part of the class at line 6, then part of the
class at line 3, then disappearing, then back to the class at line 6

In C++ this program has three class names:

a) at line 1 declaration of problem<bool>
b) at line 3 definition of problem<false>
c) at line 6 definition of problem<true>

Note that these are distinct classes as if the names include <bool>,
<true> and <false>.

But neither symbols.c or the tagmanager parser includes the template
parameters in the name, instead showing both of the classes at line 3
and 6 as "problem".

Discussion with Colomban on IRC indicated that this may be confusing
the symbol update algorithm.  Forcing a complete re-generation of the
symbols did indeed stabilise the sidebar.

I think that the problem is due to update_tree_tags() identifying the
parent of i_change just by name so it can't tell if line 3 or line 6
(or possibly line 1) is the parent.

If  i_change is shown in the symbol tree as part of the class at line
6 then it will be in the parent_tags hash with parent of "problem".
If this is taken as "problem"of line 3 as parent, it will delete it
from the class at line 6 in pass 1 and as i_change is still in the
tags list will add it to the class at line 3 since thats what the
parent_tags hash says is its parent.

On the next symbol update, since what it thinks is the parent of
i_change (the class at line 3) does not in fact have i_change as a
member, it will be deleted from the tree and the tags list, so it
isn't added again in pass 2.

On the next symbol update i_change is not in the tree so it isn't in
the parent_tags hash so it is added where the tags list says is the
correct place.

If the order of the definitions at line 3 and 6 are reversed i_change
just alternates on and off, suggesting that it isn't the first
definition of the symbol "problem" that is the one found.

At least I think this is the mechanism?

Other than the hack to re-create the whole table each time, I'm not
sure how to cure it without distinguishing the three class names, and
that means modifying tagmanager/c.c (shudder).


More information about the Devel mailing list