From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Wed, 26 Feb 2014 20:41:56 +0100 Message-ID: <87txbld5kr.fsf@wanadoo.es> References: <87wqgr4v18.fsf@yandex.ru> <53064BD0.7070009@yandex.ru> <87ha7tr5bo.fsf@fencepost.gnu.org> <87ppmhecd8.fsf@yandex.ru> <87y50z90pd.fsf@fencepost.gnu.org> <87txbn8r6x.fsf@fencepost.gnu.org> <8338j717oe.fsf@gnu.org> <87zjlf6tdx.fsf@fencepost.gnu.org> <83sir7yue7.fsf@gnu.org> <8761o3dlak.fsf@wanadoo.es> <83bnxuzyl4.fsf@gnu.org> <871tyqes5q.fsf@wanadoo.es> <87a9ddg7o8.fsf@engster.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1393443745 18038 80.91.229.3 (26 Feb 2014 19:42:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Feb 2014 19:42:25 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 26 20:42:32 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WIkND-0002uk-Sh for ged-emacs-devel@m.gmane.org; Wed, 26 Feb 2014 20:42:32 +0100 Original-Received: from localhost ([::1]:42994 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIkND-0007UK-Fw for ged-emacs-devel@m.gmane.org; Wed, 26 Feb 2014 14:42:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35395) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIkN4-0007R9-TL for emacs-devel@gnu.org; Wed, 26 Feb 2014 14:42:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WIkMy-0001m1-Tw for emacs-devel@gnu.org; Wed, 26 Feb 2014 14:42:22 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:45648) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WIkMy-0001kT-NA for emacs-devel@gnu.org; Wed, 26 Feb 2014 14:42:16 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WIkMu-0001tv-NP for emacs-devel@gnu.org; Wed, 26 Feb 2014 20:42:12 +0100 Original-Received: from 19.red-83-39-162.dynamicip.rima-tde.net ([83.39.162.19]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Feb 2014 20:42:12 +0100 Original-Received: from ofv by 19.red-83-39-162.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Feb 2014 20:42:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 50 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 19.red-83-39-162.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:M++WxiEHwEwqDXIw8zux+7FMK38= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:169890 Archived-At: David Engster 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.