Code::Blocks
September 02, 2014, 03:46:54 am *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Don't forget to check the Nightly builds in the appropriate forum.
 
   Home   Help Search Login Register  :: WebsiteWiki  
Pages: [1]   Go Down
  Send this topic  |  Print  
Author Topic: Another code completion problem  (Read 2387 times)
zabzonk
Guest
« on: August 13, 2011, 05:49:16 pm »

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.
 
« Last Edit: August 13, 2011, 08:47:46 pm by Neil Butterworth » Logged
ollydbg
Developer
Lives here!
*****
Offline Offline

Posts: 4020


Interests on OpenCV and Robotics


WWW
« Reply #1 on: August 14, 2011, 03:08:22 am »

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?
Logged

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.
zabzonk
Guest
« Reply #2 on: August 14, 2011, 09:14:58 am »

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...
Logged
ollydbg
Developer
Lives here!
*****
Offline Offline

Posts: 4020


Interests on OpenCV and Robotics


WWW
« Reply #3 on: August 14, 2011, 09:25:31 am »

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).
Logged

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.
zabzonk
Guest
« Reply #4 on: August 14, 2011, 09:28:42 am »

> 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.

Logged
ollydbg
Developer
Lives here!
*****
Offline Offline

Posts: 4020


Interests on OpenCV and Robotics


WWW
« Reply #5 on: August 14, 2011, 09:42:52 am »

> 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. Cheesy
Logged

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.
zabzonk
Guest
« Reply #6 on: August 14, 2011, 09:54:04 am »

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.

« Last Edit: August 14, 2011, 10:07:28 am by Neil Butterworth » Logged
eranif
Regular
***
Offline Offline

Posts: 251


« Reply #7 on: August 17, 2011, 04:42:06 pm »

> 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

Logged
ollydbg
Developer
Lives here!
*****
Offline Offline

Posts: 4020


Interests on OpenCV and Robotics


WWW
« Reply #8 on: August 17, 2011, 05:00:14 pm »

I too feels that writing a full blown c++ parser is just too much.
I totally agree on this. Cheesy writing a full c++ parser is tooooo much.

Quote
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.

Logged

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.
eranif
Regular
***
Offline Offline

Posts: 251


« Reply #9 on: August 17, 2011, 05:18:44 pm »

Quote
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
Logged
MortenMacFly
Administrator
Lives here!
*****
Offline Offline

Posts: 8635



« Reply #10 on: August 17, 2011, 05:28:33 pm »

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.
Logged

Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ
ollydbg
Developer
Lives here!
*****
Offline Offline

Posts: 4020


Interests on OpenCV and Robotics


WWW
« Reply #11 on: August 18, 2011, 08:54:31 am »

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.

Quote
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. Cheesy
Logged

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.
Pages: [1]   Go Up
  Send this topic  |  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!