[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs contributions, C and Lisp
From: |
Óscar Fuentes |
Subject: |
Re: Emacs contributions, C and Lisp |
Date: |
Wed, 26 Feb 2014 20:41:56 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
David Engster <address@hidden> writes:
> With latest Emacs from trunk:
>
> - Put the above in file test.c
> - Load it
> - M-x semantic-mode
> - Put point behind "baz(c)."
> - C-c , l
Impressive, but...
[snip]
>> Even this very simple case requires knowing the semantics of C++. Even
>> if this looks approachable by a parser armed with some ad-hoc
>> heuristics, those will surely fail by just adding/modifying a couple of
>> lines on the test case above, unless those heuristics implement semantic
>> analysis under cover.
>
> Yes. You will notice that if you change 'quux' to accept a struct A, it
> will still say 'foo'. But this is actually not a parser problem, but a
> missing feature in the semantic database, which currently cannot deal
> with overloads, so it just takes the first one it sees.
... it works just by chance.
> That should not
> be very hard to add, but - as usual - someone has to do it.
Overload resolution is one of the most difficult parts of "C++ with
classes" (the language without templates). Another very tricky part is
namespace resolution.
> CEDET will most probably never be able to refactor C++ code, aside from
> very simple cases. There are very few IDEs out there which even try to
> do that; from my experience, none of them do it 100% reliably (just
> bring some meta template programming into the game and see what
> happens). IMHO, "Refactoring C++" should not be in the job description.
Just because current solutions are no 100% accurate doesn't mean that
the feature should be ignored. Until recently, those solutions falled
into two classes: "heroic" parsers (i.e. Eclipse's) and compilers acting
as analyzers (MS Visual Studio, which uses a propietary compiler
front-end (not their own)) inspecting its internal state. The former is
absolutely insufficient and the later is like using an square peg in a
round hole, because the compiler was never intended to do that (same
could be said of GCC.) Clang is changing all that because it is designed
from the start for making available and manageable the required
information.
- Re: Emacs contributions, C and Lisp, (continued)
- Re: Emacs contributions, C and Lisp, Stephen Leake, 2014/02/25
- Re: Emacs contributions, C and Lisp, Eli Zaretskii, 2014/02/25
- Re: Emacs contributions, C and Lisp, David Kastrup, 2014/02/25
- Re: Emacs contributions, C and Lisp, Eli Zaretskii, 2014/02/25
- Re: Emacs contributions, C and Lisp, Óscar Fuentes, 2014/02/25
- Re: Emacs contributions, C and Lisp, Eli Zaretskii, 2014/02/25
- Re: Emacs contributions, C and Lisp, Óscar Fuentes, 2014/02/25
- Re: Emacs contributions, C and Lisp, David Engster, 2014/02/26
- Re: Emacs contributions, C and Lisp, Josh, 2014/02/26
- Re: Emacs contributions, C and Lisp, David Engster, 2014/02/26
- Re: Emacs contributions, C and Lisp,
Óscar Fuentes <=
- Re: Emacs contributions, C and Lisp, David Engster, 2014/02/26
- Re: Emacs contributions, C and Lisp, Óscar Fuentes, 2014/02/26
- Re: Emacs contributions, C and Lisp, David Kastrup, 2014/02/26
- Re: Emacs contributions, C and Lisp, Stefan Monnier, 2014/02/26
- Re: Emacs contributions, C and Lisp, John Yates, 2014/02/26
- Re: Emacs contributions, C and Lisp, David Engster, 2014/02/26
- Re: Emacs contributions, C and Lisp, John Yates, 2014/02/26
- Re: Emacs contributions, C and Lisp, David Engster, 2014/02/27
- Re: Emacs contributions, C and Lisp, Eli Zaretskii, 2014/02/27
- Re: Emacs contributions, C and Lisp, Richard Stallman, 2014/02/27