[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs contributions, C and Lisp
From: |
David Engster |
Subject: |
Re: Emacs contributions, C and Lisp |
Date: |
Wed, 26 Feb 2014 17:28:23 +0100 |
User-agent: |
Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) |
Óscar Fuentes writes:
> See this simple example:
>
> struct A {
> int foo();
> };
>
> struct B {
> int bar();
> };
>
> A baz(int);
> B baz(A);
>
> int quux(char c) {
> return baz(c). ???????????
> }
>
> For knowing the correct completion candidates at the point indicated by
> the question marks you need to know which `baz' overload to choose,
> which in turn requires to know that `c' is a `char' and then knowing
> that a `char' is acceptable by the `baz' overload that takes an `int'.
> Therefore you know that the correct `baz' overload returns an `A' and
> therefore the list of completion candidates is `foo'.
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
Also, run "M-x bovinate" to see the tags the parser generates. In the
function, run "M-x semantic-calculate-scope" to see what it knows there.
> 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. That should not
be very hard to add, but - as usual - someone has to do it.
> One was already mentioned by Stephen Leake: refactoring. Actually,
> anything that requires semantic knowledge of the source code you are
> working on. You could ask for a listing of places dependent of word
> size, for instance, or highlight the places where certain idiom is used.
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.
-David
- Re: Emacs contributions, C and Lisp, (continued)
- Re: Emacs contributions, C and Lisp, David Kastrup, 2014/02/25
- Re: Emacs contributions, C and Lisp, Stephen Leake, 2014/02/25
- Re: Emacs contributions, C and Lisp, David Kastrup, 2014/02/25
- 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 <=
- 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, 2014/02/26
- 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