Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => CodeCompletion redesign => Topic started by: Loaden on January 06, 2010, 05:39:50 am

Title: vector<int> is OK, but string or wstring no-work.
Post by: Loaden on January 06, 2010, 05:39:50 am
Hello, everyone! I compiled SVN6056 version, and do not use already existing default.conf, but by the CB to generate a new configuration file.
After I found: vector <int> can already be a normal CB resolved, but the string and wstring not be resolved CB. As shown in the following code: there is no intelligence tips.
Code
#include <iostream>
#include <string>

int main()
{
    std::string s;
    s.
    return 0;
}

Code
#include <iostream>
#include <string>

using namespace std;

int main()
{
    string s;
    s.
    return 0;
}



[attachment deleted by admin]
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: Loaden on January 06, 2010, 05:46:27 am
but if i use this code, it's work!
Code
#include <iostream>
#include <string>

using namespace std;

int main()
{
    basic_string<char> s;
    s.
    return 0;
}

but if use wchar_t, it's no-work too.
Code
#include <iostream>
#include <string>

using namespace std;

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



[attachment deleted by admin]
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: Loaden on January 06, 2010, 05:49:51 am
but this code is work fine.
Code
#include <iostream>
#include <string>

int main()
{
    std::basic_string<char> s;
    s.
    return 0;
}

[attachment deleted by admin]
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 06, 2010, 06:03:44 am
the string's ancestor is lost.that is why it can not work.



Note:it work in svn 5986.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 06, 2010, 08:23:08 am
the string's ancestor is lost.that is why it can not work.
I don't thinks that's the reason. In fact I think I found it.

I've submitted some minor enhancements to debug SmartSense.
If you do exactly the following (with this code base):
0.) Open C::B with debug log enabled
1.) Open the CC testing project
2.) Activate the STL project
3.) Open the stl.cpp file
4.) Uncomment the "s." line (do not save!)
5.) Go to the symbols browser, enable SmartSense
6.) Clear the Debug log
7.) After the "s." try CTRL+SPACE (CC kicks in)
8.) Notice this output in the debug log:

FindCurrentFunctionStart() Looking for tokens in 'C:\Devel\CodeBlocks\src\plugins\codecompletion\testing\stl.cpp'
FindCurrentFunctionStart() Found 1 results
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='int main(void)', tF='C:\Devel\CodeBlocks\src\plugins\codecompletion\testing\duplicate_header.cpp', tStart=52, tEnd=117
FindCurrentFunctionStart() Function out of bounds: tN='int main(void)', tF='C:\Devel\CodeBlocks\src\plugins\codecompletion\testing\duplicate_header.cpp', tStart=52, tEnd=117, line=9 (size_t)line=9
FindCurrentFunctionStart() Can't determine current function...

