From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21800 invoked by alias); 5 Feb 2011 12:47:28 -0000 Received: (qmail 21789 invoked by uid 22791); 5 Feb 2011 12:47:28 -0000 X-SWARE-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,BAYES_00,DNS_FROM_RFC_BOGUSMX,SARE_HEAD_XWORD,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from caprica.metux.de (HELO mailgate.caprica.metux.de) (82.165.128.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 05 Feb 2011 12:47:22 +0000 Received: from mailgate.caprica.metux.de (localhost.localdomain [127.0.0.1]) by mailgate.caprica.metux.de (8.14.4/8.14.4) with ESMTP id p15ChwKP019673 for ; Sat, 5 Feb 2011 13:43:59 +0100 Received: (from uucp@localhost) by mailgate.caprica.metux.de (8.14.4/8.14.4/Submit) with UUCP id p15ChEan019648 for gcc-help@gcc.gnu.org; Sat, 5 Feb 2011 13:43:14 +0100 Received: (from weigelt@localhost) by nibiru.metux.de (8.12.10/8.12.10) id p15CbQWs004223 for gcc-help@gcc.gnu.org; Sat, 5 Feb 2011 13:37:26 +0100 Date: Sat, 05 Feb 2011 12:51:00 -0000 From: Enrico Weigelt To: gcc-help@gcc.gnu.org Subject: Re: C++ and garbage collection Message-ID: <20110205123726.GA29367@nibiru.local> Reply-To: weigelt@metux.de Mail-Followup-To: gcc-help@gcc.gnu.org References: <20110204194604.GB12837@nibiru.local> <8762szv979.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8762szv979.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.4.1i X-Terror: bin laden, kill bush, Briefbombe, Massenvernichtung, KZ, X-Nazi: Weisse Rasse, Hitlers Wiederauferstehung, 42, X-Antichrist: weg mit schaeuble, ausrotten, heiliger krieg, al quaida, X-Killer: 23, endloesung, Weltuntergang, X-Doof: wer das liest ist doof X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2011-02/txt/msg00117.txt.bz2 * Florian Weimer wrote: Hi, > > My idea is to add some mark+sweep gc (boem-gc ?) and remove (or > > somehow disable) all delete operations. Does that work safely, > > or do I have to cope with certain nasty side effects ? > > Performance might change. Okay, it might block a little time when the GC runs, but as it's a menu-driven application, this won't matter much, IMHO. > Object lifetimes are no longer deterministic, and destructors will not > be called. This can be a significant issue. Yes, for examples having to close fd's before unmounting filesystems. But these places are quite few, already identified and mostly encapsulated, so I can easily add an direct close (independent of object lifetimes) instead of the delete operations. > There are a few cases when the Boehm-Dehmers-Weiser collector won't > work, for instance if you have got custom memory allocators or use > some pointer encoding schemes. That's not the case in my app. Purely C++, plus some additional libraries which I could review quite easily. cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------