Code::Blocks Forums

Hi,

I like using the foreach statement in c++, provided with the c++11 standard:


list<string> strList;
for(string &str : strList)
{
cout << str << endl;
}


But now my problem is, that, in the for block, the variable "str" is unknown by the code completion, which can be quite annoying/confusing.

Is there anything that can be done to resolve this problem?

edit: I'm using the latest nightly build.

Thanks!

Koonschi

Quote from: koonschi on October 04, 2012, 11:40:39 AM
Is there anything that can be done to resolve this problem?

Make a patch that implements this feature.

this is not purely a problem with the range based for loop, it is a problem with every declaration in the for(;;) construct, also in declarations in if() construct  [I am not talking about the bodies/blocks of the for/if]


if(TxmlElement* problem = handle.FirstChildElement("test"))
{
  /// ---> will not code complete on 'problem'
}


oBFusCATed: Sounds good. How exactly would that work?

Here is the code for the latest revision of C::B: http://svn.berlios.de/wsvn/codeblocks/trunk/?rev=8431&peg=8431#a0b40758157c8f16fa703ca3be466fa8a
Go browse it, study it, find where it must be modified, modify it, test the modification, read this http://wiki.codeblocks.org/index.php?title=Creating_a_patch_to_submit_to_BerliOS_%28Patch_Tracker%29 , create a patch, submit to berlios, fix reported bugs.

I hope, I've not missed any of the required steps.  ::)

Alright, it seems like it's done .. Is there something like a testing framework or similar where I could add/get some test cases?
I tested multiple cases, seems to be alright though ..
So should I just submit it?

Quote from: koonschi on October 06, 2012, 04:24:55 PM
Alright, it seems like it's done ..

Good work.

QuoteIs there something like a testing framework or similar where I could add/get some test cases?

There is a testing project called "cctest.cbp", its under "trunk\src\plugins\codecompletion", you can build this project, then run the app. (The app will open the file "test.h", and parse it, you can see the log of parserthread or other classes), I think we can use some kind of testing framework like cpp-unit-test in the future.

Quote
I tested multiple cases, seems to be alright though ..
So should I just submit it?

Go ahead. Thanks.

Alright, uploaded it :)

Quote from: koonschi on October 06, 2012, 05:41:41 PM
Alright, uploaded it :)

Good work, I'm testing your patchAdded code completion of declarations in for/if/while heads (https://developer.berlios.de/patch/?func=detailpatch&patch_id=3345&group_id=5358), Thanks.

Some comments:
1, RemoveTemplateArgs is missing in header file, comments needed for this function.
2,    // for loop heads look like this:
   // ([init1 [, init2 ...] ] ; [cond1 [, cond2 ..]], [mod1 [, mod2 ..]])
should have the second ";" instead of ",".

BTW: It is the first time I see you use another instance (smallTokenizer) of Tokenizer class in Parserthread.  :)

Quote from: ollydbg on October 09, 2012, 02:02:11 AM
Good work, I'm testing your patchAdded code completion of declarations in for/if/while heads (https://developer.berlios.de/patch/?func=detailpatch&patch_id=3345&group_id=5358), Thanks.

Feel free to take over, btw...

Quote from: ollydbg on October 09, 2012, 04:39:24 AM
1, RemoveTemplateArgs is missing in header file, comments needed for this function.

I'm confused, I just checked and I thought it was in the patch though? At least if I look at the raw patch file it is all at the bottom ...

Quote from: ollydbg on October 09, 2012, 04:39:24 AM
Some comments:
2,

Code Select Expand

    // for loop heads look like this:
    // ([init1 [, init2 ...] ] ; [cond1 [, cond2 ..]], [mod1 [, mod2 ..]])
should have the second ";" instead of ",".

Oops, you're absolutely right, I will change that asap.

Quote from: ollydbg on October 09, 2012, 04:39:24 AM
BTW: It is the first time I see you use another instance (smallTokenizer) of Tokenizer class in Parserthread.  :)

Well, it is the first time that I contribute to Code::Blocks, too :) I hope I did not break any rules by using it.
It seemed like the easiest thing to do though, as the expressions in parentheses are parsed as one single token. I did not want to mess around with that, as it's used for function parameters, too.

Corrected patch is online. RemoveTemplateArgs + comments should be in there, too.

Here is my test code:

void f()
{
if(TxmlElement* problem = handle.FirstChildElement("test"))
{
  /// ---> will not code complete on 'problem'
     problem;
}

}


void f2()
{
if(TxmlElement* problem1 = handle.FirstChildElement("test"))
{
  /// ---> will not code complete on 'problem'
   problem1;
}
}


And I see the patch works very nice. I right click on "problem", and select find declaration, it goes to the correct position.
When I click on the "problem1", I see the temp Token "problem" is cleared, and new temp Token "problem1" is created.
Nice work, koonschi.

Quote
Well, it is the first time that I contribute to Code::Blocks, too Smiley I hope I did not break any rules by using it.
It seemed like the easiest thing to do though, as the expressions in parentheses are parsed as one single token. I did not want to mess around with that, as it's used for function parameters, too.

I hope this is the beginning of your contribution to C::B, welcome!!!!
It dose not break any rules. I have no objection to use another instance of Tokenizer class in Parserthread class.

Besize that, we have a function in Parserthread
bool ParserThread::GetBaseArgs(const wxString & args, wxString& baseArgs)
which translate a complex full function arguments to a simple arguments like:
void f(int a=1, float *p=0x777);

here, (int a=1, float *p=0x777) will be translated to (int a, float *p), I think here we also need a smallTokenizer. :), because sometimes, there are nested "()" in the function arguments, currently implementation of GetBaseArgs() does not work correctly about those nest parentheses.

Bug comes in the function: void ParserThread::HandleConditionalArguments()

Suppose I have a if condition below:


if(aaaaa>bbbbb && ccccc<ddddd)

When parsing, it will add a temporary token with the information below:

[debug]{m_FullType = "aaaaa&&", m_BaseType = "aaaaa", m_Name = "<", m_Args = "", m_BaseArgs = "", m_AncestorsString = "", m_FileIdx = 1, m_Line = 17, m_ImplFileIdx = 0, m_ImplLine = 0, m_ImplLineStart = 0, m_ImplLineEnd = 0, m_Scope = tsUndefined, m_TokenKind = tkVariable, m_IsOperator = false, m_IsLocal = false, m_IsTemp = true, m_IsConst = 186, m_Index = 501, m_ParentIndex = 500
[debug], m_Children = std::set with 0 elements, m_Ancestors = std::set with 0 elements, m_DirectAncestors = std::set with 0 elements, m_Descendants = std::set with 0 elements, m_Aliases = 0 count of wxArrayString, m_TemplateArgument = "", m_TemplateType = 0 count of wxArrayString, m_TemplateMap = std::map with 0 elements, m_TemplateAlias = "", m_UserData = 0x0, m_TokenTree = 0x3d31270, m_Ticket = 786}>>>>>>cb_gdb:


You see: m_Name is "<".

I think the logic to find a variable:

   if (peek.empty())
        {
            if (!m_Str.empty())
            {
             .....
                Token *newToken = DoAddToken(tkVariable, token, smallTokenizer.GetLineNumber());


Here, if peek is empty, and m_Str have some characters, but the token is "logic compare operators".

Ah, I was afraid something like that would happen. I will look into it.