Another code completion problem

[zabzonk]

I have a problem with nightly 7289 on Windows 7. For this code:

#include <string>
using namespace std;

int main()
{
     string s;
}

code completion on s works perfectly. Whereas for this code:

#include <string>
using std::string;

int main()
{
     string s;
}

code completion on s does not work at all. Is this a known issue? I did try searching for it, but there are a hell of a lot of posts about completion.
 

[ollydbg]

Whereas for this code:
#include <string>
using std::string;

int main()
{
     string s;
}

code completion on s does not work at all. Is this a known issue?

Yes, this is an issue, and it is an issue exists for a long time.
But I think it is hard to solve this issue. There is no easy way to solve this issue. But I would think that when the parser see:

Code

using std::string;

it would add "namespace std" scope instead. but this is only a workaround, because all the other classes under "std" will be added to the context. any comments?

[zabzonk]

Well, that's really unfortunate, because it makes CB uncompetitive with VC++, at least in this area. Both code samples do work correctly in VC++ 2010, and it seems not to use the "include entire namespace hack" you suggest. That means that the problem is soluble, and I think it is an important one. I recommend CB very strongly in all my posts and blogging about C++, but if a major language feature like this is not supported, I may have to tone this down :-( Well, at least CB's FOSS competitor CodeLite doesn't seem to get it right either...

[ollydbg]

I may have to tone this down :-( Well, at least CB's FOSS competitor CodeLite doesn't seem to get it right either...

what does this sentence means? did you say the same problem exists in Codelite or Not?
BTW: codelite has some extra feature to list the code suggestion. (in fact, it has its own code suggestion mechanism and also a clang supported mechanism).

[zabzonk]

> what does this sentence means?

I mean that CodeLite appears to have the same problem that CB does - a

using std::string;

does not allow for code completion on string variables, but

using namespace std;

does.

[ollydbg]

> what does this sentence means?

I mean that CodeLite appears to have the same problem that CB does - a

using std::string;

does not allow for code completion on string variables, but

using namespace std;

does.

Ok, I see.
The fact that this feature is quite complex to implement is that it need symbol scope lookup in the context in the parser.  our Codecompletion plugin's parser has not implemented this. It is hard to build a full c++ parser.

[zabzonk]

I fully appreciate the difficulty, but real C++ code uses this feature a lot, and if it is not supported I think CB uptake will gradually fall off, as people seem to be using namespaces (or using libraries that require the use of namespaces) more and more..

While I'm at it, there is actually what I take to be an associated problem with the symbols browser. Given this code:

#include <string>

struct A {
   void f( std::string );
};

using namespace std;

void A :: f( string ) {
}

The symbols browser shows two different functions called f when surely it should only show one.

[eranif]

> what does this sentence means?

I mean that CodeLite appears to have the same problem that CB does - a

using std::string;

does not allow for code completion on string variables, but

using namespace std;

does.

Since you mentioned it, I need to correct you: if you enables codelite's clang support - the above sample works as expected
 (only available in trunk version of codelite)
I too feels that writing a full blown c++ parser is just too much, so I took the path of clang as a "completion" for the built-in parser that I already have in codelite (I think that C::B should do the same)

Eran

[ollydbg]

I too feels that writing a full blown c++ parser is just too much.

I totally agree on this. writing a full c++ parser is tooooo much.

so I took the path of clang as a "completion" for the built-in parser that I already have in codelite (I think that C::B should do the same)
Eran

Some days ago, I tested the clang completion(in command line or link to libclang library), and it works fine.
Hope it was not much work to use clang in C::B.

[eranif]

Hope it was not much work to use clang in C::B.

The basics works fine.

But when I started trying playing with it responded very slow on large files with many include files
The key was to implement the caching for clang using an automated mechanism of PCH creation by stripping the include files from a source file and generate a dummy header file which will be used as our PCH file. The generated PCH is then "injected" to the command line by the -include switch.

Another thing to put it mind is to implement a mechanism that will invalidate the cache (some entries) when needed (e.g. new header file was added to the source file)
If you need assist, please free to email me or start a new thread about it.

Eran

[MortenMacFly]

If you need assist, please free to email me or start a new thread about it.

Which reminds me, Eran:

We had in mind to "join forces" by trying to attach the CC codecompletion (stand-alone) library into Code::Blocks. I once tried and I have a few stubs available, but I simply don't have the time and meanwhile I'm afraid the interface to CodeLite's CC and C::B's CC has changed.

So - if anybody is willing to write a CC wrapper for Code::Blocks based on Eran's work - step forward. I think Eran did nice job concerning the separation of concerns, so it can really be seen as a stand-alone framework where we just need to match C::B's CC interface to the one of Erans.

However, as long as there is no measurement/guess about the effort our own CC has higher priority. In the end for my (and probably only my) purposes it works really well, in fact I rarely miss any information/feature.

[ollydbg]

We had in mind to "join forces" by trying to attach the CC codecompletion (stand-alone) library into Code::Blocks. I once tried and I have a few stubs available.

There are some discussion about porting Codelite's SQLite dabase and other stuff to Codeblocks, but finally no one start doing that, because it was complex.

Hope it was not much work to use clang in C::B.

The basics works fine.

But when I started trying playing with it responded very slow on large files with many include files
The key was to implement the caching for clang using an automated mechanism of PCH creation by stripping the include files from a source file and generate a dummy header file which will be used as our PCH file. The generated PCH is then "injected" to the command line by the -include switch.

Another thing to put it mind is to implement a mechanism that will invalidate the cache (some entries) when needed (e.g. new header file was added to the source file)
If you need assist, please free to email me or start a new thread about it.

Eran

Thanks, you're so kind. My current work give me about one hour more or less to doing some C::B related work, so I'm not have much time to implement this right now.