Bug?

[daniloz]

Hi!

I found that when defining a temporary variable with the same name several consecutive times, the tooltip for the variable gets duplicated, triplicated and so on... (see screenshots)

Here is a sample code to reproduce it...

Code

void main(void)
{
	for (int i=0; i<10; i++)
	{
		float ff = 0;
		ff = ff + i;
	}

	for (int i=0; i<10; i++)
	{
		float ff = 0;
		ff = ff + i;
	}

	for (int i=0; i<10; i++)
	{
		float ff = 0;
		ff = ff + i;
	}
}

Is this a bug in the CC? Can it be easily fixed?

Thx!

[ollydbg]

confirmed!

yes, it was definitely a bug in CC. This bug was due to the parser in CC does not treat the "scope" information correctly.

Say:

Code

void main(void)
{
	for (int i=0; i<10; i++)
	{
		float ff = 0;                 // place one
		ff = ff + i;
	}                                       // place two

	for (int i=0; i<10; i++)
	{
		float ff = 0;                 // place three
		ff = ff + i;                   // place four
	}
....

for example, the code above, your caret was put in the "place four", what cc's parser do was :

1, locate which function body your caret in. OK, it find it's location in "main()"
2, next, the parser try to parse the function body from the { to the current caret, and collect all the local variables.  if it meet a for statement, it will just "dig into" its body (because the parser has no idea whether your currently caret position was in the "for body" or not.
3, when the parser meet "place one", he just add the variable "ff" as a member of the "main()".
4, even it step out of the for body and step into the "place three", he will recognize another variable "ff" and added again as a child of "main()"

That's way you see the wrong tip.

To solve this. I'm not sure it was easy?? the Scope information is quite complex in the C++ language. a lot of directive can introduce a scope, like

using namespace directive
using directive
....

So, a full C++ parser framework(I'd like to say, currently Clang) can solve all the problem.

[daniloz]

@ollydbg:

Thanks for the fast (and precise) response... I understand the difficulty of it. Anyway, this is not at all preventing me from using C::B, i really love it! ;-)

So, a full C++ parser framework(I'd like to say, currently Clang) can solve all the problem.

I can see the advantages of using clang and it really seems to be very powerful. HOWEVER, in my case, I do embedded (DSP) programming and I use a proprietary C++ compiler. Is clang still be able to parse all my code? Because, gcc or any other compiler can actually compile my code... and it seems clang do more than just parsing but also compilation. Is that correct?

[ollydbg]

@ollydbg:

Thanks for the fast (and precise) response... I understand the difficulty of it. Anyway, this is not at all preventing me from using C::B, i really love it! ;-)

Nice to hear, I love C::B too!!!

So, a full C++ parser framework(I'd like to say, currently Clang) can solve all the problem.

I can see the advantages of using clang and it really seems to be very powerful. HOWEVER, in my case, I do embedded (DSP) programming and I use a proprietary C++ compiler. Is clang still be able to parse all my code? Because, gcc or any other compiler can actually compile my code... and it seems clang do more than just parsing but also compilation. Is that correct?

sure, if you code can be compiled by gcc, then the code can definitely compiled(parsed) by clang.  
1, clang is a c language family compiler frond end, so the major job was parsing the code and generate some intermediate level code to the llvm, then llvm can do some optimization and do some target related code generation thing

2, clang currently I think is quite capable to parse c/c++ source files. (although a small c++0x feature was not finished compared with gcc)

3, clang supply a strong library to support IDE, we can do code index, code completion, code rewrite(re-factor), and now it has a very minimal c interface called libclang.

4, currently, clang is now supported to do codecompletion in vim, see:
https://github.com/Rip-Rip/clang_complete/wiki
and emace:
see:
http://mike.struct.cn/blogs/entry/15/
Also, the apple's Xcode IDE has use libclang to do codecompletion and other things.

5, as in your situation, clang is just serve as a compiler front end, and it was enough, you can still use your proprietary c++ compiler to build your DSP program.

[daniloz]

Sorry, there was a typo in my post, actually my code CANNOT "be compiled by or any other compiler".

That's why I'm concerned if clang is still work in my case?

[ollydbg]

Sorry, there was a typo in my post, actually my code CANNOT "be compiled by or any other compiler".

That's why I'm concerned if clang is still work in my case?

sure, I believe that clang can still used to parse your project.