Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
CC plugin interface redesign
oBFusCATed:
Probably you've lost direction in your changes, because I saw you've added another edit->complete code item (shift-space hotkey). Why? What is it purpose?
The two defines are extremely ugly. Try to no use them and use an enum instead or even enum in a struct (to simulate the strong enum c++11 feature).
What is supposed to do GetTokenAt and what is supposed to do GetAutocompList?
If they do different things it doesn't matter that they have similar signatures/return types - you should keep them separate.
Alpha:
--- Quote from: oBFusCATed on September 08, 2013, 02:02:02 am ---[...] I saw you've added another edit->complete code item (shift-space hotkey). Why? What is it purpose?
--- End quote ---
The entry used to be supplied by the main CC plugin. I moved it to the application, so that CCManager can make the same shortcut work for any/all CC plugins.
GetTokenAt() currently only supplies information for showing tooltips, however, I intended it to be something that another plugin, ex. debugger, could call for more accurate results when doing some other operation. GetAutocompList() supplies tokens for the code completion popup by looking at the prefix.
--- Quote from: oBFusCATed on September 08, 2013, 02:02:02 am ---Probably you've lost direction in your changes [...]
--- End quote ---
Probably.
oBFusCATed:
From you explanation I conclude that:
1. GetTokenAt could return multiple tokens depicting full tokens (type, name, namespace, parameteres, etc), for example multiple functions.
2. GetAutocompList returns also multiple tokens, but they are different from the ones returned in GetTokenAt.
They are just member function names, type info, parameters.
3. The debugger needs only the full name or better name it the expression. No need for function parameters, type, namespace, etc.
The debugger needs the name of a member expanded to the full expression used to access it.
At the moment if you hover over a member you'll get just the member and if you try to evaluate it, you'll get "variable not found in scope", because you tried to evaluate variable "member1" instead of "a.b->c->member1". The debugger needs a way to expand a particular string word to the full expression at the cursor. So we need a different method here again.
Also I don't think you need to worry too much if you add too many pure methods.
If the plugin developer thinks it is best to handle them the same, he can do so no problem (he can add a common method and convert parameters).
Providing clear and separate names is better for source readability. An API where you have a few functions that do lots of stuff is most of the times worse than an API with many functions doing simple things each...
Also don't worry, just iterate on the API until it feels good to you...
Alpha:
If I need to modify the return of, say:
--- Code: ---virtual std::vector<CCToken> GetAutocompList(int& tknStart, int& tknEnd, cbEditor* ed) = 0;
--- End code ---
is it the preferred style to use:
--- Code: ---virtual void GetAutocompList(std::vector<CCToken>& tokens, int& tknStart, int& tknEnd, cbEditor* ed) = 0;
--- End code ---
to avoid a (potentially) expensive copy on the vector?
oBFusCATed:
It depends...
c++11: The first one is almost always better.
c++98: It depends on some things:
- Is the copy really expensive (many elements in the vector)?
- Will it be called many times and so the copy will show in the profiler?
If the answers to both questions is no, then I'll use the first style otherwise the second.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version