Ceniza's CodeCompletion Project

[ollydbg]

@Ceniza

I examed your code a little, and found that the "can't read relative path file" problem comes from this piece of code.
In CCPP\include\ccpfsourceprovider.h start from line 115.

Code

template <class StringType, class StringFunctions>
typename CCPFSourceProvider<StringType, StringFunctions>::DataFetcherType CCPFSourceProvider<StringType, StringFunctions>::getSource(const StringType &filename, const StringType &source, bool global, unsigned int start) throw (ccp::FileNotFound<StringType>)
{
    unsigned int found_at = start;

    if (global)
    {
        typename stringVectorType::const_iterator i = m_globalPaths.begin();

        if (start >= m_globalPaths.size())
        {
            i = m_globalPaths.end();
        }
        else
        {
            std::advance(i, start);
        }

        for (; i != m_globalPaths.end(); ++i, ++found_at)
        {
            StringType path(*i);

            if (path.length() > 0 && path[path.length() - 1] != StringFunctions::dirSeparator)
            {
                path += StringFunctions::dirSeparator;
            }

            path += filename;

            if (StringFunctions::fileExists(path))
            {
                return DataFetcherType(IFStreamFileAbstr<StringType>(path), path, true, found_at);
            }
        }

        start = found_at = 0;
    }

You add the file name to the path. then check whether the file is exist.

Here is the solution in CodeCompletion source code parser.cpp line 815

Code

wxString Parser::GetFullFileName(const wxString& src,const wxString& tgt, bool isGlobal)
{
    wxCriticalSectionLocker lock(s_mutexListProtection);
    wxString fullname(_T("")); // Initialize with Empty String
    if (isGlobal)
    {
        fullname = FindFirstFileInIncludeDirs(tgt);
        if (fullname.IsEmpty())
        {
            // not found; check this case:
            //
            // we had entered the previous file like this: #include <gl/gl.h>
            // and it now does this: #include "glext.h"
            // glext.h was correctly not found above but we can now search
            // for gl/glext.h.
            // if we still not find it, it's not there. A compilation error
            // is imminent (well, almost - I guess the compiler knows a little better ;).
            wxString base = wxFileName(src).GetPath(wxPATH_GET_VOLUME | wxPATH_GET_SEPARATOR);
            fullname = FindFirstFileInIncludeDirs(base + tgt);
        }
    }
    ......

[Ceniza]

IIRC, I decided not to use one of the two methods to search for included files. I do not recall if it was global or local, though.

I think I had also added some code to deal with that situation. It was also a bit of a last minute hack. That's the reason that method receives both filename and source. That's what the while loop that follows (into that if) should do.

[ollydbg]

@Ceniza
I briefly read your pdf(English version ). I can get the conclusion of these points.

First, a memory pool is better and faster, allocate a large memory once is better and faster than allocate small chunks by several times.

Second, smart pointer is something which can avoid the reallocate memory.

Now, I'm concerning the parser, I have read the forum, someone are discussion using a general parser like:

YACC or ANTLR

So, I do a search on Google, I found that the CodeLite IDE's parser use a simplified parser generated by Lex and Yacc. I'm unsure if this parser can be used in CodeCompletion.

By the way, the performance is very important. In my computer(windows Xp, intel dualCore), Parsing the whole codeblocks's source code takes 13 seconds. But an older 2.6G computer takes 24seconds. To solve the performance problem, one solution is store the token tree in the harddisk, then load it when a project file opened.

The current code of the parsing is "hand crafted",  I do suggest we can use a more general way.
Thanks.

 

[Ceniza]

Using a general parser instead of creating a handcrafted one again would help simplify things, to some extent. It's important to know quite well the parser to be able to write all the rules while indicating how to resolve all ambiguities. Furthermore, the parser should integrate nicely with C++, and allow for multi-threading. I gave YACC a try once, and it seems to be able to do all those things, provided you use the right flags. Still, writing all the rules, solving all ambiguities the right way, and even twisting the rules, is a task that requires a lot of time and dedication.

Writing all the rules to at least be able to parse correctly all sorts of variable declarations (including templates and function/method pointers), would be a good start. Being able to store all that information is some sort of structure would be a good second step. That minimum test should be enough to get started. It is also worth mentioning that the parser should also include in the rules all those common extensions to the language, like calling convention specification.

As a personal comment, the only thing I hate about C++ is trying to parse it.

[ollydbg]

I just installed CodeLite and test it's parser. But, I found that it's parser doesn't work as well as codeblocks'.  Especially it can't automatically parser the header file, and many bugs. So, it seems a "handcrafted" parser works better then a standard general parser. . Maybe, it will more time and effort to tune a better YACC grammar rule.

What I concern mostly right now is the macros and preprocesser issue. I do expect your preprecosser could be successfully integrate to the current design to solve this issue. Although we would still use a "handcrafted" but fast parser.

[jfouche]

I just installed CodeLite and test it's parser. But, I found that it's parser doesn't work as well as codeblocks'.  Especially it can't automatically parser the header file, and many bugs.

Hi

I'm using codelite because I found that code completion was better than C::B. Can you give me your feedback about bugs you found in codelite code completion ?
FYI, all project files are parsed automatically, and you can add as many directory you want to the auto completion tool (external libs for example). If not in your case, may be a bug, or a misused of codelite.

[nanyu]

I'm using codelite because I found that code completion was better than C::B...

  me too! I use code::blocks. But I think the codelite's "code completion " was better.

[ollydbg]

@jfouche
I can write a very simple test case.

Code

#include <stdio.h>

int abcdefg;

int main(int argc, char **argv)
{
	printf("hello world\n");
	abcd*******************Here
	return 0;
}

code::blocks can give a list, see the screen shot, but Codelite gives nothing.


[attachment deleted by admin]

[jfouche]

Hi Ollydbg

For me everything is fine, just by pressing CTRL-SPACE.
More over, I would like to say that I love c::b, and I'm always reading the forum, looking for interresting news, specialy about code completion.
--
Jérémie

[attachment deleted by admin]

[ollydbg]

@jfouche

You are right, I'm sorry that I'm new to codeLite, so I don't know the short-cut "ctrl + space". (especially, in my windows system, press ctrl + space will do nothing but change the input method ).

I just do more test, I found that Lex&Yacc works really good!

Also, Code::Blocks can really learn from that.