[Top][All Lists]

[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...


>> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]