Is this something we can solve with the improved CC

[killerbot]

Hi,

This code has had, and still has some problems with CC, more specifically with the 'find declaration' :

Code

#include <iostream>

class ITest
{
public:
	virtual int Method1(int Arg) = 0;
};


class Test : public ITest
{
public:
	int Method1(int Arg);
};


int Test::Method1(int Arg)
{
	return Arg;
}

int main()
{
	Test Hello;
	std::cout << Hello.Method1(5);
	return 0;
}

Scenario :

1) right click Method1 in the call 'Hello.Method1(5)' and choose "find implementation' --> works nicely :-)

2) right click Method1 in the call 'Hello.Method1(5)' and choose "find declaration' --> gives me a choice :

* the ITest declaration
* the Test declaration

I think since the parser should now that Hello is a Test variable, it should not allow me any choice, and automatically select the Test declaration one.

Is this something that can be fixed with the improved CC, or are we still missing something in our parsing/tokens list ?

[blueshake]

Dear killerbot:

I dont think it is easy to do this.

For current parser.It will parse your test codes as this.

ITest
  |- Method1

Test
  |-Method1

And for a faster seach,the parser just get the matched items from the tokenstree.so you can two items from your test codes.


It make no sense if you try to solve the expression,since Test is inherited from ITest.you still will get two items.One in ITest,the other in Test.


killerbot:if you get any idea about this.share it here,please.


I think it will be more harder for parse these codes:

Code

ITest* pHello = new Test();

Even the codecompletion can not work correctly,not mention to others.


BTW:it is amazing that I can write so much English now. :lol: :lol: :lol:

[ollydbg]

@killerbot

As blueshake said, the parsing tree (simply we can say the token tree, or AST) can be like:

ITest
  |- Method1

Test
  |-Method1

Once using the find declaration on the statement: Hello.Method1(5).

In the current CC, I think there are some steps:
1, get the word under the caret, so, we return the "Method1"
2, then we do a search on the TokenTree( it is a trie structure, which store all the token names)
3, then we get all the tokens named "Method1", also, we filter the non-function tokens.
4, Then, we show "two result".

So, the more clever way is analysis the whole expression of "Hello.Method1()", and as you said, the parser knows that this is a function of the "Hello", and the parser also knows that "Hello" is type of class "Test", so, the member methods of "Test" should be searched first, then if the result is 0, we should search following the class inheritance hierarchy, in this case, the ITest class should be searched.

So, I think this bug can be fixed. 

[daniloz]

If I understand right what ollydbg says and if this is changed somehow in the CC to do what  killerbot suggests, does it means that "find implementation" and "find declaration" would also be also to go directly to the relevant class function member in case of functions with same name in different classes?

For example, I have a Reset() function in several classes (more than 20, actually) and each time I do a "find declaration/implementation" I have to chose from a list which class I want.

So, if  the whole expression of "Object.Reset()" is analyzed (as suggested by ollydbg), then the CC can go directly to the relevant Reset() function, right?

[ollydbg]

For example, I have a Reset() function in several classes (more than 20, actually) and each time I do a "find declaration/implementation" I have to chose from a list which class I want.

So, if  the whole expression of "Object.Reset()" is analyzed (as suggested by ollydbg), then the CC can go directly to the relevant Reset() function, right?

Yes, 100% correct!!!

[daniloz]

Cool!!! That's something I was waiting for a while now... 

The other thing is to parse #ifdef statements and parse only the relevant code, but this one I know is a though one... ;-)

[ollydbg]

Cool!!! That's something I was waiting for a while now... 

The other thing is to parse #ifdef statements and parse only the relevant code, but this one I know is a though one... ;-)

Ok, I will help if I have time.

By the way, these days, Loaden has implementing a mechanism to handle #if #ifdef like statement. He has release his code in

http://topic.csdn.net/u/20100412/21/b39c50b9-caeb-406f-a12e-023e088c78c9.html  It is a Chinese programming site.

He has not finished it yet, because he has failed parsing the statement like below:

Code

#if (2 - 1) + !((3 - 2) ^ 1)

Resolving the expression is not quite easy.

[Ceniza]

Code

#if (2 - 1) + !((3 - 2) ^ 1)

Resolving the expression is not quite easy.

