Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
New code completion remarks/issues
MortenMacFly:
--- Quote from: ollydbg on October 06, 2009, 04:27:03 pm ---We should expand the replacement method in tokenizer.cpp. :D
--- End quote ---
No. This does not work, because:
--- Quote from: MortenMacFly on October 06, 2009, 04:16:57 pm ---Hence I tried replacing:
_GLIBCXX_BEGIN_NESTED_NAMESPACE(std, _GLIBCXX_STD_D)
with
using namespace std;
and:
_GLIBCXX_END_NESTED_NAMESPACE
with "empty", but this of course works not, too as the tokenizer has already tokenized the first statement. So the replacement cannot be done anymore. ;-)
--- End quote ---
ollydbg:
--- Quote from: MortenMacFly on October 06, 2009, 04:40:45 pm ---
--- Quote from: ollydbg on October 06, 2009, 04:27:03 pm ---We should expand the replacement method in tokenizer.cpp. :D
--- End quote ---
No. This does not work, because:
--- Quote from: MortenMacFly on October 06, 2009, 04:16:57 pm ---Hence I tried replacing:
_GLIBCXX_BEGIN_NESTED_NAMESPACE(std, _GLIBCXX_STD_D)
with
using namespace std;
and:
_GLIBCXX_END_NESTED_NAMESPACE
with "empty", but this of course works not, too as the tokenizer has already tokenized the first statement. So the replacement cannot be done anymore. ;-)
--- End quote ---
--- End quote ---
I mean, you can check the token == _GLIBCXX_BEGIN_NESTED_NAMESPACE, if it proves, the tokenizer can eat the following token which is ( "(std, _GLIBCXX_STD_D)"), or do anything you want.
So, what we need to do is "expand the replacement method", which means the tokenizer not only do the replacement, but also do "eat" the next token, or do something else :D
MortenMacFly:
--- Quote from: ollydbg on October 06, 2009, 05:18:08 pm ---I mean, you can check the token == _GLIBCXX_BEGIN_NESTED_NAMESPACE, if it proves, the tokenizer can eat the following token which is ( "(std, _GLIBCXX_STD_D)"), or do anything you want.
--- End quote ---
OK - that might work, indeed and would probably be a feasible solution. But: This is very error prone, for sure. If you look deeper into the STL classes the macros contain macros in itself so the order of replacements matters!
However - I did a nasty hack so that std:: completion works again. I am replacing directly within the buffer before the Tokenizer starts any action. This proves that CC would still be able to do the right thing so it's not a bug.
Hence the cost for this is several calls to wxString::Replace which simply takes an awful lot of time. But it was what I could do quickly.
If anybody is interested in a patch, I can so so...?!
ollydbg:
--- Quote from: MortenMacFly on October 06, 2009, 05:24:06 pm ---
--- Quote from: ollydbg on October 06, 2009, 05:18:08 pm ---I mean, you can check the token == _GLIBCXX_BEGIN_NESTED_NAMESPACE, if it proves, the tokenizer can eat the following token which is ( "(std, _GLIBCXX_STD_D)"), or do anything you want.
--- End quote ---
OK - that might work, indeed and would probably be a feasible solution. But: This is very error prone, for sure. If you look deeper into the STL classes the macros contain macros in itself so the order of replacements matters!
However - I did a nasty hack so that std:: completion works again. I am replacing directly within the buffer before the Tokenizer starts any action. This proves that CC would still be able to do the right thing so it's not a bug.
Hence the cost for this is several calls to wxString::Replace which simply takes an awful lot of time. But it was what I could do quickly.
If anybody is interested in a patch, I can so so...?!
--- End quote ---
I really concern the performance of the parsing, if you do this "replacement" in every m_Buffer of Tokenizer.
MortenMacFly:
--- Quote from: MortenMacFly on October 06, 2009, 05:24:06 pm ---If anybody is interested in a patch, I can so so...?!
--- End quote ---
Here it is btw...
Edit: Invalid now and not needed anymore, just uncomment the section in trunk.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version