You will realise that the token returned does not match in the file name even though FindTokensInFile was given the right file name. The result: The function bounds check will fail and thus CC cannot code complete (no matter if it's string or vector or alike).

blueshake: I believe this is related to the "real time parse" where probably some false file information is passed... Could that be? Can you please try SVN trunk?
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 06, 2010, 12:06:23 pm
Quote
blueshake: I believe this is related to the "real time parse" where probably some false file information is passed... Could that be? Can you please try SVN trunk?

ok,i will try it.but I just pass the filename .nothing more.

and see the string information in svn 5986 and svn 6056.see the screen shot.



[attachment deleted by admin]
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 06, 2010, 12:23:31 pm
um,it seems something relatived to the files.

in svn 6056(which not work),the debug log output:only 141 files are parsed.

Quote
Parsing stage done (141 total parsed files, 28885 tokens in 0 minute(s), 1.781 seconds).


in svn 5986(which work,I have apply the real-time parser in my local copy with this svn version),the debug log output:164 files are parsed.

Quote
Parsing stage done (164 total parsed files, 30028 tokens in 0 minute(s), 1.985 seconds).

Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 06, 2010, 12:23:34 pm
and see the string information in svn 5986 and svn 6056.see the screen shot.
Hmmm... weird. So it could also e related to OllyDbg's modifications for the typedef handling. Because it's in fact a typedef.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 06, 2010, 12:34:16 pm
mention to typedef ,but these codes work fine.
Code
#include <iostream>

using namespace std;
class qq
{
    int x;
    int y;
};
typedef qq pp;
typedef pp tt;

int main()
{
    cout << "Hello world!" << endl;
    return 0;
}

see the attachmet.


[attachment deleted by admin]
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 06, 2010, 01:01:49 pm
Quote
Parsing stage done (141 total parsed files, 28885 tokens in 0 minute(s), 1.781 seconds).
Quote
Parsing stage done (164 total parsed files, 30028 tokens in 0 minute(s), 1.985 seconds).
Hmmm... could you do me a favour and try r6044 versus r6045? r6044 should still work. The modifications between r5986 and r6044 should not matter.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 06, 2010, 01:19:01 pm
Quote
Parsing stage done (141 total parsed files, 28885 tokens in 0 minute(s), 1.781 seconds).
Quote
Parsing stage done (164 total parsed files, 30028 tokens in 0 minute(s), 1.985 seconds).
Hmmm... could you do me a favour and try r6044 versus r6045? r6044 should still work. The modifications between r5986 and r6044 should not matter.

It is a shame to say that I don't know how to do it.

and I turn the real-time parse off in latest svn with nothing changed.

the issue still exist.so I think there is something wrong with parserthread.


I found a big problem.
try these codes.

Code
#include <iostream>

using namespace std;
class qq
{
    int x;
    int y;
};
typedef qq pp;
typedef pp tt;
tt cc;//



int main()
{
    cout << "Hello world!" << endl;
    return 0;
}


follow the steps below:
-save the codes in cb
-close the cb application.
-restart the cb ----------------at this point .the parser work fine.
-add any codes below tt cc;//-----------------then the variable can not be parsed correctly.there is no any variable in the symboltree.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 06, 2010, 02:27:20 pm
the issue still exist.so I think there is something wrong with parserthread.
OK - after some tests it's definitely related to:
http://forums.codeblocks.org/index.php/topic,11754.msg79756.html#msg79756

Stage management is not working as before. OllyDbg?!
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 06, 2010, 02:34:09 pm
the issue still exist.so I think there is something wrong with parserthread.
OK - after some tests it's definitely related to:
http://forums.codeblocks.org/index.php/topic,11754.msg79756.html#msg79756

I will check this bug. It seems the preprocessor of "include" statement is not correct.

Quote
Stage management is not working as before. OllyDbg?!
what does "stage management" means???
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 06, 2010, 02:47:09 pm
Quote
Stage management is not working as before. OllyDbg?!
what does "stage management" means???
It meant the modifications you did with Tokenizer state (introducing the enum TokenizerState).
For example (void ParserThread::DoParse()):
Before:
Code
        else if (token==ParserConsts::kw_operator)
        {
            bool oldState = m_Tokenizer.IsSkippingUnwantedTokens();
            m_Tokenizer.SetSkipUnwantedTokens(false);
            m_Tokenizer.SetOperatorState(true);
After:
Code
            TokenizerState oldState = m_Tokenizer.GetState();
            m_Tokenizer.SetState(tsSkipNone);

...or (void ParserThread::HandleClass(EClassType ct, const wxString& templateArgs)):
Before:
Code
    // don't forget to reset that if you add any early exit condition!
    bool oldState = m_Tokenizer.IsSkippingUnwantedTokens();
    m_Tokenizer.SetSkipUnwantedTokens(false);
After:
Code
    // don't forget to reset that if you add any early exit condition!
    TokenizerState oldState = m_Tokenizer.GetState();
    m_Tokenizer.SetState(tsSkipUnWanted);

This might be a mistake...?!
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 06, 2010, 03:06:06 pm
Ok, let's explain some thing about introduce a "state" variable in the Tokenizer.
There are several reasons:

1, Before that, Tokenizer use a bool variable SkipUnWanted to determine where the Tokenizer need to skip some statement like  assignment "=" or array subscirpt "[]".

2, Angle Brace is a single token return from the Tokenizer::GetToken or Tokenizer::PeekToken.
But when we want to read the template argument. like the code below:
Code
template < XXXX >
class AAA{
...
}

I would perfer the Tokenizer return the whole string < XXXX >

3,When we are entering some context, we should save the context state.
Before:
Code
bool oldState = m_Tokenizer.IsSkippingUnwantedTokens();
            m_Tokenizer.SetSkipUnwantedTokens(false);
            m_Tokenizer.SetOperatorState(true);
            

Do some parsing..


            m_Tokenizer.SetSkipUnwantedTokens(oldState);

But I think a bool variable is not enough to describe all the context, so ,I use a more flexiable enum variable.

The benifit is that Currently, CC is only a partily parser, which means some statements are skiped( currently, the member function body is skiped, the statement in the right side of an assignment is skiped too). But for the long run, I think add a state is convient :D
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 06, 2010, 05:03:38 pm
But for the long run, I think add a state is convient :D
I know, that's why I applied the patch. ;-) However, there seems to be something wrong with the new implementation where you surely can help... :P
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 07, 2010, 01:13:12 pm
I'm confused about your discussion. Does this bug comes from the "real-time CC" or the patch of my modification of Tokenizer??? :?
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 07, 2010, 01:22:41 pm
Does this bug comes from the "real-time CC" or the patch of my modification of Tokenizer??? :?
From the new Tokenizer states. Have another look at my previous post. The two examples in the code do obviously the opposite of what was done previously. Is this intended behaviour of yours?

Meaning, shouldn't we apply this patch:
Code
Index: src/plugins/codecompletion/parser/parserthread.cpp
===================================================================
--- src/plugins/codecompletion/parser/parserthread.cpp (revision 6058)
+++ src/plugins/codecompletion/parser/parserthread.cpp (working copy)
@@ -403,7 +403,7 @@
     // need to reset tokenizer's behavior
     // don't forget to reset that if you add any early exit condition!
     TokenizerState oldState = m_Tokenizer.GetState();
-    m_Tokenizer.SetState(tsSkipUnWanted);
+    m_Tokenizer.SetState(tsSkipNone);
 
     m_Str.Clear();
     m_LastToken.Clear();
@@ -1385,7 +1385,7 @@
         wxString next = m_Tokenizer.PeekToken(); // named namespace
         if (next==ParserConsts::opbrace)
         {
-            m_Tokenizer.SetState(tsSkipNone);
+            m_Tokenizer.SetState(tsSkipUnWanted);
 
             // use the existing copy (if any)
             Token* newToken = TokenExists(ns, m_pLastParent, tkNamespace);

However, you changes quite a lot related to skipping so I might be wrong...
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 07, 2010, 02:08:26 pm
No, the first place when entering the DoParse function. we should set the state to "

Code
    // need to reset tokenizer's behavior
    // don't forget to reset that if you add any early exit condition!
    TokenizerState oldState = m_Tokenizer.GetState();
    m_Tokenizer.SetState(tsSkipUnWanted);
    m_Str.Clear();
    ....

This is the default setting.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 07, 2010, 02:35:01 pm
No, the first place when entering the DoParse function. we should set the state to "
Could you explain '' a little more? Set to what exactly? And what's with the second one?
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 07, 2010, 02:55:58 pm
No, the first place when entering the DoParse function. we should set the state to "
Could you explain '' a little more? Set to what exactly? And what's with the second one?

OK, let me explain the old way( before the patch of Tokenizer state related code).
There is a variable named: m_SkipUnwantedTokens(true), you can see this from the constructor of Tokenizer, so, by default, this means in normal situation, we should let the Tokenizer skip some words. In very merely case, this variable would set to "true" to let the Tokenizer never skip anything.

So, the new way ( after applying my patch), I would set the state to "skipUnWanted", so this is the same behavour like the old one.


For the second place:
I'm sorry, that's my mistake, you are right!

Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 07, 2010, 03:05:07 pm
OK, let me explain the old way( before the patch of Tokenizer state related code). [...]
Thanks, that made things clear to me.

So finally, what happened to:
Code
m_Tokenizer.SetOperatorState(true);
This is not applied anymore if I got the new implementation right. Look again:
For example (void ParserThread::DoParse()):
Before:
Code
        else if (token==ParserConsts::kw_operator)
        {
            bool oldState = m_Tokenizer.IsSkippingUnwantedTokens();
            m_Tokenizer.SetSkipUnwantedTokens(false);
            m_Tokenizer.SetOperatorState(true);
After:
Code
            TokenizerState oldState = m_Tokenizer.GetState();
            m_Tokenizer.SetState(tsSkipNone);
Any comments on that...?!
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 07, 2010, 03:18:14 pm
So finally, what happened to:
Code
m_Tokenizer.SetOperatorState(true);
This is not applied anymore if I got the new implementation right. Look again:
For example (void ParserThread::DoParse()):
Before:
Code
        else if (token==ParserConsts::kw_operator)
        {
            bool oldState = m_Tokenizer.IsSkippingUnwantedTokens();
            m_Tokenizer.SetSkipUnwantedTokens(false);
            m_Tokenizer.SetOperatorState(true);
After:
Code
            TokenizerState oldState = m_Tokenizer.GetState();
            m_Tokenizer.SetState(tsSkipNone);
Any comments on that...?!


I personally don't think we need another variable to specify we are after the operator statement.

for example:

Code
void AAA::operator + (XXXX)
or
void AAA::operator = (XXXX)

In such situations, the word after "operator" should return from GetToken() function. ( They won't be skipped ). So, I think once we meet a "operator" word, we need to set the TokenizerState to "tsSkipNone".

Is that OK?  :D
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 11, 2010, 03:12:16 am
Test report:
rev 6067 trunk windows.
CodeCompletion testing workspace:
function_args.cpp can't full pass.
Code
//    i_integer = from.i_;
//    f_float   = from.f_;
stl.cpp can't fully pass
Code
  std::string ss;
  ss.
stl_namespace.cpp can't fully pass.
Code
  string s;
  s.
structs_typedefs.cpp can't fully pass.
Code
    std::string ss;
    my_string   ms;
    ss.

I'm try to find the bug, but these days I'm a little busy :?
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 11, 2010, 08:41:02 am
Ok, have a further test, I'm fully agree with blueshake's No ancestor's in the current string Token (http://forums.codeblocks.org/index.php/topic,11800.msg80086.html#msg80086), so, the "string" have no ancestors, that's the reason why we don't have string members list auto completion.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 11, 2010, 08:49:24 am
Ok, have a further test, [...]
Just for the record: I've implemented some more debugging facilities with the last commit of mine. You can now save the tokens tree to an ASCii file from  the CC debug window.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 11, 2010, 08:57:21 am
Ok, have a further test, [...]
Just for the record: I've implemented some more debugging facilities with the last commit of mine. You can now save the tokens tree to an ASCii file from  the CC debug window.

Yes, I have noticed that, it is a great improvement!
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 11, 2010, 12:22:06 pm
Ok, have a further test, I'm fully agree with blueshake's No ancestor's in the current string Token (http://forums.codeblocks.org/index.php/topic,11800.msg80086.html#msg80086), so, the "string" have no ancestors, that's the reason why we don't have string members list auto completion.
I wonder if the modification you did in void ParserThread::ReadClsNames(wxString& ancestor) are 100% correct. NOtice this code snippet:
Before:
Code
        else if (   wxIsalpha(current.GetChar(0))
                 && (   (m_Tokenizer.PeekToken() == ParserConsts::semicolon)
                     || (m_Tokenizer.PeekToken() == ParserConsts::comma)) )
        {
            TRACE(_T("ReadClsNames() : Adding variable '%s' as '%s' to '%s'"),
                  current.wx_str(),
                  m_Str.wx_str(),
                  (m_pLastParent ? m_pLastParent->m_Name.wx_str():_T("<no-parent>")));

            Token* newToken = DoAddToken(tkTypedef, current, m_Tokenizer.GetLineNumber());
            if (!newToken)
                break;
            else
            {
                wxString tempAncestor       = ancestor;
                newToken->m_AncestorsString = tempAncestor;
                newToken->m_ActualType      = tempAncestor;
                newToken->m_Type            = tempAncestor;
            }
        }
After:
Code
        else if (   wxIsalpha(current.GetChar(0))
                 && (   (m_Tokenizer.PeekToken() == ParserConsts::semicolon)
                     || (m_Tokenizer.PeekToken() == ParserConsts::comma)) )
        {
            TRACE(_T("ReadClsNames() : Adding variable '%s' as '%s' to '%s'"),
                  current.wx_str(),
                  m_Str.wx_str(),
                  (m_pLastParent ? m_pLastParent->m_Name.wx_str():_T("<no-parent>")));

            m_Str.clear();
            wxString tempAncestor = ancestor;
            m_Str = tempAncestor;
            Token* newToken = DoAddToken(tkTypedef, current, m_Tokenizer.GetLineNumber());
            if (!newToken)
                break;
            else
            {
                newToken->m_AncestorsString = tempAncestor;
                //newToken->m_ActualType      = tempAncestor;
                //if (m_IsPointer)
                //{
                //    newToken->m_Type = tempAncestor + _T("*");
                //}
                //else
                //newToken->m_Type            = tempAncestor;
            }
        }
You are not setting the m_Type etc. This is commented out. Is this intended (and if so: Why)?
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 11, 2010, 01:49:59 pm
I just do a test, that, I create a simple cpp file from basci_string.

It seems the parserThread failed in parsing these statement:

Code
  template<typename _CharT, typename _Traits, typename _Alloc>
    inline basic_string<_CharT, _Traits, _Alloc>::
    basic_string()
#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
    : _M_dataplus(_S_empty_rep()._M_refdata(), _Alloc()) { }
#else
    : _M_dataplus(_S_construct(size_type(), _CharT(), _Alloc()), _Alloc()) { }
#endif

  // operator+
  /**
   *  @brief  Concatenate two strings.
   *  @param lhs  First string.
   *  @param rhs  Last string.
   *  @return  New string with value of @a lhs followed by @a rhs.
   */
  template<typename _CharT, typename _Traits, typename _Alloc>
    basic_string<_CharT, _Traits, _Alloc>
    operator+(const basic_string<_CharT, _Traits, _Alloc>& __lhs,
     const basic_string<_CharT, _Traits, _Alloc>& __rhs)
    {
      basic_string<_CharT, _Traits, _Alloc> __str(__lhs);
      __str.append(__rhs);
      return __str;
    }

because when I read the TRACE Debug output, these code were failed.
You can just copy the testString.txt(see the attachment of this post)'s content to a empty project, and set the
#define PARSERTHREAD_DEBUG_OUTPUT 1

Then view the debug log output.

Note: the testString.txt is just a modified source from STL header file of basic_string.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 11, 2010, 02:04:21 pm
You can see the last sentence of the debug log.
Code
DoAddToken() : Found token (parent).
DoAddToken() : Created token='compare', file_idx=1, line=2016
GetActualTokenType() : Searching within m_Str='int'
GetActualTokenType() : Compensated m_Str='int'
GetActualTokenType() : Found 'int'
DoAddToken() : Prepending ''
DoAddToken() : Added/updated token 'compare' (172), type 'int', actual 'int'. Parent is basic_string (1)
DoParse() : Loop:m_Str='', token=';'
DoParse() : Loop:m_Str='', token='int'
DoParse() : Loop:m_Str='int ', token='compare'
HandleFunction() : Adding function 'compare': m_Str='int '
HandleFunction() : name='compare', args='(size_type __pos, size_type __n1, const _CharT* __s, size_type __n2)', peek='const'
HandleFunction() : !(Ctor/Dtor) 'compare', m_Str='int ', localParent='<none>'
HandleFunction() : Adding function 'compare', ': m_Str='int ', enc_ns='nil'.
HandleFunction() : Add token name='compare', args='(size_type __pos, size_type __n1, const _CharT* __s, size_type __n2)', return type='int '
GetStrippedArgs() : args='(size_type __pos, size_type __n1, const _CharT* __s, size_type __n2)'.
GetStrippedArgs() : stripped_args='(size_type,size_type,const _CharT*,size_type)'.
DoAddToken() : Found token (parent).
DoAddToken() : Created token='compare', file_idx=1, line=2042
GetActualTokenType() : Searching within m_Str='int'
GetActualTokenType() : Compensated m_Str='int'
GetActualTokenType() : Found 'int'
DoAddToken() : Prepending ''
DoAddToken() : Added/updated token 'compare' (173), type 'int', actual 'int'. Parent is basic_string (1)
DoParse() : Loop:m_Str='', token=';'
DoParse() : Loop:m_Str='', token='}'
DoParse() : Loop:m_Str='', token='template'
DoParse() : template argument='<typename _CharT, typename _Traits, typename _Alloc>', token ='inline'
DoParse() : Loop:m_Str='', token='#'
HandlePreprocessorBlocks() : Saving nesting level: 1
HandlePreprocessorBlocks() : Restoring nesting level: 1 (was 1)
DoParse() : Loop:m_Str='', token='template'
DoParse() : template argument='<typename _CharT, typename _Traits, typename _Alloc>', token ='basic_string'
DoParse() : Loop:m_Str='', token='template'
DoParse() : template argument='<typename _CharT, typename _Traits, typename _Alloc>', token ='basic_string'
DoParse() : Loop:m_Str='', token='template'
DoParse() : template argument='<typename _CharT, typename _Traits, typename _Alloc>', token ='basic_string'
DoParse() : Loop:m_Str='', token='template'
DoParse() : template argument='<typename _CharT, typename _Traits, typename _Alloc>', token ='inline'
DoParse() : Loop:m_Str='', token='template'
DoParse() : template argument='<typename _CharT, typename _Traits, typename _Alloc>', token ='inline'
DoParse() : Loop:m_Str='', token='template'
DoParse() : template argument='<typename _CharT, typename _Traits, typename _Alloc>', token ='inline'
DoParse() : Loop:m_Str='', token='}'
DoParse() : Loop:m_Str='', token='template'
DoParse() : template argument='<typename _CharT, typename _Traits, typename _Alloc>', token ='inline'
Parsing stage done (1 total parsed files, 174 tokens in 0 minute(s), 8.377 seconds).
Updating class browser...
Class browser updated.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 11, 2010, 04:17:58 pm
Code
        if (token == ParserConsts::kw_template)
        {
            // There are some template defintions that are not working like
            // within gcc headers (NB: This syntax is a GNU extension):
            // extern template
            //    const codecvt<char, char, mbstate_t>&
            //    use_facet<codecvt<char, char, mbstate_t> >(const locale&);
            m_Tokenizer.SetState(tsTemplateArgument);
            wxString args = m_Tokenizer.GetToken();
            token = m_Tokenizer.GetToken();
            TRACE(_T("DoParse() : Template argument='%s', token ='%s'"), args.wx_str(), token.wx_str());
            if (token==ParserConsts::kw_class)
            {
                m_Str.Clear();
                if (m_Options.handleClasses)
                    HandleClass(ctClass, args);
                else
                    SkipToOneOfChars(ParserConsts::semicolonclbrace, true);
            }
            else if (token==ParserConsts::kw_struct)
            {
                m_Str.Clear();
                if (m_Options.handleClasses)
                    HandleClass(ctStructure, args);
                else
                    SkipToOneOfChars(ParserConsts::semicolonclbrace, true);
            }
            else
            {
                SkipToOneOfChars(ParserConsts::semicolonclbrace, true);
            }
        }
We should rethink the code above, for example, there are some template declaration like below:
Code
template<typename _CharT, typename _Traits, typename _Alloc>
    inline bool
    operator<=(const basic_string<_CharT, _Traits, _Alloc>& __lhs,
      const basic_string<_CharT, _Traits, _Alloc>& __rhs)
    { return __lhs.compare(__rhs) <= 0; }

at this time, the "token string" behind the template argument is not "class" nor "struct", but a general function declaration. So, I think we should use a variable like "template argument" to specify the current context".

For example:

When the parser eat these strings "template<typename _CharT, typename _Traits, typename _Alloc>", we can set the variable "template argument", then we continue our DoParse Loop. next we add a Token, we should attach this "template argument" context to the Token. So, This variable is just like other variables like: m_Str( store the type information) or m_EncounteredTypeNamespaces (store the namespace in data types).

Any way, checking the next token after the template argument is not a correct way.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 11, 2010, 06:29:01 pm
Any way, checking the next token after the template argument is not a correct way.
True, but I still wonder why it works with vector and alike and why with any revision before applying your and blueshake's patch it used to work. There must be another error.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: Loaden on January 12, 2010, 01:24:56 am
Will it be to replace the rules of the problem? This is CodeLite replacement rules:
Code
EXPORT
WXDLLIMPEXP_CORE
WXDLLIMPEXP_BASE
WXDLLIMPEXP_XML
WXDLLIMPEXP_XRC
WXDLLIMPEXP_ADV
WXDLLIMPEXP_AUI
WXDLLIMPEXP_CL
WXDLLIMPEXP_LE_SDK
WXDLLIMPEXP_SQLITE3
WXMAKINGDLL
WXUSINGDLL
_CRTIMP
__CRT_INLINE
__cdecl
__stdcall
WXDLLEXPORT
WXDLLIMPORT
wxT
wxTopLevelWindowNative=wxTopLevelWindowMSW
wxWindow=wxWindowMSW
wxStatusBar=wxStatusBarBase
WXUNUSED
wxDEPRECATED
_T
ATTRIBUTE_PRINTF_1
ATTRIBUTE_PRINTF_2
WXDLLIMPEXP_FWD_BASE
WXDLLIMPEXP_FWD_CORE
DLLIMPORT
DECLARE_INSTANCE_TYPE
emit
Q_OBJECT
Q_PACKED
Q_GADGET
QT_BEGIN_HEADER
QT_END_HEADER
Q_REQUIRED_RESULT
Q_INLINE_TEMPLATE
Q_OUTOFLINE_TEMPLATE
_GLIBCXX_BEGIN_NAMESPACE(std)=namespace std{
_GLIBCXX_END_NAMESPACE=}
_GLIBCXX_BEGIN_NESTED_NAMESPACE(std, _GLIBCXX_STD)=namespace std{
_GLIBCXX_BEGIN_NESTED_NAMESPACE(std, _GLIBCXX_STD_D)=namespace std{
_GLIBCXX_END_NESTED_NAMESPACE=}
_GLIBCXX_STD=std
WXDLLIMPEXP_SCI
__const=const
__restrict
__THROW
__wur
_STD_BEGIN=namespace std{
_STD_END=}
__CLRCALL_OR_CDECL
_CRTIMP2_PURE
Among them, through the following replacement rules, can support VC9 header file parsing:
Code
_STD_BEGIN=namespace std{
_STD_END=}
__CLRCALL_OR_CDECL
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 12, 2010, 02:28:38 am
hi,guys:

see what the template handle do,
Code
        if (token == ParserConsts::kw_template)
        {
            m_Tokenizer.SetState(tsTemplateArgument);
            wxString args = m_Tokenizer.GetToken();
            token = m_Tokenizer.GetToken();
            TRACE(_T("DoParse() : template argument='%s', token ='%s'"), args.wx_str(), token.wx_str());
            if (token==ParserConsts::kw_class)
            {
                m_Str.Clear();
                if (m_Options.handleClasses)
                    HandleClass(ctClass,args);
                else
                    SkipToOneOfChars(ParserConsts::semicolonclbrace, true);
            }
            else if (token==ParserConsts::kw_struct)
            {
                m_Str.Clear();
                if (m_Options.handleClasses)
                    HandleClass(ctStructure,args);
                else
                    SkipToOneOfChars(ParserConsts::semicolonclbrace, true);
            }
            else
            {
                SkipToOneOfChars(ParserConsts::semicolonclbrace, true);
            }
        }

just as ollydbg said,when the the next token is not class or struct,the parser will skip to }/;,I think it is wrong here.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 12, 2010, 02:51:53 am
@blueshake:
Yes, the code is added by me.
Code
            else
            {
                SkipToOneOfChars(ParserConsts::semicolonclbrace, true);
            }
I nearly forget what's in the visualfc's patch, he use a different logic. So, I will check it.

@macfly
I will exam it, it seems the code before is not correct either, but it do show some code completion list.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 12, 2010, 02:58:23 am
Here is improved testString.txt, I have test in an old rev 5988, it seems the last part of file was skipped.
Eg, You can't find the declaration of this function.
Code
  inline wstring
  to_wstring(long long __val)
  { return __gnu_cxx::__to_xstring<wstring>(&std::vswprintf,
   4 * sizeof(long long),
   L"%lld", __val); }


You can enable PARSERTHREAD_DEBUG_OUTPUT 1 to see the log.

Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 12, 2010, 03:49:54 am
I'm planning adding a variable to store the Template argument in the ParserThread.cpp.

Some thing like below:

Code
        if (token == ParserConsts::kw_template)
        {
            m_Tokenizer.SetState(tsTemplateArgument);
            m_TemplateArgument = m_Tokenizer.GetToken();
            m_Str.Clear();
            token = m_Tokenizer.GetToken();
            TRACE(_T("DoParse() : Reading Template argument='%s'"), m_TemplateArgument.wx_str());
            m_Tokenizer.SetState(tsSkipUnwanted);
        }

So, when we are about to add some tokens like "class" or "function", we can check m_TemplateArgument. if it is an wxEmptyString, then the currently token is a "normal" token, if not, the current token is a template token.

Also, I suggest that in the Token.h.

we can add a member to the Token class. like:
Code
class Token : public BlockAllocated<Token, 10000>{
...
wxString m_TemplateArgument;
}

Any comments?
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 12, 2010, 04:28:40 am
If you do this, do not forget to change the codes about mouse hover tip too. :D
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 12, 2010, 06:54:30 am
I'm planning adding a variable to store the Template argument in the ParserThread.cpp.
[...]
Sounds good.

Also, I suggest that in the Token.h.
we can add a member to the Token class. like:
[...]
For what purpose? Displaying the template arguments?
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 12, 2010, 08:39:56 am
Quote
For what purpose? Displaying the template arguments?
Yes, also, if we need to do some template instantiation, we need to store the template argument.

Currently, Further more, if a "class template" Token, we can use the "argument" field to store the template argument. But if it is a "function template" Token, we need another field. :D
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 12, 2010, 09:46:26 am
hi,ollydbg:

I get some codes from the string test file.It seems the typedef can not handle correctly.
Code
class basic_string
{

};
_GLIBCXX_BEGIN_NAMESPACE(std)

  template<typename _Alloc>
    class allocator;

  template<class _CharT>
    struct char_traits;

  template<typename _CharT, typename _Traits = char_traits<_CharT>,
           typename _Alloc = allocator<_CharT> >
    class basic_string;

  template<> struct char_traits<char>;

  typedef basic_string<char>    string;

#ifdef _GLIBCXX_USE_WCHAR_T
  template<> struct char_traits<wchar_t>;

  typedef basic_string<wchar_t> wstring;
#endif

#if (defined(__GXX_EXPERIMENTAL_CXX0X__) \
     && defined(_GLIBCXX_USE_C99_STDINT_TR1))

  template<> struct char_traits<char16_t>;
  template<> struct char_traits<char32_t>;

  typedef basic_string<char16_t> u16string;
  typedef basic_string<char32_t> u32string;

#endif

_GLIBCXX_END_NAMESPACE

//string aaaa;
//aaaa.



you can find that the string loses its ancestor.It work before.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 12, 2010, 10:11:17 am
you can find that the string loses its ancestor.It work before.
Exactly. That's what I noticed, too. Still: I don't see why that is. But it's most likely related to Ollydbg's patch. So I was hoping he'd help us...
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 12, 2010, 10:18:55 am
you can find that the string loses its ancestor.It work before.
Exactly. That's what I noticed, too. Still: I don't see why that is. But it's most likely related to Ollydbg's patch. So I was hoping he'd help us...
Ok, I will try my best to find the bug :D
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 12, 2010, 02:09:20 pm
This is a patch for testing, I just add a member variable to ParserThread and Token. It seems the parser works better. :D.
Also, I refined my testString.txt.

Comments and suggestion are welcome. :D

[attachment deleted by admin]
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 12, 2010, 03:29:51 pm
I noticed that we have forgot one Macro replacement rule

Code
_GLIBCXX_END_NAMESPACE   to  }

in default.conf file , change to this
Code
		<TOKEN_REPLACEMENTS>
<ssmap>
   <_GLIBCXX_END_NAMESPACE>
<![CDATA[}]]>
</_GLIBCXX_END_NAMESPACE>
<_GLIBCXX_BEGIN_NAMESPACE>
<![CDATA[+namespace]]>
</_GLIBCXX_BEGIN_NAMESPACE>
<_GLIBCXX_BEGIN_NAMESPACE_TR1>
<![CDATA[-namespace tr1 {]]>
</_GLIBCXX_BEGIN_NAMESPACE_TR1>
<_GLIBCXX_BEGIN_NESTED_NAMESPACE>
<![CDATA[+namespace]]>
</_GLIBCXX_BEGIN_NESTED_NAMESPACE>
<_GLIBCXX_END_NAMESPACE_TR1>
<![CDATA[}]]>
</_GLIBCXX_END_NAMESPACE_TR1>
<_GLIBCXX_END_NESTED_NAMESPACE>
<![CDATA[}]]>
</_GLIBCXX_END_NESTED_NAMESPACE>
<_GLIBCXX_STD>
<![CDATA[std]]>
</_GLIBCXX_STD>
</ssmap>
</TOKEN_REPLACEMENTS>

Edit

Also, this rule should be added to this function body
Code
Tokenizer::SetReplacementString(_T("_GLIBCXX_END_NAMESPACE"),          _T("}"));

Code
void CodeCompletion::LoadTokenReplacements()
{
    ConfigManager* cfg = Manager::Get()->GetConfigManager(_T("code_completion"));

    ConfigManagerContainer::StringToStringMap& repl = Tokenizer::GetTokenReplacementsMap();
    repl.clear();

    if (!cfg->Exists(_T("token_replacements")))
    {
        // first run; add default replacements string
        Tokenizer::SetReplacementString(_T("_GLIBCXX_STD"),                    _T("std"));
        Tokenizer::SetReplacementString(_T("_GLIBCXX_BEGIN_NESTED_NAMESPACE"), _T("+namespace"));
        Tokenizer::SetReplacementString(_T("_GLIBCXX_END_NESTED_NAMESPACE"),   _T("}"));
        Tokenizer::SetReplacementString(_T("_GLIBCXX_BEGIN_NAMESPACE"),        _T("+namespace"));
        Tokenizer::SetReplacementString(_T("_GLIBCXX_END_NAMESPACE_TR1"),      _T("}"));
        Tokenizer::SetReplacementString(_T("_GLIBCXX_BEGIN_NAMESPACE_TR1"),    _T("-namespace tr1 {"));
    }
    else
        cfg->Read(_T("token_replacements"), &repl);
}
By the way, I found it's hard to enter in the CC's configure dialog.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 12, 2010, 03:47:36 pm
After that, CC works now !!!!
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: Loaden on January 12, 2010, 03:53:37 pm
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]
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: Loaden on January 12, 2010, 05:34:57 pm
After that, CC works now !!!!
Great! Thank you very much! :lol:
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 12, 2010, 06:44:30 pm
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?
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 13, 2010, 01:00:13 am
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". :D

[attachment deleted by admin]
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: Loaden on January 13, 2010, 03:26:37 am
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". :D
I applied this patch, string parsing normal, but wstring parsing is not correct.



[attachment deleted by admin]
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: Loaden on January 13, 2010, 03:31:23 am
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 (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 (http://forums.codeblocks.org/index.php/topic,11784.msg80354.html#msg80354)
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: Loaden on January 13, 2010, 02:24:59 pm
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]
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 13, 2010, 03:09:25 pm
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".
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: Loaden on January 13, 2010, 04:49:39 pm
I also feel that real-time analysis for editing dulled. After the use of the SVN6082, obviously there is no sense of delay.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 14, 2010, 01:47:42 am
Quote
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.

Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 14, 2010, 01:58:47 am

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.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 14, 2010, 02:01:07 am
Quote
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.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 14, 2010, 02:09:35 am
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]
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 14, 2010, 02:33:59 am
where is the option "parse while typiing"?
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 14, 2010, 02:37:56 am
where is the option "parse while typiing"?
Menu->settings->Editor->CodeCompletion.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 14, 2010, 03:10:21 am
hi,I encouter that the parser can not parse in real-time even I enable "parse while typing".

edit:
     update to the latest svn without any change.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 14, 2010, 03:13:42 am
hi,I encouter that the parser can not parse in real-time even I enable "parse while typing".

edit:
     update to the latest svn without any change.

Yes, I can confirm this bug.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 14, 2010, 03:59:41 am
the reason is simple.
the variable needParse's scope is function scope.when it (needParse) leave the functioin body.it will be destroyed.so it will be false again when the carect is in different line.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: Loaden on January 14, 2010, 04:57:58 am
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:

If you drag the scroll bar prompt window, you will find many non-basic_string <T> function, it seems from iostream.


[attachment deleted by admin]
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: Loaden on January 14, 2010, 04:59:04 am
SVN 6083.


[attachment deleted by admin]
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 14, 2010, 06:18:32 am
Quote
If you drag the scroll bar prompt window, you will find many non-basic_string <T> function, it seems from iostream.


you can not use variable name ws here.because it has been defined in istream.tcc which belong to gcc files.


Note:

try another name e.g. wsss,you will get the answer.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 14, 2010, 06:38:29 am
Quote
If you drag the scroll bar prompt window, you will find many non-basic_string <T> function, it seems from iostream.


you can not use variable name ws here.because it has been defined in istream.tcc which belong to gcc files.


Note:

try another name e.g. wsss,you will get the answer.

Good! So, this is not a problem. :wink:
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 14, 2010, 06:46:52 am
Just a reminder:

@morten

This is a big bug, should be fixed soon.

Re: The 12 January 2010 build (6080) is out. (http://forums.codeblocks.org/index.php/topic,11844.msg80487.html#msg80487)
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: Loaden on January 14, 2010, 08:12:53 am
Quote
If you drag the scroll bar prompt window, you will find many non-basic_string <T> function, it seems from iostream.


you can not use variable name ws here.because it has been defined in istream.tcc which belong to gcc files.


Note:

try another name e.g. wsss,you will get the answer.

Good! So, this is not a problem. :wink:
Confirm it! Thanks!
Below code works fine.
Code
#include <iostream>
#include <string>

int main()
{
    std::wstring ws;
    ws.
    return 0;
}
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 14, 2010, 11:45:53 am
the reason is simple.
the variable needParse's scope is function scope.when it (needParse) leave the functioin body.it will be destroyed.so it will be false again when the carect is in different line.
I don't get it. m_NeedReparse was used just there. So what's wrong with this piece of code:
Code
    Parser* parser = m_NativeParser.GetParserPtr();
    bool needReparse = false;
    if (   parser && parser->Options().whileTyping
        && (   (event.GetModificationType() & wxSCI_MOD_INSERTTEXT)
            || (event.GetModificationType() & wxSCI_MOD_DELETETEXT) ) )
    {
        needReparse = true;
    }
    if (control->GetCurrentLine() != m_CurrentLine)
    {
        if (parser && needReparse)
            parser->Reparse(editor->GetFilename());
        else
            FindFunctionAndUpdate(control->GetCurrentLine());
    }
It will trigger the re-parse correctly in the case a parser is present, the option is enabled and a char was inserted/deleted.

So...?! (I am a bit sick, so probably you should explain slowly... ;-)).
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 14, 2010, 11:46:49 am
@morten
This is a big bug, should be fixed soon.
Re: The 12 January 2010 build (6080) is out. (http://forums.codeblocks.org/index.php/topic,11844.msg80487.html#msg80487)
Done in my local copy. Will commit in a while... probably after blueshake answered the other question which may require some modifications, too.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 14, 2010, 12:32:54 pm
Quote
I don't get it. m_NeedReparse was used just there. So what's wrong with this piece of code:


see the codes below,in the new codes,it declare a new variable needReparse ,not m_NeedReparse.
    Parser* parser = m_NativeParser.GetParserPtr();
    bool needReparse = false;
    if (   parser && parser->Options().whileTyping
        && (   (event.GetModificationType() & wxSCI_MOD_INSERTTEXT)
            || (event.GetModificationType() & wxSCI_MOD_DELETETEXT) ) )
    {
        needReparse = true;
    }
    if (control->GetCurrentLine() != m_CurrentLine)
    {
        if (parser && needReparse)
            parser->Reparse(editor->GetFilename());
        else
            FindFunctionAndUpdate(control->GetCurrentLine());
    }
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 14, 2010, 12:35:06 pm
maybe this will help a little.
Code
Index: src/plugins/codecompletion/codecompletion.cpp
===================================================================
--- src/plugins/codecompletion/codecompletion.cpp (revision 6083)
+++ src/plugins/codecompletion/codecompletion.cpp (working copy)
@@ -2085,17 +2085,24 @@
     }
 
     Parser* parser = m_NativeParser.GetParserPtr();
-    bool needReparse = false;
+    //bool needReparse = false;
     if (   parser && parser->Options().whileTyping
         && (   (event.GetModificationType() & wxSCI_MOD_INSERTTEXT)
             || (event.GetModificationType() & wxSCI_MOD_DELETETEXT) ) )
     {
-        needReparse = true;
+        //needReparse = true;
+        m_NeedReparse = true;
     }
     if (control->GetCurrentLine() != m_CurrentLine)
     {
-        if (parser && needReparse)
-            parser->Reparse(editor->GetFilename());
+
+        if (parser && m_NeedReparse)
+           {
+               m_NeedReparse = false;
+               parser->Reparse(editor->GetFilename());
+           }
         else
             FindFunctionAndUpdate(control->GetCurrentLine());
     }
Index: src/plugins/codecompletion/codecompletion.h
===================================================================
--- src/plugins/codecompletion/codecompletion.h (revision 6083)
+++ src/plugins/codecompletion/codecompletion.h (working copy)
@@ -135,7 +135,7 @@
         int                                m_ActiveCalltipsNest;
 
         bool                               m_IsAutoPopup;
-
+        bool                                m_NeedReparse;
         wxChoice*                          m_Function;
         wxChoice*                          m_Scope;
         FunctionsScopeVec                  m_FunctionsScope;


NOTE:

the patch is used to show what changed(or explain what I try to say.please do not apply it)
:wink:
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: Jenna on January 14, 2010, 02:27:28 pm
To make it clear, why the current code does not work:

needReparse is set to true whenever text is inserted or deleted, but the reparsing is only triggered if we leave the current line.
This does normally (never ?) happen inside the same event, so we have to remember whether a reparse is needed, either with a member-variable or a static local variable.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 14, 2010, 04:31:47 pm
This does normally (never ?) happen inside the same event, so we have to remember whether a reparse is needed, either with a member-variable or a static local variable.
Dammed. Now I got the point. Ok... I'll take care...
Me should not work when being sick. :?
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: Jenna on January 14, 2010, 04:41:29 pm
Me should not work when being sick. :?

Nobody should.

I hope you feel better soon.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 16, 2010, 01:09:38 pm
This is what Visual c++'s code completion do in the feature:
http://blogs.msdn.com/vcblog/archive/2009/08/12/tag-parsing-c.aspx
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 16, 2010, 03:43:11 pm
I think a variable in Tokenizer class can be removed, because it is never used any more.

Code
bool             m_IsOperator;

BTW: comparing with the "operator" keyword is done in the ParserThread class instead of Tokenizer class.

Edit
Also, this function is never used in Tokenizer, we use another function.
Code
    inline const wxString& ThisOrReplacement(const wxString& str) const
    {
        ConfigManagerContainer::StringToStringMap::const_iterator it = s_Replacements.find(str);
        if (it != s_Replacements.end())
            return it->second;
        return str;
    };
So, it can be cleaned up.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 17, 2010, 02:40:20 am
Quote
I think a variable in Tokenizer class can be removed, because it is never used any more.

Code:

bool             m_IsOperator;


BTW: comparing with the "operator" keyword is done in the ParserThread class instead of Tokenizer class.

@ollydbg

it was used here in nativeparser.cpp

Code
if (!token)
        {
            if (s_DebugSmartSense)
                Manager::Get()->GetLogManager()->DebugLog(_T("FindAIMatches() Token is NULL?!"));
            continue;
        }

        // ignore operators
        if (token->m_IsOperator)
            continue;

        // enums children (enumerators), are added by default
        if (token->m_TokenKind == tkEnum)
        {
            // insert enum type
            result.insert(id);
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 17, 2010, 02:58:47 am
Quote
I think a variable in Tokenizer class can be removed, because it is never used any more.

Code:

bool             m_IsOperator;


BTW: comparing with the "operator" keyword is done in the ParserThread class instead of Tokenizer class.

@ollydbg

it was used here in nativeparser.cpp

Code
if (!token)
        {
            if (s_DebugSmartSense)
                Manager::Get()->GetLogManager()->DebugLog(_T("FindAIMatches() Token is NULL?!"));
            continue;
        }

        // ignore operators
        if (token->m_IsOperator)
            continue;

        // enums children (enumerators), are added by default
        if (token->m_TokenKind == tkEnum)
        {
            // insert enum type
            result.insert(id);
No, There is a member m_IsOperator in the Token class. so does in Tokenizer class.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 17, 2010, 11:50:31 am
test codes:
Code
#include <iostream>

using namespace std;
int abc(int aa)
{

    int bb;
    aa----------------------not work here.
    return 0;
}
int main()
{
    cout << "Hello world!" << endl;
    return 0;
}

issue:

the cc can not do codecompletion for variable aa

reason:

I suspect  that the function arguments were not parsed.

see the output log.yoou can see that only one temp token bb was added.
Quote
ParseLocalBlock() Block:


    int bb;
    aa
ParseLocalBlock() Local tokens:
ParseLocalBlock() + int bb parent =
AI() AI enter, actual_search: "    aa"
AI() =========================================================


And see the output log of work version,two temp tokens(aa and bb) were added.
Quote
ParseLocalBlock() Block:


    int bb;
    aa
ParseLocalBlock() Local tokens:
ParseLocalBlock() + int aa parent =
ParseLocalBlock() + int bb parent =
AI() AI enter, actual: "    aa"
AI() =========================================================
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: Loaden on January 17, 2010, 12:53:04 pm
Code
#include <iostream>
#include <map>
#include <string>

int main()
{
    typedef std::map<int, std::string> TestMap;
    TestMap testMap;
//    testMap. // not work!

    std::map<int, std::string> m;
    m.insert(1, "Hello World!"); // work fine.
    return 0;
}


[attachment deleted by admin]
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 17, 2010, 01:07:28 pm
Quote
   std::map<int, std::string> m;
    m.insert(1, "Hello World!"); // work fine.

not work for me.

I search the tokenstree and get nothing.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: Loaden on January 17, 2010, 01:26:07 pm
Quote
    std::map<int, std::string> m;
    m.insert(1, "Hello World!"); // work fine.

not work for me.

I search the tokenstree and get nothing.


[attachment deleted by admin]
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 17, 2010, 01:41:46 pm
test code:
Code
int abc(int aaaaa)
{

    int bb;
    aaa
    return 0;
}
int main()
{
    cout << "Hello world!" << endl;
    return 0;
}


In a old version of C::B, it works!
Code
MarkItemsByAI()
ParseUsingNamespace() Parse file scope for "using namespace"
ParseFunctionArguments() Parse function arguments
FindCurrentFunctionStart() Current function: int abc(int aaaaa) (at line 1)
GenerateResultSet() search 'abc', parent='Global namespace (id:0, type:(null)), isPrefix=0'
ParseFunctionArguments() + Function match: abc
ParseFunctionArguments() Parsing arguments: "int aaaaa;"
ParseLocalBlock() Parse local block
ParseLocalBlock() Block:


    int bb;
    aaa
ParseLocalBlock() Local tokens:
ParseLocalBlock() + int aaaaa parent =
ParseLocalBlock() + int bb parent =
AI() AI enter, actual: "    aaa"
AI() =========================================================

In the current C::B, failed. see the log:
Code
MarkItemsByAI()
ParseUsingNamespace() Parse file scope for "using namespace"
ParseLocalBlock() Parse local block
FindCurrentFunctionStart() Looking for tokens in 'C:\cb\testforum\main.cpp'
FindCurrentFunctionStart() Found 2 results
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='int main()', tF='C:\cb\testforum\main.cpp', tStart=9, tEnd=12
FindCurrentFunctionStart() Function out of bounds: tN='int main()', tF='C:\cb\testforum\main.cpp', tStart=9, tEnd=12, line=5 (size_t)line=5
FindCurrentFunctionStart() (Next) Iteration...
FindCurrentFunctionStart() Iterating: tN='int abc(int aaaaa)', tF='C:\cb\testforum\main.cpp', tStart=2, tEnd=7
FindCurrentFunctionStart() Current function: 'int abc(int aaaaa)' (at line 1)
FindCurrentFunctionStart() Namespace='', proc='abc' (returning 20)
ParseLocalBlock() Block:


    int bb;
    aa
ParseLocalBlock() Local tokens:
ParseLocalBlock() + int bb parent =
AI() AI enter, actual_search: "    aa"
AI() =========================================================

So, I will check why the function parameters were not added.....
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 17, 2010, 02:14:25 pm
Code
#include <iostream>
#include <map>
#include <string>

int main()
{
    typedef std::map<int, std::string> TestMap;
    TestMap testMap;
//    testMap. // not work!

    std::map<int, std::string> m;
    m.insert(1, "Hello World!"); // work fine.
    return 0;
}

@Loaden
you can not typedef something in the function body.The reason is not clear for me,maybe ollydbg or morten can release some answers. :D
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 17, 2010, 02:30:35 pm
Quite strange. See the function below:
Code
// Here, we collect the "using namespace XXXX" directives
// Also, we locate the current caret in which function, then, add the function parameters to Token trie
// Also, the variables in the function body( local block ) was add to the Token trie
size_t NativeParser::MarkItemsByAI(TokenIdxSet& result, bool reallyUseAI, bool noPartialMatch, bool caseSensitive, int caretPos)
{

    if (s_DebugSmartSense)
        Manager::Get()->GetLogManager()->DebugLog(F(_T("MarkItemsByAI()")));

    result.clear();

    cbEditor* ed = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
    if (!ed)
        return 0;

    if (!m_Parser.Done())
        Manager::Get()->GetLogManager()->DebugLog(_T("C++ Parser is still parsing files..."));
    else
    {
        // remove old temporaries
        m_Parser.GetTokens()->FreeTemporaries();
        m_Parser.GetTempTokens()->Clear();

        // find "using namespace" directives in the file
        TokenIdxSet search_scope;
        ParseUsingNamespace(ed, search_scope, caretPos);

        // parse function's arguments
        ParseFunctionArguments(ed, caretPos);

        // parse current code block (from the start of function up to the cursor)
        ParseLocalBlock(ed, caretPos);

        if (!reallyUseAI)
        {
            // all tokens, no AI whatsoever
            TokensTree* tokens = m_Parser.GetTokens();
            for (size_t i = 0; i < tokens->size(); ++i)
                result.insert(i);
            return result.size();
        }
        // we have correctly collected all the tokens, so we will do the artificial intelligence search
        return AI(result, ed, wxEmptyString, noPartialMatch, caseSensitive, &search_scope, caretPos);
    }
    return 0;
}

So, the
Code
ParseFunctionArguments(ed, caretPos);
should be called. But see in the ParseFunctionArguments body, there is a log out put :

Code
bool NativeParser::ParseFunctionArguments(cbEditor* ed, int caretPos)
{
    if (!ed)
        return false;

    if (m_Parser.Done())
        return false;

    if (s_DebugSmartSense)
        Manager::Get()->GetLogManager()->DebugLog(_T("ParseFunctionArguments() Parse function arguments"));

    TokenIdxSet proc_result;
    if (FindCurrentFunctionToken(ed, proc_result, caretPos) != 0)
    {
        for (TokenIdxSet

But I can't see any text about "ParseFunctionArguments() Parse function arguments" in the debug log output.... Why?
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 17, 2010, 02:33:43 pm
hi,guys.
I found the bug
in the ParseFunctionArguments
should be so
Code
    if (!m_Parser.Done())
        return false;

not so.

Code
    if (m_Parser.Done())
        return false;
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 17, 2010, 02:36:07 pm
hi,guys.
I found the bug
in the ParseFunctionArguments
should be so
Code
    if (!m_Parser.Done())
        return false;

not so.

Code
    if (m_Parser.Done())
        return false;

Great! Why the "!" is missing........It seems we haven't change this function.

Edit:

It is a typo in rev 6058. :D
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 17, 2010, 02:46:44 pm
Great! Why the "!" is missing........It seems we haven't change this function.
My fault. I was removing the artifacts from the past where there used to be a parser per project. So I changed all references to "per project parser" to the global none and obviously missed the !" there. Sorry. Will fix asap...
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: Loaden on January 17, 2010, 04:14:22 pm
Code
#include <iostream>
#include <map>
#include <string>

int main()
{
    typedef std::map<int, std::string> TestMap;
    TestMap testMap;
//    testMap. // not work!

    std::map<int, std::string> m;
    m.insert(1, "Hello World!"); // work fine.
    return 0;
}

@Loaden
you can not typedef something in the function body.The reason is not clear for me,maybe ollydbg or morten can release some answers. :D
Code
#include <iostream>
#include <map>
#include <string>

typedef std::map<int, std::string> TestMap;

class A
{
public:
    void Test()
    {
        TestMap2 t2;
        t2.in // works here too.
    }
   
private:
    typedef std::map<int, std::string> TestMap2;
}

int main()
{
    TestMap testMap;
    testMap.i // ok, work now.
    return 0;
}


[attachment deleted by admin]
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: Loaden on January 17, 2010, 04:32:08 pm
New bug:
Code
#include <iostream>

int main()
{
    // std::cou // not work!
    std::endl // work here.
    return 0;
}

[attachment deleted by admin]
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: Loaden on January 17, 2010, 04:40:38 pm
There's a small problem.


[attachment deleted by admin]
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 17, 2010, 07:22:00 pm
There's a small problem.
That's not a problem, that's by design.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 18, 2010, 03:06:52 am
Quote
#include <iostream>

int main()
{
    // std::cou // not work!
    std::endl // work here.
    return 0;
}


where is the definition of std::cout???
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 18, 2010, 06:31:28 am
where is the definition of std::cout???
Directly in iostream:
Code
  extern istream cin;		///< Linked to standard input
  extern ostream cout; ///< Linked to standard output
  extern ostream cerr; ///< Linked to standard error (unbuffered)
  extern ostream clog; ///< Linked to standard error (buffered)
And yes: It's "gone". ?!
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 18, 2010, 06:55:36 am
In my opinion: In the parserThread DoParse function, when it meet the "extern" keyword, the parser just skip to the the ";".
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 18, 2010, 08:07:41 am
In my opinion: In the parserThread DoParse function, when it meet the "extern" keyword, the parser just skip to the the ";".

right.that is why I ask where is the real definition.if it is just so,we need to  do some handle about extern.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 18, 2010, 08:10:58 am
In my opinion: In the parserThread DoParse function, when it meet the "extern" keyword, the parser just skip to the the ";".
No, the code is question is as follows:
Code
        else if (token==ParserConsts::kw_extern)
        {
            // check for "C"
            m_Str = m_Tokenizer.GetToken();
            if (m_Str==ParserConsts::kw_C)
            {
                m_Tokenizer.GetToken(); // "eat" {
                DoParse(); // time for recursion ;)
            }
            else
            {
                // do nothing, just skip keyword "extern", otherwise uncomment:
                //SkipToOneOfChars(ParserConsts::semicolon); // skip externs
            }
            m_Str.Clear();
        }
As you see: Really only "extern" is skipped, the rest is parsed as usual.
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 18, 2010, 08:47:20 am
Code
            m_Str = m_Tokenizer.GetToken();
            if (m_Str==ParserConsts::kw_C)
            {
                m_Tokenizer.GetToken(); // "eat" {
                DoParse(); // time for recursion ;)
            }
            else
            {
                // do nothing, just skip keyword "extern", otherwise uncomment:
                //SkipToOneOfChars(ParserConsts::semicolon); // skip externs
            }
            m_Str.Clear();

it seems I get the reason.

e.g. extern int aa;

when we do this.
Code
m_Str = m_Tokenizer.GetToken();

now the m_Str is int.


but here we clear the m_Str again.
Code
m_Str.Clear();

so the m_Str is empty.I think this is why the cout can not be parsed correctly.

solution :

comment this statement may work.

Code
//m_Str.Clear();
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 18, 2010, 09:00:15 am
New bug:
Code
#include <iostream>

int main()
{
    // std::cou // not work!
    std::endl // work here.
    return 0;
}


patch for it.

Code
Index: src/plugins/codecompletion/parser/parserthread.cpp
===================================================================
--- src/plugins/codecompletion/parser/parserthread.cpp (revision 6089)
+++ src/plugins/codecompletion/parser/parserthread.cpp (working copy)
@@ -524,7 +524,7 @@
         else if (token==ParserConsts::kw_extern)
         {
             // check for "C"
-            m_Str = m_Tokenizer.GetToken();
+            m_Str = m_Tokenizer.PeekToken();
             if (m_Str==ParserConsts::kw_C)
             {
                 m_Tokenizer.GetToken(); // "eat" {

see the screen shot.



[attachment deleted by admin]
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 18, 2010, 09:04:11 am
patch for it.
Code
Index: src/plugins/codecompletion/parser/parserthread.cpp
             // check for "C"
-            m_Str = m_Tokenizer.GetToken();
+            m_Str = m_Tokenizer.PeekToken();
             if (m_Str==ParserConsts::kw_C)
             {
                 m_Tokenizer.GetToken(); // "eat" {
Be careful: In that case not the "{" is "eaten" in the case of extern C {...} statements, but the "C". So your patch will work for the extern cout thing, but will break extern C {...}.
This maybe corrected by issuing "m_Tokenizer.GetToken();" twice in the if clause, the fiorst time for "C", the second time for the "{".
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 18, 2010, 09:09:13 am
hi,morten:
what about this way.
Code
Index: src/plugins/codecompletion/parser/parserthread.cpp
===================================================================
--- src/plugins/codecompletion/parser/parserthread.cpp (revision 6089)
+++ src/plugins/codecompletion/parser/parserthread.cpp (working copy)
@@ -534,6 +534,7 @@
             {
                 // do nothing, just skip keyword "extern", otherwise uncomment:
                 //SkipToOneOfChars(ParserConsts::semicolon); // skip externs
+                m_Tokenizer.UngetToken();
             }
             m_Str.Clear();
         }
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: Loaden on January 18, 2010, 09:23:21 am
hi,morten:
what about this way.
Code
Index: src/plugins/codecompletion/parser/parserthread.cpp
===================================================================
--- src/plugins/codecompletion/parser/parserthread.cpp (revision 6089)
+++ src/plugins/codecompletion/parser/parserthread.cpp (working copy)
@@ -534,6 +534,7 @@
             {
                 // do nothing, just skip keyword "extern", otherwise uncomment:
                 //SkipToOneOfChars(ParserConsts::semicolon); // skip externs
+                m_Tokenizer.UngetToken();
             }
             m_Str.Clear();
         }
Work now! :P
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 18, 2010, 09:47:40 am
what about this way.
...I'll try.

BTW: I was in fact thinking about having another flag for the token to declare it as "extern" (similar to m_IsConst). This would help to e.g. overwrite the "content" in the case you find the true definition / implementation. In addition the tooltip could show "extern" if only the "extern" declaration is found, indicating that the implementation might not be known (as it is in a binary library, for example).
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: ollydbg on January 18, 2010, 09:55:24 am
what about this way.
...I'll try.

BTW: I was in fact thinking about having another flag for the token to declare it as "extern" (similar to m_IsConst). This would help to e.g. overwrite the "content" in the case you find the true definition / implementation. In addition the tooltip could show "extern" if only the "extern" declaration is found, indicating that the implementation might not be known (as it is in a binary library, for example).
Good idea! But it seems there are too many bool variables in the Token class.
Code
    bool          m_IsOperator;
        bool          m_IsLocal;       // found in a local file?
        bool          m_IsTemp;        // if true, the tree deletes it in FreeTemporaries()
        bool          m_IsConst;       // the member method is const (yes/no)

As we build the C::B in the "debug" mode, then strip the debug information. I think one bool variable occupy 4 BYTE in the memory.
I'm not sure a enum variable(combine all the state in one variable) is better??
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: sbezgodov on January 18, 2010, 10:50:50 am
I have deleted cb configuration files. Next run cb creates these files with default values.
I've noticed that tokens replacement list is extended. See attacment.

std::string s1; s1. now works fine

As i understand, if you patched your installation to latest nighty, configuration files are not patched at first run.


[attachment deleted by admin]
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: blueshake on January 18, 2010, 11:02:08 am
I have deleted cb configuration files. Next run cb creates these files with default values.
I've noticed that tokens replacement list is extended. See attacment.

std::string s1; s1. now works fine

As i understand, if you patched your installation to latest nighty, configuration files are not patched at first run.


work fine here.Make sure that you have include the string file. :D
see my attachment.

[attachment deleted by admin]
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: Loaden on January 18, 2010, 11:24:56 am
I have deleted cb configuration files. Next run cb creates these files with default values.
I've noticed that tokens replacement list is extended. See attacment.

std::string s1; s1. now works fine

As i understand, if you patched your installation to latest nighty, configuration files are not patched at first run.

Yes, you need edit the "default.conf" file, and add the replacement rules.
Code
		<TOKEN_REPLACEMENTS>
<ssmap>
<_GLIBCXX_BEGIN_NAMESPACE>
<![CDATA[+namespace]]>
</_GLIBCXX_BEGIN_NAMESPACE>
<_GLIBCXX_BEGIN_NAMESPACE_TR1>
<![CDATA[-namespace tr1 {]]>
</_GLIBCXX_BEGIN_NAMESPACE_TR1>
<_GLIBCXX_BEGIN_NESTED_NAMESPACE>
<![CDATA[+namespace]]>
</_GLIBCXX_BEGIN_NESTED_NAMESPACE>
<_GLIBCXX_END_NAMESPACE>
<![CDATA[}]]>
</_GLIBCXX_END_NAMESPACE>
<_GLIBCXX_END_NAMESPACE_TR1>
<![CDATA[}]]>
</_GLIBCXX_END_NAMESPACE_TR1>
<_GLIBCXX_END_NESTED_NAMESPACE>
<![CDATA[}]]>
</_GLIBCXX_END_NESTED_NAMESPACE>
<_GLIBCXX_STD>
<![CDATA[std]]>
</_GLIBCXX_STD>
</ssmap>
</TOKEN_REPLACEMENTS>
Title: Re: vector<int> is OK, but string or wstring no-work.
Post by: MortenMacFly on January 18, 2010, 01:51:23 pm
I'm not sure a enum variable(combine all the state in one variable) is better??
In terms of memory footprint: yes. In terms of logic: the boolean field have nothing in common really. So combining them logically makes no sense. So a default enum would be enough.