From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs and Gnome Canvas Date: Sat, 17 Jul 2010 10:57:55 +0300 Message-ID: <83630efsl8.fsf@gnu.org> References: <4C3ECB4C.6050208@swipnet.se> <83aaptgly1.fsf@gnu.org> <4C3ED4F9.4080603@swipnet.se> <83630hgi0r.fsf@gnu.org> <4C3EE8D6.3020607@swipnet.se> <8339vlgcax.fsf@gnu.org> <87fwzkbzg8.fsf@telefonica.net> <877hkwag6y.fsf@stupidchicken.com> <877hkwbth6.fsf@telefonica.net> <83pqyofzdg.fsf@gnu.org> <8739vkbpq5.fsf@telefonica.net> <83oce8fwlq.fsf@gnu.org> <87tyo0a11p.fsf@telefonica.net> <83k4ovg7rn.fsf@gnu.org> <87630fa4j8.fsf@telefonica.net> <83d3unfo92.fsf@gnu.org> <87wrsv8l6u.fsf@telefonica.net> <83bpa7feta.fsf@gnu.org> <87zkxr6s34.fsf@telefonica.net> <56009CA1-80D6-43CC-BC46-42002D2B4498@mit.edu> <87r5j36kc4.fsf@telefonica.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: dough.gmane.org 1279353559 26393 80.91.229.12 (17 Jul 2010 07:59:19 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 17 Jul 2010 07:59:19 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?utf-8?Q?=C3=93scar_Fuentes?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 17 09:59:16 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Oa2Ie-0007Wk-0T for ged-emacs-devel@m.gmane.org; Sat, 17 Jul 2010 09:59:08 +0200 Original-Received: from localhost ([127.0.0.1]:56120 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oa2Ic-0000eS-WB for ged-emacs-devel@m.gmane.org; Sat, 17 Jul 2010 03:59:07 -0400 Original-Received: from [140.186.70.92] (port=39855 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oa2IW-0000eN-0H for emacs-devel@gnu.org; Sat, 17 Jul 2010 03:59:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oa2IU-0006Hd-H5 for emacs-devel@gnu.org; Sat, 17 Jul 2010 03:58:59 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:40112) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oa2IU-0006HQ-6k for emacs-devel@gnu.org; Sat, 17 Jul 2010 03:58:58 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0L5O00200ZG88N00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Sat, 17 Jul 2010 10:57:57 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.61.30]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L5O000MCZGJPW60@a-mtaout23.012.net.il>; Sat, 17 Jul 2010 10:57:56 +0300 (IDT) In-reply-to: <87r5j36kc4.fsf@telefonica.net> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:127493 Archived-At: > From: =C3=93scar Fuentes > Date: Sat, 17 Jul 2010 02:08:43 +0200 >=20 > Second, whatever mechanism Emacs uses for memory management, it is > usable from C++ as well (for dealing with Emacs objects, of course.= ) How can you be sure? Emacs overrides the default `malloc' and `sbrk' functions, at least o= n some platforms, and replaces them with its own implementations. Thos= e implementations relocate large objects on the heap behind the scenes, whenever Emacs sees fit. I'm not sure this is "usable from C++" out of the box. C++ objects that hold pointers to arrays might suddenly find those pointers invalidated by the above-mentioned relocation. We had quite a few bugs caused by that in Emacs, even though the issu= e is well known and there are special protocols in Emacs sources to follow in order to avoid that. See, for example these messages regarding one such bug: http://lists.gnu.org/archive/html/emacs-devel/2010-02/msg00666.html http://lists.gnu.org/archive/html/emacs-devel/2010-02/msg00702.html http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg00088.html If you want to see the fix, it's revno 99601 on the trunk. > Is it better to not try it, then? No. But you need to be careful when you are choosing your tools of trade -- they need to allow you to concentrate on the important issues, instead of wasting energy on obstacles that have nothing to d= o with the problems you intend to solve.