From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Finding objects on C stack - alternate GCPRO Date: Thu, 17 Nov 2011 13:17:37 +0900 Message-ID: <87pqgridr2.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4EC38B72.1000101@yandex.ru> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: dough.gmane.org 1321503471 11144 80.91.229.12 (17 Nov 2011 04:17:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 17 Nov 2011 04:17:51 +0000 (UTC) Cc: Helmut Eller , emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 17 05:17:45 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RQtQ0-0006gi-Pr for ged-emacs-devel@m.gmane.org; Thu, 17 Nov 2011 05:17:44 +0100 Original-Received: from localhost ([::1]:52736 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQtQ0-0004zz-3b for ged-emacs-devel@m.gmane.org; Wed, 16 Nov 2011 23:17:44 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:41344) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQtPx-0004zm-V6 for emacs-devel@gnu.org; Wed, 16 Nov 2011 23:17:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQtPx-0006x4-2F for emacs-devel@gnu.org; Wed, 16 Nov 2011 23:17:41 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:58067) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQtPw-0006wn-Pe; Wed, 16 Nov 2011 23:17:41 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 0E481970773; Thu, 17 Nov 2011 13:17:38 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 02E941A3003; Thu, 17 Nov 2011 13:17:37 +0900 (JST) In-Reply-To: X-Mailer: VM 8.2.0a1 under 21.5 (beta31) "ginger" 2dbefd79b3d3 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.224 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:146068 Archived-At: Richard Stallman writes: > Please don't make Emacs use C++. C++ is an ugly and clumsy language. Except where it isn't. XEmacs code is required to compile with both C (specifically C89, thought there has been discussion recently of preferring C99) and C++ (IIRC this dialect was named "Clean C" by Martin Buchholz). This has two advantages in our practice: (1) the stricter typing rules of C++ catch some bugs[1], and (2) some things that are impossible to express cleanly in C (specifically, typeof(Emacs character) != EMACS_INT, which has been very useful in completely preventing certain Mule bugs that have regressed frequently in Emacs's implementation) can be implemented in the C++ build, and therefore type-checked. Granted, the code needed to implement such a type in C++ is very redundant if not specifically ugly, but it's really a unit test for a "unit" that pervades text manipulation code rather than being modularized into a few files. It's nice if test code can be clean and pretty, but when necessary I don't have a problem with gymnastics in test code. On the other hand, the code that actually implements XEmacs functionality still compiles (and works correctly! :-) with C and "typedef EMACS_INT Ichar" (where Ichar is our typedef for the internal representation of the character type). If C++ makes it possible to write *functionally better* allocation and garbage collection code in a clean and intelligible way, I would be in favor of relaxing the prohibition of C++ for *specified* files and *specified* C++ idioms. Footnotes: [1] I don't know if this is still true for the most recent, tighter C standard, but in our code --std=C99 does not catch all the common bugs that a C++ build does.