4 ms·

I agree: this is not C/C++ IDE, this is a C IDE (and maybe a "C-with-classes" IDE). None of these emacs packages (e.g. CEDET) handle modern C++ well (heavy use

by mandor 12y ago

I agree: this is not C/C++ IDE, this is a C IDE (and maybe a "C-with-classes" IDE). None of these emacs packages (e.g. CEDET) handle modern C++ well (heavy use of generic programming, boost, c++-11 features, etc.). Even indenting this code is complicated for an editor! I think the only way to do it is to rely on the compilers to parse the code. Clang has a nice API (and command lines tools) for this. For instance, there are some packages for auto-completition in emacs: http://www.emacswiki.org/emacs/AutoComplete http://www.emacswiki.org/emacs/AutoComplete Last, it would be nice to have a brew/ubuntu package so we can easily install the "IDE" :)

tuhdo 12y ago
AutoComplete has nothing to do with C/C++. It's just a package for displaying completion candidates, but you must give it a source for displaying. It is pretty outdated compare to company-complete. Company also has a Clang[ backend, available through the command company-clang. Emacs also has Clang based solutions such as rtags: https://github.com/Andersbakken/rtags https://github.com/Andersbakken/rtags that can index code as you type but is complicated to setup. Or you can use Clang to generate a tag database for your source code with clang-ctags: https://github.com/drothlis/clang-ctags https://github.com/drothlis/clang-ctags , but the performance for creating tag database is not so good for large source tree: it took "98 minutes and a peak memory usage of 140MB" to generate a tag database for entire LLVM source. As for CEDET, in what way it could not handle library like Boost? Could you be specific? I tried it before with Boost, and it works pretty well (i.e. gives correct completion candidates in a namespace). I used CEDET for getting completion candidates all the time in Boost.
- deng 12y ago
  Regarding the C++ parser, here's the current state: It does not support any C++11. Especially 'auto' is problematic, since type inference is quite a hard problem. Basic templates are handled, but things like template specialization or default template parameters still break things. I'm currently working on fixing this; it's been in my personal branch for quite some time now, but I haven't got around to merge it into mainline. Actually, still one of the most problematic things is preprocessor handling. If the parser doesn't work, it is often due to some preprocessor macros Semantic does not know about.
  - tuhdo 12y ago
    Thanks for the info. You must be David Engster, the current CEDET maintainer. Yes, I agree with the preprocessor handling since we still have manually tell Semantic what preprocessor exists in the current project. But CEDET is still very usable for most of the things and I love it.
    - deng 12y ago
      The name is correct, but I'm not CEDET's maintainer; that would still be Eric Ludlam, its original author.
- mandor 12y ago
  It is not really linked to boost, but meta-programming make many things many difficult for an IDE (whatever the IDE is). For instance, I could have this class: template<typename X> struct Test { void test(const X& x) { typename X::type_t x = x.get_something(); } }; When I type this, there is no way for the compiler to know what X will be (and even for the programmer). As a consequence, the IDE cannot help me much: no auto-completion is possible on x, no way to jump to the definition of get_something() [there are probably several implementations], no way to jump to the definition of type_t, etc. The issue is that this kind of code is very common in modern C++ (I think 90% of my code is probably templated by something) [and look at the code of boost]. So, there is probably no issue in _using_ some boost libraries or the STL, but programming "boost-like" or "STL-like" libraries probably needs different tools.

by mandor 12y ago

tuhdo 12y ago

AutoComplete has nothing to do with C/C++. It's just a package for displaying completion candidates, but you must give it a source for displaying. It is pretty outdated compare to company-complete. Company also has a Clang[ backend, available through the command company-clang. Emacs also has Clang based solutions such as rtags: https://github.com/Andersbakken/rtags https://github.com/Andersbakken/rtags that can index code as you type but is complicated to setup. Or you can use Clang to generate a tag database for your source code with clang-ctags: https://github.com/drothlis/clang-ctags https://github.com/drothlis/clang-ctags , but the performance for creating tag database is not so good for large source tree: it took "98 minutes and a peak memory usage of 140MB" to generate a tag database for entire LLVM source. As for CEDET, in what way it could not handle library like Boost? Could you be specific? I tried it before with Boost, and it works pretty well (i.e. gives correct completion candidates in a namespace). I used CEDET for getting completion candidates all the time in Boost.

deng 12y ago
Regarding the C++ parser, here's the current state: It does not support any C++11. Especially 'auto' is problematic, since type inference is quite a hard problem. Basic templates are handled, but things like template specialization or default template parameters still break things. I'm currently working on fixing this; it's been in my personal branch for quite some time now, but I haven't got around to merge it into mainline. Actually, still one of the most problematic things is preprocessor handling. If the parser doesn't work, it is often due to some preprocessor macros Semantic does not know about.
- tuhdo 12y ago
  Thanks for the info. You must be David Engster, the current CEDET maintainer. Yes, I agree with the preprocessor handling since we still have manually tell Semantic what preprocessor exists in the current project. But CEDET is still very usable for most of the things and I love it.
  - deng 12y ago
    The name is correct, but I'm not CEDET's maintainer; that would still be Eric Ludlam, its original author.
mandor 12y ago
It is not really linked to boost, but meta-programming make many things many difficult for an IDE (whatever the IDE is). For instance, I could have this class: template<typename X> struct Test { void test(const X& x) { typename X::type_t x = x.get_something(); } }; When I type this, there is no way for the compiler to know what X will be (and even for the programmer). As a consequence, the IDE cannot help me much: no auto-completion is possible on x, no way to jump to the definition of get_something() [there are probably several implementations], no way to jump to the definition of type_t, etc. The issue is that this kind of code is very common in modern C++ (I think 90% of my code is probably templated by something) [and look at the code of boost]. So, there is probably no issue in _using_ some boost libraries or the STL, but programming "boost-like" or "STL-like" libraries probably needs different tools.