Re: A guide on setting up C/C++ development environment for Emacs

["Óscar Fuentes" <ofv@wanadoo.es>]

solidius4747@gmail.com writes:

>> That's a problem of clang-ctags being slow, not Clang being *so* slow,
>> because Clang can compile its own sources on a fraction of time of those
>> 98 minutes (15 minutes here on a 6 year old 4core machine, for an
>> optimized build.)
>
> Are you sure that it took you 15 minutes to build?

Absolutely. I build Clang+LLVM ToT every month or two.

> I'm pretty sure
> when I built LLVM followed the official guide:
> http://clang.llvm.org/get_started.html, it took me hours with a core
> i5 machine.

I guess that the machine have no enough memory and resorted to swapping.
Did you use GCC or Clang on that build? GCC requires much more memory.
Some source files of Clang are complex enough to require a good chunk of
memory even when compiled with Clang itself. OTOH, linking can be
memory-intensive, specially a debug build.

> I already updated the guide for people to try Clang solution first, as
> it seems to be more accepted for editor without a built-in language
> parser. I also emphasized in CEDET section that it might be slow for
> large source tree like Linux kernel or might not fully up to date to
> support all the C++ features. But if you see my demo screenshot, you
> see that CEDET works fine for code completion with BOOST. It responded
> instantly and gave candidates with full information (types, parameters
> and parameter types). I also explicitly wrote the section as: "Source
> code completion with C++", that means you only use CEDET for CODE
> COMPLETION - and no other fancy features in other IDE. As I demoed, it
> did A GOOD JOB for reasonably sized source tree, like BOOST.

My experience with CEDET C++ smart completion (I try it once a year) is
that it often works on the most simple cases. It is quite good for C++
when used as "C with classes". However, it fails with more elaborate
cases. The fact that it works for some example that uses Boost proves
nothing, as Boost is not uniformly complex. Your screenshot about
boost::asio is not very demanding. Try something involving templates
(apart from the simple ones like std::vector) and you will see failures.
CEDET's C++ parser falls short of understanding namespace resolution and
other minefields of the C++ language. Let's not discuss modern features
like lambdas and variadic templates.

For doing correct smart completion for C++, parsing is not enough.
Semantic analysis is necessary. CEDET's parser does nothing of the sort.

> Here are
> the two demo screenshots, I post it here again:
>
> http://tuhdo.github.io/static/c-ide/semantic-boost-demo.gif
>
> http://tuhdo.github.io/static/auto_complete.gif
>
> CEDET also provides a nice tool that is Semantic Symref:
>
> http://tuhdo.github.io/static/c-ide/semantic-symref.gif
>
> CEDET works best when you start a project from scratch. It will parse
> your source tree as you grow it, so there should be almost no waiting
> for parsing.
>
> I use it in my daily job, and it works pretty nice.

That's good news indeed. However, please keep in mind that there are
huge differences on how people/teams/projects use C++. Something that
works for you may be insufficient for others, and in all cases C++ is
being used. Doing the job with a good compiler is the definitive
solution.

> The current
> support development with C/C++ are much nicer with community packages
> contributed. When I first used Emacs, not Clang solution existed yet.
> CEDET was the only usable solution.
>
> Why CEDET is slow?

CEDET is fast enough for me. The problem is that it gives the wrong
answer too often.

> Because you don't try to do computational expensive
> tasks in Emacs. That's why you delegate heavy works to external
> processes. But Emacs could have more possibilities if it can generate
> native code, or at least has FFI.

FFI is in the "most wanted" feature list of the Emacs maintainers.
However, I don't see CEDET's team throwing away their Elisp parser and
start coding one on C/C++. They could use Clang's right away, or GCC's
once the modularization is completed, but they insist on their own's.

CEDET's problem with C++ is the extraordinary complexity of the
language. That's something that the handful of hackers working on CEDET,
no matter how talented they are, can't address on a reasonable
timeframe.