Author Topic: New code completion remarks/issues  (Read 157444 times)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5274
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: New code completion remarks/issues
« Reply #135 on: October 06, 2009, 02:07:36 pm »
Also, is it possible using the predefined macro name for function name?

Code: [Select]
__FUNCTION__ or
Code: [Select]
__PRETTY_FUNCTION__
since codeblocks is build under GCC. :D
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5274
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: New code completion remarks/issues
« Reply #136 on: October 06, 2009, 03:31:19 pm »
here is the patch of using "TRACE" macro for tokenizer.cpp and parserthread.cpp.




[attachment deleted by admin]
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5274
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: New code completion remarks/issues
« Reply #137 on: October 06, 2009, 03:50:41 pm »
patch for nativeparser.cpp


[attachment deleted by admin]
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9606
Re: New code completion remarks/issues
« Reply #138 on: October 06, 2009, 04:16:57 pm »
I believe the std:: int the actualtype cause it.
Guys, I found the reason for that and it's not easily solvable.

std:: completion worked fine (and still works fine) with GCC3. It is broken with GCC4 and the reason is simple:
Take for example the file vector.tcc (which is the implementation of std::vector in your GCC folder).
In version 3 it was:
Code: [Select]
#ifndef _VECTOR_TCC
#define _VECTOR_TCC 1

namespace _GLIBCXX_STD
{
  // ...
} // namespace std

#endif /* _VECTOR_TCC */
As we replace "_GLIBCXX_STD" within the parser with "std", std::(vector) was easily resolvable. Now things have changed for GCC4, now the wrapper is as follows:
Code: [Select]
#ifndef _VECTOR_TCC
#define _VECTOR_TCC 1

_GLIBCXX_BEGIN_NESTED_NAMESPACE(std, _GLIBCXX_STD_D)

  // ...

_GLIBCXX_END_NESTED_NAMESPACE

#endif /* _VECTOR_TCC */
As you see: This is done using a macro. As we don't have macro expansion it won't work with out implementation of CC anymore. So - this is not a bug in CC, "just" a missing feature and it happens now as we all just jumped to GCC4.

Hence I tried replacing:
_GLIBCXX_BEGIN_NESTED_NAMESPACE(std, _GLIBCXX_STD_D)
with
using namespace std;
and:
_GLIBCXX_END_NESTED_NAMESPACE
with "}", but this of course works not, too as the tokenizer has already tokenized the first statement. So the replacement cannot be done anymore. ;-) In addition the macros is not always like that and sometimes appears multiple times / is nested. So replacements have to be done carefully.
« Last Edit: October 07, 2009, 08:33:13 pm by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5274
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: New code completion remarks/issues
« Reply #139 on: October 06, 2009, 04:27:03 pm »
As we replace "_GLIBCXX_STD" within the parser with "std", std::(vector) was easily resolvable. Now things have changed for GCC4, now the wrapper is as follows:
Code: [Select]
#ifndef _VECTOR_TCC
#define _VECTOR_TCC 1

_GLIBCXX_BEGIN_NESTED_NAMESPACE(std, _GLIBCXX_STD_D)

  // ...

_GLIBCXX_END_NESTED_NAMESPACE

#endif /* _VECTOR_TCC */
As you see: This is done using a macro. As we don't have macro expansion it won't work with out implementation of CC anymore. So - this is not a bug in CC, "just" a missing feature and it happens now as we all just jumped to GCC4.

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

For these kind of macros, we can learn from the Ctags.

See this post:

http://forums.codeblocks.org/index.php/topic,10827.msg74127.html#msg74127

We should expand the replacement method in tokenizer.cpp. :D

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9606
Re: New code completion remarks/issues
« Reply #140 on: October 06, 2009, 04:40:45 pm »
We should expand the replacement method in tokenizer.cpp. :D
No. This does not work, because:
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. ;-)
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5274
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: New code completion remarks/issues
« Reply #141 on: October 06, 2009, 05:18:08 pm »
We should expand the replacement method in tokenizer.cpp. :D
No. This does not work, because:
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. ;-)

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
« Last Edit: October 06, 2009, 05:20:38 pm by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9606
Re: New code completion remarks/issues
« Reply #142 on: October 06, 2009, 05:24:06 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.
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...?!
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5274
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: New code completion remarks/issues
« Reply #143 on: October 06, 2009, 05:37:02 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.
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...?!

I really concern the performance of the parsing, if you do this "replacement" in every m_Buffer of Tokenizer.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9606
Re: New code completion remarks/issues
« Reply #144 on: October 06, 2009, 05:41:52 pm »
If anybody is interested in a patch, I can so so...?!
Here it is btw...

Edit: Invalid now and not needed anymore, just uncomment the section in trunk.
« Last Edit: October 07, 2009, 09:15:12 am by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 12904
    • Travis build status
Re: New code completion remarks/issues
« Reply #145 on: October 06, 2009, 07:47:02 pm »
I want to test it, but it failed to apply in the debugger branch... :(
Morten can you sync trunk and debugger branch?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9606
Re: New code completion remarks/issues
« Reply #146 on: October 06, 2009, 08:05:22 pm »
Morten can you sync trunk and debugger branch?
Sure, but not today anymore.
Hence you can surely just checkout the CC plugin from trunk only and do a file comparision/sanc with the debugger branch yourself. The only method you need to take care about is SetSelectionVoid. That should be the only difference to trunk then.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5274
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: New code completion remarks/issues
« Reply #147 on: October 07, 2009, 03:55:43 am »
Hi, here is the patch for tokenizer.cpp and tokenizer.h

I just change some variable name, such as

m_Str in DoGetToken() function changes to str.
Also, I add a function FixArgument to wrap a lot of operations.


[attachment deleted by admin]
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9606
Re: New code completion remarks/issues
« Reply #148 on: October 07, 2009, 09:16:23 am »
Morten can you sync trunk and debugger branch?
Done. Patch is not needed anymore, just uncomment the section in question in the tokenizer.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline blueshake

  • Regular
  • ***
  • Posts: 459
Re: New code completion remarks/issues
« Reply #149 on: October 07, 2009, 10:04:28 am »
For the right valuetip on typedef.
patch:
Code: [Select]
Index: src/plugins/codecompletion/parser/parserthread.cpp
===================================================================
--- src/plugins/codecompletion/parser/parserthread.cpp (revision 5852)
+++ src/plugins/codecompletion/parser/parserthread.cpp (working copy)
@@ -1765,6 +1765,7 @@
         {
             tdef->m_AncestorsString = ancestor;
             tdef->m_ActualType = ancestor;
+            tdef->m_Type = ancestor;
         }
         else
             tdef->m_ActualType = ancestor + args;

[attachment deleted by admin]
Keep low and hear the sadness of little dog.
I fall in love with a girl,but I don't dare to tell her.What should I do?