[Geany-devel] C++ Symbols problem

[Lex Trotman]

Hi Colomban,

I used both patches all afternoon with no visible problems.  They seem
to work as advertised.  Will keep using, thanks.

Cheers
Lex

On 18 March 2012 08:36, Colomban Wendling <lists.ban at herbesfolles.org> wrote:
> Le 13/03/2012 01:48, Lex Trotman a écrit :
>> Hi All,
>
> Hey!
>
> Here's an initial patch that fixes the issue by better handling of true
> duplicate tags.  It's not necessarily the better fix for the issue,
> where maybe having the template type info would be better, but it is
> more generic since it would handle any duplicate.
>
> It's not much tested, but have fun :)
>
> Cheers,
> Colomban
>
>
>>
>> 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
>> etc.
>>
>> 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).
>>
>> Cheers
>> Lex
>> _______________________________________________
>> Geany-devel mailing list
>> Geany-devel at uvena.de
>> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
>
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>