If you need to make replacements, then it is not easy. If it is just parentheses, numbers and operators, then it is quite easy once you convert everything into tokens after the #if and skip all whitespace.

The code that evaluates constant expressions is in constexprevaluator.h of CCPP, but no one liked that code because of all template stuff. Re-using the productions would give you the desired result. It is just a matter of replacing all template stuff into specific types.

Anyway...

[ollydbg]

@Ceniza
I know you CCPP project, and I have tried that several months ago, but as you said, it is hard to understand...

If your CCPP project can used to replace the current Tokenizer class. ( All I want is " macro replacement, and #if XXXX evaluation), it will make CC more powerful.

But I'm sorry I can't fully understand these source code structure. Can you give a more description about your CCPP? Thanks.

[killerbot]

If I understand right what ollydbg says and if this is changed somehow in the CC to do what  killerbot suggests, does it means that "find implementation" and "find declaration" would also be also to go directly to the relevant class function member in case of functions with same name in different classes?

For example, I have a Reset() function in several classes (more than 20, actually) and each time I do a "find declaration/implementation" I have to chose from a list which class I want.

So, if  the whole expression of "Object.Reset()" is analyzed (as suggested by ollydbg), then the CC can go directly to the relevant Reset() function, right?

I can fully confirm this. That is indeed the idea behind my suggestion, to have these kind of things fixed. I think this would be an big improvement in our CC.

Let's hope our CC specialists can come up with a solution.

[ollydbg]

Doing "find implementation" is some thing much like to the autoCompletion.

For example:

When

Code

Object.Reset()

, you would like to find the implementation of Reset().

This is just like doing the autoCompletion when you are entering, the vertical slash stands for the caret position.

Code

Object.Reset|

The only difference is: Doing autoCompletion will list all the members with the prefix string "Reset", so there will be a list like:

Code

Reset()
ResetXXX
ResetYYYY
.....

But doing "find implementation" will only do a full match of the "Reset", and only the function members will be matched.

 

[MortenMacFly]

I can fully confirm this. That is indeed the idea behind my suggestion, to have these kind of things fixed. I think this would be an big improvement in our CC.

I would do it slightly different: Consider you have base classes and you do want to see the base method which your derived class may have overwritten. So I still would show all methods, but maybe kind of sorted by it's relevance. So like first the one of the very class I am directly targeting, then the onces of base classes etc. Searching for the whole object as suggested makes this impossible. I can live very well with being presented a lot of "Reset" functions (it's the same for me with methods called "Init" and "ReInit"). I benefit from seeing all matches and would disagree if I see only one or less in the end.

...just don't over-do it!

[daniloz]

I benefit from seeing all matches and would disagree if I see only one or less in the end.
...just don't over-do it!

My case is not related with derived classes, in which case I agree with MortenMacFly. I was think of different classes (not related to each other) with methods called "Reset", in which case I don't see the advantage of seeing the other classes in the list, since they're not related to the object in question.

What do you think??

[ollydbg]

@mac

Code

Searching for the whole object as suggested makes this impossible. I can live very well with being presented a lot of "Reset" functions (it's the same for me with methods called "Init" and "ReInit"). I benefit from seeing all matches and would disagree if I see only one or less in the end.

Not fully understand these sentence.  Does it means all the function in the class inheritance hierarchy should be displayed. I just agree with daniloz that all the other functions should be removed from the list.

[Ceniza]

@Ceniza
I know you CCPP project, and I have tried that several months ago, but as you said, it is hard to understand...

If your CCPP project can used to replace the current Tokenizer class. ( All I want is " macro replacement, and #if XXXX evaluation), it will make CC more powerful.

But I'm sorry I can't fully understand these source code structure. Can you give a more description about your CCPP? Thanks.

At least the constexprevaluator:

WSSkipper is a class that returns the next non-whitespace token given an iterator. It actually works as a wrapper around the iterator.
TokenContainer is just a... er... container (like a vector, deque, list, ...) that has all tokens after #if up to the end of the expression. The last token must be a ttEOT (Token Type End-Of-Tokens).
All you have to do is to give this sequence of tokens to ConstExprEvaluator::eval() and it will tell you if the expression evaluates to true or false.

I attach the file just in case. What is important from it are the rules.

[attachment deleted by admin]