VLOmniCpp - vim 的新的基于 ctags 的 c/cpp 全能补全插件

[lilydjwg]

java呢

javacomplete.vim 还行吧。

[asmwarrior]

嘿嘿，非常值得我学习，我目前立志于改进/重写 codeblocks的代码完成模块。

最近一个星期一直在搞模版的事, 现在算是基本完成了, 在处理名空间的事
最大的感想就是, 实在没办法做到100%精确, 只能处理风格良好的代码
如果想办法做到100%准确, 开销相当大, 对于脚本来说不可接受
你可以试一下下面这个不是很复杂的模版测试, 如果复杂的情况, 如基类加了一堆作用域, 或者基类定义在打开的某个命名空间中等等
[cpp]
class A {
public:
int a;
};

class AA {
public:
int aa;
};

template<typename T>
class A2 {
public:
int a2;
T ta2;
};
int g_b;
template<typename T>
class B {
public:
int b;
T tb;
class BB {
int bb;
void BBFunc()
{
}
};
};

template<typename T1, typename T2>
class B2 : public A2<T2> {
public:
int b2;
T1 tb21;
T2 tb22;
AA aaaa;
A2<T1> b2a2t1;
A2<A> b2a2t2;
T1 B2Get();
//T2<T1> bt2t1;
};

template<typename T = A>
class C : public B<T>, public B2<T, A> {
public:
int c;
T tc;
T Get() { return B2<T, A>::tb21; }
};

int main(int argc, char *argv[])
{
C<AA> c;
c.tc; // test1
c.tb; // test2
c.ta2; // test3
c.tb21; // test4
c.tb22; // test5
c.tb; // test6
c.b; // test7 -> failed
c.Get(); // test8
c.b2a2t1.ta2; // test9
c.b2a2t2.ta2; // test10

return 0;
}
[/cpp]

最后, 我对codeblocks的parser有点兴趣, 不知道能不能提取出来, 我可以把ctags换成cb的parser, 只要符号能存进去我的数据库就行了

上次提到的对于stl的模版支持问题, 我看了下stl的头文件, 发现, 真的不是这么好处理的...
估计codelite作者作了硬替换

codeblocks的parser有点乱，我目前在整一个新的，你可以看这里：
http://code.google.com/p/quexparser/

但是距离完全能用还有很大的距离。

codeblocks的parser里面当前设计一个很不好的地方是没有使用一个lexer，什么东西从lexer返回都是用string类型的，我觉得非常糟糕。我的这个quexparser采用了集成的quex lexer。内部逻辑基本和codeblocks的parser类似。

另外，ctags的源代码我也看过，感觉很乱。。。。
codeblocks的parser和我目前尝试写的quexparser都是采用所谓的recursive parser的函数递归调用结构，还是比较清楚的，你只要把保存tags的内容变成你自己的保存sqlite的就可以了。

另外，stl的头文件里面很多宏，肯定需要进行硬替换，否则这些stl的头文件都没有办法分析。（当然我们无法写一个完善的preprocessor是一个重要原因）

[susbarbatus]

好东西啊，支持一下

[fanhe]

嘿嘿，非常值得我学习，我目前立志于改进/重写 codeblocks的代码完成模块。

最近一个星期一直在搞模版的事, 现在算是基本完成了, 在处理名空间的事
最大的感想就是, 实在没办法做到100%精确, 只能处理风格良好的代码
如果想办法做到100%准确, 开销相当大, 对于脚本来说不可接受
你可以试一下下面这个不是很复杂的模版测试, 如果复杂的情况, 如基类加了一堆作用域, 或者基类定义在打开的某个命名空间中等等
[cpp]
class A {
public:
int a;
};

class AA {
public:
int aa;
};

template<typename T>
class A2 {
public:
int a2;
T ta2;
};
int g_b;
template<typename T>
class B {
public:
int b;
T tb;
class BB {
int bb;
void BBFunc()
{
}
};
};

template<typename T1, typename T2>
class B2 : public A2<T2> {
public:
int b2;
T1 tb21;
T2 tb22;
AA aaaa;
A2<T1> b2a2t1;
A2<A> b2a2t2;
T1 B2Get();
//T2<T1> bt2t1;
};

