Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign

Regular expressions

<< < (3/15) > >>

JGM:
I have been reading some c++ books, and on each one I encounter a new feature of the language that I didn't know. I have to admit that I'm an amateur on c++, it has so many features that the language is pluginable, some things on the language have so many definitions or uses.  :?

I see why there are little software alternatives to accomplish code completion. Making an intelligent c++ parser would take a significant amount of time (maybe years).

stevenkaras:
I've always said when in doubt, check the source. In this case, the best source is the ARM:
http://www.research.att.com/~bs/arm.html

and after that, that Bjarne book(my own name):
http://www.research.att.com/~bs/3rd.html
http://en.wikipedia.org/wiki/The_C%2B%2B_Programming_Language

As for my opinions about ctags: I've tried using ctags in the past, and failed spectacularly. Not really sure why, but I've had an instinctual dislike of the package since then. But perhaps we can steal the core of it, and then just update that, rather than using an external program. Also, when we internalize it, we take control about when it can reparse the project.

In any case, I'd like to see some documentation put here about how the code completion works now, so we can perhaps improve upon it. If not, at least discuss how code completion works, rather than everyone just saying: "let's use regex!" or "it should look like visual assistant x!"

JGM:

--- Quote from: stevenkaras on February 20, 2008, 01:26:00 am ---rather than everyone just saying: "let's use regex!" or "it should look like visual assistant x!"

--- End quote ---

Don't listen to us we are just a bunch of frustrated programmers that can't make a decent auto completion plugin  :lol: (talking for my self)

By the way as I know the code completion plug in is going to be redesigned ( a new and better one). Theres already people working on it (or at least a library). Also you are welcome to develop one that may take place on a future contest I guess  :wink:.

stevenkaras:
I suppose what I'm trying to say is I think seeing some more discussion on how code completion actually works would create results faster than simple suggestions, and telling everyone: "Work alone". This is a group project, where everyone takes part. Not a project where one person puts together a whole bunch of other people's work. I'm not saying that working alone is bad (i prefer it myself), but on a complicated problem such as this, the design stages should be done in a public forum.

So, how does code completion work? Rather than throw around buzzwords and feature names, let's talk about what we actually want it to do:
Provide, in an automatic/seamless way, all possible/likely solutions to "complete" the current identifier.

1. To do so, you need to have a list of all the identifiers in the current scope. (That last sentence was important).
2. Then, reduce the list to what already begins with what has been typed.
3. Show that list to the user
4. If the user wants to, he can select the proper solution from that list, and press enter/tab to insert the solution.

Let me know if you have a correction/suggestion. I'll think about how to break down the problem further, and add that on.

Edit:

I've put some more thought into the problem. As for getting the list of identifiers, the problem is threefold. You need to generate 3 lists. The first list should contain global identifiers with external linkage in the current target(a stumbling block, as I see it). The second list should contain global identifiers with internal linkage, and the last list should contain all the local scope identifiers. A couple of solutions:

1. Keep 2 lists on hand for each file. One is external linkage, the other is internal linkage. Generate the list needed by merging all the lists for the current target on demand.
2. Keep a list on hand for each target (storing external linkage only). Generate the internal linkage list on the fly.

In any case, the local scope list should be generated on demand (it shouldn't take that much time, and makes the plugin more useful).

There are a few potential problems, as I see it:

1. What happens when the current scope is global?
2. What happens in an unbalanced block? (say I'm writing a function and forgot a brace...)
3. What should the data format be?

byo:

--- Quote from: stevenkaras on February 26, 2008, 11:50:13 am ---Provide, in an automatic/seamless way, all possible/likely solutions to "complete" the current identifier.

--- End quote ---

That's only one thing. To make really good code-completion you will also have to:

* Provide call tips while writing function-call function (maybe with some documentation gathered from comments)
* Provide reliable list of include files when user type  #include macro
* Help with coding initializer lists on constructors
* and probably much more
Additionally current implementation also does few more things like:

* Providing class browser
* Providing "goto declaration/definition" stuff
* Detecting current scope we're in
Ok, now we can not find all identifiers in current scope. Why? Because in c++ we always include global namespace which contains really huge amount of symbols so even enumerating them may be a problem. Also we can not only take symbols from one scope - for example when we're in member function of class we must look in local variables of this function, members of the class, all members of base classes, global namespaces and all namespaces included through "using" keyword - so it's not so simple.

It even looks worse when dealing with templates - let's take an example:


--- Code: ---teplate<typename T> class Template
{
    public:
        T& GetInstance() { return m_Instance; }
    private:
        T m_Instance;
};

class Parameter
{
    public:
        void PrintfText() { printf("Text"); }
};

int main(int,char**)
{
    Template<Parameter> Object;
   
    Object.GetInstance().Printf <<<<< What to complete here ?
}

--- End code ---

In this example we don't only need to know that Object has function named GetInstance. If we detect what this function returns we see that this is template parameter - so such lists also have to be accessible from somwhere. And believe me - stl, boost and other modern libraries won't easily work without it.


Now to do the completion really good we can't overcome the problem of parsing most of the code in include files. Of course it don't require full parsing but to have accurate results we can only skip bodies of functions, everything else must be parsed as in standard c++ parser. But since we need to parse current context while completing the code, body of function we're in must be parsed then (so this shows that really good code-completion is in fact full c++ parser).

We can cache result of parsing include files (of course there are exceptions for this but they're rare) and we can quickly parse current file (when skipping function bodies) so the performance should be acceptable.

I thought lately about the cc plugin and how to improve it becuase the current implemetnation is not good enough for me (I started to really love templates and cc fails in this area) so maybe I could help too. But I think that maybe we shoudn't start any huge changes before the release (so it's not so long ;) ) and we should focus on the release right now.

But just one suggestion which should be considered before starting the change (I already written about this some time ago but it was long time ago so I don't even remember where I wrote this ;) ).

I think that current cc plugin should be splitted into three parts:

* Parser plugin (or maybe language-support plugin) - this one will be responsible for parsing files / detecting completion context etc. etc. - mainly analysing source code and changes made to them. I also thought about adding possibility to define own lexers and fold detectors for scintilla editor here - and I can say that I already have this part done
* Code-completion plugin - here we could leave all things related to managing threads / gui updates etc
 
* Parser manager - which would provide some bridge between those two (maybe more) plugins - it would manage parser plugins (for example give proper parser for given language) and it could provide some interface used to access symbols.
If parser manager and interfaces for accessing symbols will be really good designed, we can separate parsing from completion in most of areas.

Regards

   BYO

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version