vector<int> is OK, but string or wstring no-work.

[ollydbg]

After that, CC works now !!!!

[Loaden]

SVN 6077, this code work now.

Code

#include <iostream>
#include <string>

using namespace std;

int main()
{
    basic_string<char> bs;
    bs.append("work fine!");
    basic_string<wchar_t> wbs;
    wbs.append(L"work too!");
    return 0;
}

[attachment deleted by admin]

[Loaden]

After that, CC works now !!!!

Great! Thank you very much! :lol:

[MortenMacFly]

After that, CC works now !!!!

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!

And btw: I had that replacement in the conf file of C::B. Nevertheless it is missing in the code in trunk.

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?

[ollydbg]

After that, CC works now !!!!

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!

It works here. You can see the screenshot as an attachment.

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?

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

[attachment deleted by admin]

[Loaden]

After that, CC works now !!!!

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!

It works here. You can see the screenshot as an attachment.

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?

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

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;
}

[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!

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.

[blueshake]

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.

hi,morten:

if I remember right,the editor name should be the full name.for your example.if there are two same name files in projectA and projectB.

it should be .\projectA\filename
it should be .\projectB\filename


the parser should parse the file correctly according the editor file.

[ollydbg]

if I remember right,the editor name should be the full name.for your example.if there are two same name files in projectA and projectB.

it should be .\projectA\filename
it should be .\projectB\filename

the parser should parse the file correctly according the editor file.

I think a full file name with full path(such as: C:\projectA\AAA.cpp or C:\projectB\AAA.cpp )is recorded in the filelist of CC.

[blueshake]

I think a full file name with full path(such as: C:\projectA\AAA.cpp or C:\projectB\AAA.cpp )is recorded in the filelist of CC.

haha,that is what I want to express.

[ollydbg]

Oh, look this screenshot.

Code

#include <iostream>
#include <string>

using namespace std;

int main()
{
    basic_string<wchar_t> ws;
    ws.
    return 0;
}

@Loaden
This works fine here, rev 6083.
You can see the screen shot below:


[attachment deleted by admin]

[blueshake]

where is the option "parse while typiing"?