Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
vector<int> is OK, but string or wstring no-work.
Loaden:
--- Quote from: ollydbg on January 13, 2010, 01:00:13 am ---
--- Quote from: MortenMacFly on January 12, 2010, 06:44:30 pm ---
--- Quote from: ollydbg on January 12, 2010, 03:47:36 pm ---After that, CC works now !!!!
--- End quote ---
Not for me. :-(
What happens if you just open the TESTING workspace of the CC plugin, activate the STL project, open stl.cpp and uncomment the "ss.". CC does not kick in for me!
--- End quote ---
It works here. You can see the screenshot as an attachment.
--- Quote from: MortenMacFly on January 12, 2010, 06:44:30 pm ---In the original code the order in how the strings were replaced (when replacing in the whole buffer) did matter. I don't think it does so in the current version as it is based on the appearance of the tokens, but just to double check: Is that correct?
--- End quote ---
In the replacement map( wxString Key to wxString Value), I don't think current code has some thing wrong, because each "wxString Key" are different. right? Oh, I can confirm that what you concern won't happen. because when the Tokenizer DoGetToken, they will return a whole "Token string", thus, "_GLIBCXX_BEGIN_NAMESPACE_TR1" and "_GLIBCXX_END_NAMESPACE" are totally different tokens when we are at the last stage of the DoGetToken() function.
Finally, I think the answer is :"it is correct". :D
--- End quote ---
I applied this patch, string parsing normal, but wstring parsing is not correct.
[attachment deleted by admin]
Loaden:
And I found that map, make_pair can parse and display the correct information:
http://forums.codeblocks.org/index.php/topic,11784.msg80355.html#msg80355
But this problem still exists:http://forums.codeblocks.org/index.php/topic,11784.msg80354.html#msg80354
Loaden:
Oh, look this screenshot.
--- Code: ---#include <iostream>
#include <string>
using namespace std;
int main()
{
basic_string<wchar_t> ws;
ws.
return 0;
}
--- End code ---
[attachment deleted by admin]
MortenMacFly:
Dammed. I believe I found the REAL reason for the quirks now. blueshake: it may indeed be your real time parse... :-(
What happens:
Assume you have several projects in a WS (like the CC "TESTING" WS). Now if you have project A activated but edit a file with the same name of project B and within a function of the same name as present in project A the real-time parse will update the parser according to the editors name. Hence this may be truncated so what gets updated is the wrong method.
So what happens in my case and why std::string does still not work for make is that the function scope cannot be evaluated as the wrong file is picked and the function markers are invalid. Thus CC will abort and nothing kicks in.
I've made real time parse an option now, however, we should fix this issue!
So: For all of you still struggling of the missing std::string (or alike) completion: Disable "parse while typing" in the CC options but keep in mind that the parser is then only updated upon save! So you need to save the file before you can expect the following to CC:
--- Code: --- std::string s;
s. // << CC shall kick in here!
--- End code ---
CC works fine for me in any cases now when I have disabled "parse while typing".
Loaden:
I also feel that real-time analysis for editing dulled. After the use of the SVN6082, obviously there is no sense of delay.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version