template<typename T = A>
class C : public B<T>, public B2<T, A> {
public:
int c;
T tc;
T Get() { return B2<T, A>::tb21; }
};

int main(int argc, char *argv[])
{
C<AA> c;
c.tc; // test1
c.tb; // test2
c.ta2; // test3
c.tb21; // test4
c.tb22; // test5
c.tb; // test6
c.b; // test7 -> failed
c.Get(); // test8
c.b2a2t1.ta2; // test9
c.b2a2t2.ta2; // test10

return 0;
}
[/cpp]

最后, 我对codeblocks的parser有点兴趣, 不知道能不能提取出来, 我可以把ctags换成cb的parser, 只要符号能存进去我的数据库就行了

上次提到的对于stl的模版支持问题, 我看了下stl的头文件, 发现, 真的不是这么好处理的...
估计codelite作者作了硬替换

codeblocks的parser有点乱，我目前在整一个新的，你可以看这里：
http://code.google.com/p/quexparser/

但是距离完全能用还有很大的距离。

codeblocks的parser里面当前设计一个很不好的地方是没有使用一个lexer，什么东西从lexer返回都是用string类型的，我觉得非常糟糕。我的这个quexparser采用了集成的quex lexer。内部逻辑基本和codeblocks的parser类似。

另外，ctags的源代码我也看过，感觉很乱。。。。
codeblocks的parser和我目前尝试写的quexparser都是采用所谓的recursive parser的函数递归调用结构，还是比较清楚的，你只要把保存tags的内容变成你自己的保存sqlite的就可以了。

另外，stl的头文件里面很多宏，肯定需要进行硬替换，否则这些stl的头文件都没有办法分析。（当然我们无法写一个完善的preprocessor是一个重要原因）

ctags 也是没有lexer, 都是直接流处理, 现在用的 ctags 都是codelite作者打过patch的, 但是也有很多不足, 不能解析不少c++的东西
parser是随便可以换,只要符号能按固定格式存进去就行了
重新写parser也未尝不可, 但是重新写一个完善的parser前,我想先看看clang提供的东西, clang能做预编译头, 基本就等于事先做了个数据库, 但是唯一的缺点是不能按源文件控制补全符号
也即是说, 你预编译头包含了a.h, 你现在的源文件没有包含a.h, 你用clang用这个预编译头加快补全分析的时候, a.h 就好像被你的这个源文件包含了一样
这个问题在大项目的时候, 非成员补全的时候, 会导致符号n多

我这个告一段落之后, 估计会深入看看clang提供的ide特性, 重新做个parser就暂时不想了, 因为 parser 的完善程度还是比不上一个编译器的...

[asmwarrior]

codelite最近开启了clang的代码完成支持，最为常规 基于ctags/bison parser代码完成支持失败后的补充。
见：
http://codelite.svn.sourceforge.net/vie ... w=revision
貌似很不错！

[fanhe]

codelite最近开启了clang的代码完成支持，最为常规 基于ctags/bison parser代码完成支持失败后的补充。
见：
http://codelite.svn.sourceforge.net/vie ... w=revision
貌似很不错！

基于ctags的自动完成基本完工了, 只是暂时纠结与头文件嵌套包含处理问题.
有没有 python 写的头文件扫描程序, 即扫描出本源文件包含的所有头文件, 要求速度尽量快且必须支持缓存结果, 我现在仅有一个 vim 版本的, 用了 vimgrep, 残留了一大堆卸载 buffer, 看着不舒服
stl 的处理方法也知道了, 暂时还没搞, 所以没放出来
现在正忙着和项目管理模块的集成.

[liliwang]

发现一个bug
在scopes.vim里面的100行，omnicpp中间多了个#

[liliwang]

对了，想问下
比如，我想相对stl，boost，sdl，还有我自己的项目，都能补全，那我应该怎么配置？
比如，stl，boost，是不是只要用vlctags在它们的根目上创建tags就可以了？
然后在.vimrc中设置tags的路径，然后就可以补全了？

[liliwang]

感觉clang是比较好的解决方案啊
根据头文件决定当前的补全范围，或者是对ctags补全的补充，应该速度也会挺快，准确度也会比较好吧

[fanhe]

这贴很老久的了
现在我忙于 VimLite 整个项目，暂时没有计划把这个插件独立出来
想用这个插件就直接上 VimLite 吧