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

Offline blueshake

  • Regular
  • ***
  • Posts: 459
Re: New code completion remarks/issues
« Reply #225 on: December 02, 2009, 01:59:36 am »
Quote
I'm not satisfied with this, maybe, I need to implement a macro replacement rule for the "CVAPI" macro. Wink


we can make a compare here.
if the position of token (void) and token cvFunction are in the same line.keep the CVAPI(void) in m_Str and continue to parse.
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?

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: New code completion remarks/issues
« Reply #226 on: December 02, 2009, 06:38:40 am »
we can make a compare here.
I'd rather go with the token replacement as suggested by OllyDgb. This is configurable and we don't need to implement particular CV SDK hocus-pocus in the plugin. Thus the plugin should not know antyhing about CV. OR make it more generic so that it applies to other similar constructs as well. But this might break something else.
« Last Edit: December 02, 2009, 06:41:09 am by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline Monolith

  • Single posting newcomer
  • *
  • Posts: 2
Re: New code completion remarks/issues
« Reply #227 on: December 19, 2009, 11:24:44 am »
I have notice a couple issues.

(1) There is a problem with typedefs with multiple definitions. For instance, typedef WNDCLASSEXW WNDCLASSEX,*LPWNDCLASSEX,*PWNDCLASSEX; wont get recognized by code complete, however, typedef WNDCLASSEXW WNDCLASSEX; will work.
(2) The parser should recognize definitions, the difference between UNICODE and not UNICODE. For instance, I have a ANSI app, but I had to edit the UNICODE typedef of WNDCLASSEX to get the Code Complete to work.
(3) #define should be recognized as its counterparts. (#define MessageBox MessageBoxW will not be recognized as MessageBoxW.)

