Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign

Is this something we can solve with the improved CC

<< < (3/4) > >>

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

For example:

When

--- Code: ---Object.Reset()
--- End code ---
, 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|
--- End code ---

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
.....

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

 

MortenMacFly:

--- Quote from: killerbot on April 14, 2010, 11:50:26 pm ---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.

--- End quote ---
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:

--- Quote from: MortenMacFly on April 15, 2010, 07:10:26 am ---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!

--- End quote ---

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.
--- End code ---
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:

--- Quote from: ollydbg on April 14, 2010, 04:27:32 pm ---@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.

--- End quote ---

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]

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version