You guys have made great strides lately, keep up the good work.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: New code completion remarks/issues
« Reply #228 on: December 19, 2009, 12:54:25 pm »
2 and 3 are known problems -> there is no code written to parse the #defines, as far as I know
(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 blueshake

  • Regular
  • ***
  • Posts: 459
Re: New code completion remarks/issues
« Reply #229 on: December 20, 2009, 01:35:01 am »
Quote
(1) There is a problem with typedefs with multiple definitions. For instance, typedef WNDCLASSEXW WNDCLASSEX,*LPWNDCLASSEX,*PWNDCLASSEX; wont get recognized by code complete, however, typedef WNDCLASSEXW WNDCLASSEX; will work.

um,confirm it.That is because the "," is not handled.thanks for your report.
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?

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: New code completion remarks/issues
« Reply #230 on: December 20, 2009, 12:46:38 pm »
a bug in rev 5984 (Windows) , if you open the CB project, and try to find the declaration of "set", you will find only three entries.

I just test a nightly build of 20091010, the set class was correctly recognized.

see the screenshot below:


Edit:


To simplify the bug, you can just copy the code in

d:\MinGW\lib\gcc\mingw32\4.4.1\include\c++\bits\stl_set.h

to a console project, delete all the #include directive and #if statement, and the code should like below:

Code


_GLIBCXX_BEGIN_NESTED_NAMESPACE(std, _GLIBCXX_STD_D)

  /**
   *  @brief A standard container made up of unique keys, which can be
   *  retrieved in logarithmic time.
   *
   *  @ingroup associative_containers
   *
   *  Meets the requirements of a <a href="tables.html#65">container</a>, a
   *  <a href="tables.html#66">reversible container</a>, and an
   *  <a href="tables.html#69">associative container</a> (using unique keys).
   *
   *  Sets support bidirectional iterators.
   *
   *  @param  Key  Type of key objects.
   *  @param  Compare  Comparison function object type, defaults to less<Key>.
   *  @param  Alloc  Allocator type, defaults to allocator<Key>.
   *
   *  The private tree data is declared exactly the same way for set and
   *  multiset; the distinction is made entirely in how the tree functions are
   *  called (*_unique versus *_equal, same as the standard).
  */
  template<typename _Key, typename _Compare = std::less<_Key>,
   typename _Alloc = std::allocator<_Key> >
    class set
    {
      // concept requirements
      typedef typename _Alloc::value_type                   _Alloc_value_type;
      __glibcxx_class_requires(_Key, _SGIAssignableConcept)
      __glibcxx_class_requires4(_Compare, bool, _Key, _Key,
_BinaryFunctionConcept)
      __glibcxx_class_requires2(_Key, _Alloc_value_type, _SameTypeConcept)

    public:
      // typedefs:
      //@{
      /// Public typedefs.
      typedef _Key     key_type;
      typedef _Key     value_type;
      typedef _Compare key_compare;
      typedef _Compare value_compare;
      typedef _Alloc   allocator_type;
      //@}

    private:
      typedef typename _Alloc::template rebind<_Key>::other _Key_alloc_type;

      typedef _Rb_tree<key_type, value_type, _Identity<value_type>,
       key_compare, _Key_alloc_type> _Rep_type;
      _Rep_type _M_t;  // Red-black tree representing set.

    public:
      //@{
      ///  Iterator-related typedefs.
      typedef typename _Key_alloc_type::pointer             pointer;
      typedef typename _Key_alloc_type::const_pointer       const_pointer;
      typedef typename _Key_alloc_type::reference           reference;
      typedef typename _Key_alloc_type::const_reference     const_reference;
      // _GLIBCXX_RESOLVE_LIB_DEFECTS
      // DR 103. set::iterator is required to be modifiable,
      // but this allows modification of keys.
      typedef typename _Rep_type::const_iterator            iterator;
      typedef typename _Rep_type::const_iterator            const_iterator;
      typedef typename _Rep_type::const_reverse_iterator    reverse_iterator;
      typedef typename _Rep_type::const_reverse_iterator    const_reverse_iterator;
      typedef typename _Rep_type::size_type                 size_type;
      typedef typename _Rep_type::difference_type           difference_type;
      //@}

      // allocation/deallocation
      /**
       *  @brief  Default constructor creates no elements.
       */
      set()
      : _M_t() { }

      /**
       *  @brief  Creates a %set with no elements.
       *  @param  comp  Comparator to use.
       *  @param  a  An allocator object.
       */
      explicit
      set(const _Compare& __comp,
  const allocator_type& __a = allocator_type())
      : _M_t(__comp, __a) { }


......
......


and see the parser works ok or not.



[attachment deleted by admin]
« Last Edit: December 20, 2009, 01:28:52 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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: New code completion remarks/issues
« Reply #231 on: December 20, 2009, 01:01:07 pm »
A further test give the bad result, see the screen shot below:

The parser result is totally wrong.

I personally suspect this bug is introduced by the patch of reading the "template" argument of "visualfc", I'm still examining. Enable PARSERTHREAD_DEBUG_OUTPUT and see the output.
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: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: New code completion remarks/issues
« Reply #232 on: December 20, 2009, 02:20:02 pm »
For example, the code in parserthread.cpp

Code
        if (token == _T("template"))
        {
            wxString args = m_Tokenizer.GetToken(false,true);
            token = m_Tokenizer.GetToken();
            if (args == _T("<>"))
            {
                m_Str.Clear();
                wxString name = m_Tokenizer.GetToken();
                args = m_Tokenizer.PeekToken(false,true);
                m_Tokenizer.UngetToken();
            }
            if (token==ParserConsts::kw_class)
            {
                m_Str.Clear();
                if (m_Options.handleClasses)
                    HandleClass(ctClass,args);
                else
                    SkipToOneOfChars(ParserConsts::semicolonclbrace, true);
                continue;
            }
            else if (token==ParserConsts::kw_struct)
            {
                m_Str.Clear();
                if (m_Options.handleClasses)
                    HandleClass(ctStructure,args);
                else
                    SkipToOneOfChars(ParserConsts::semicolonclbrace, true);
                continue;
            }
            else
            {
                m_Tokenizer.UngetToken();
            }
        }


It is really hard to understand the function call like "m_Tokenizer.GetToken(false,true);" , I think the function should still keep the consistent prototype like( simple and easy to understand) :

GetToken()
PeekToken()

I still can't understand what does these prototype means:
Code
    wxString GetToken(bool bGetValue = false, bool bTemplate = false);
    wxString PeekToken(bool bGetValue = false, bool bTemplate = false);
:(
« Last Edit: December 20, 2009, 02:22:04 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: 9694
Re: New code completion remarks/issues
« Reply #233 on: December 20, 2009, 02:50:47 pm »
I still can't understand what does these prototype means:
Code
    wxString GetToken(bool bGetValue = false, bool bTemplate = false);
    wxString PeekToken(bool bGetValue = false, bool bTemplate = false);
:(
Agreed, the interface could be more clear. Please PM visualfc so he can have a look into...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: New code completion remarks/issues
« Reply #234 on: December 20, 2009, 03:00:17 pm »
I still can't understand what does these prototype means:
Code
    wxString GetToken(bool bGetValue = false, bool bTemplate = false);
    wxString PeekToken(bool bGetValue = false, bool bTemplate = false);
:(
Agreed, the interface could be more clear. Please PM visualfc so he can have a look into...
Thanks, that's great that we have the same consideration  :D.

Yes, I have notified him.

Currently, a workaround is to remove the "handling template related code". :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: 9694
Re: New code completion remarks/issues
« Reply #235 on: December 20, 2009, 03:26:24 pm »
Currently, a workaround is to remove the "handling template related code". :D
True, but in fact I added this to trunk because in fact it helps a lot if it works. In my own projects I use templates on a "normal" level and it works very well there and thus is really helpful (for me at least).
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: New code completion remarks/issues
« Reply #236 on: December 21, 2009, 05:47:31 am »
A reminder: This bug was introduced in the rev 5945.

In DoGetToken function, these code:

Code

    else if (CurrentChar() == '<' && bTemplate)
    {
        MoveToNextChar();
        if (!SkipToOneOfChars(_T(">\r\n")), false)
            return wxEmptyString;

        MoveToNextChar();
        wxString tmp = m_Buffer.Mid(start+1,m_TokenIndex-start-2);
        tmp.Trim();
        str = _T("<");
        str += tmp;
        str += _T(">"); // m_Buffer.Mid(start, m_TokenIndex - start);
    }

So, what does the SkipToOneOfChars(_T(">\r\n")), false) means?

It seems the ">" or "\r" or "\n" was the end of a template argument???
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: 9694
Re: New code completion remarks/issues
« Reply #237 on: December 21, 2009, 06:40:27 am »
So, what does the SkipToOneOfChars(_T(">\r\n")), false) means?
So it seems VisualFC assumed that template arguments are no longer than a single line which isn't true for the STL set as you've seen... :lol:
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: New code completion remarks/issues
« Reply #238 on: December 21, 2009, 06:49:51 am »
Ok, I'm planning to add a "TokenizerState" variable in the Tokenizer class.

The TokenizerState variable is normally a enum variable, and could have the following types:

Code
UnWanted
Preprocessor
Template

Then, the pseudo code could be something like from the old style:

Code
void ParserThread::HandleXXXXXX()
{
    // need to force the tokenizer _not_ skip anything
    // or else default values for template params would cause us to miss everything (because of the '=' symbol)
    bool oldState = m_Tokenizer.IsSkippingUnwantedTokens();
    m_Tokenizer.SetSkipUnwantedTokens(false);
   
    DoSomething();

    m_Tokenizer.SetSkipUnwantedTokens(oldState);
}

The new style:

Code
void ParserThread::HandleXXXXXX()
{

    m_Tokenizer.PushState();
   
    m_Tokenizer.SetState(YYYYY);

    DoSomething();
   
    m_Tokenizer.PopState();
}

I'm not sure the "POP" and "PUSH" mechanism can work here.

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: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: New code completion remarks/issues
« Reply #239 on: December 21, 2009, 07:00:23 am »
So, what does the SkipToOneOfChars(_T(">\r\n")), false) means?
So it seems VisualFC assumed that template arguments are no longer than a single line which isn't true for the STL set as you've seen... :lol:

Also, what about use :

SkipToOneOfChars(_T(">")), true)

because we should let the template argument support nesting of like <   XXXX<YYYYY>>.
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.