From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16745 invoked by alias); 31 Jul 2008 22:30:14 -0000 Received: (qmail 16733 invoked by uid 22791); 31 Jul 2008 22:30:12 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 31 Jul 2008 22:29:52 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 02C2498243 for ; Thu, 31 Jul 2008 22:29:51 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id D4D3998015 for ; Thu, 31 Jul 2008 22:29:50 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KOgec-0007Jj-6I for gdb@sourceware.org; Thu, 31 Jul 2008 18:29:50 -0400 Date: Thu, 31 Jul 2008 22:40:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Re: GDB to C++ issue: deletion Message-ID: <20080731222950.GA27792@caradoc.them.org> Mail-Followup-To: gdb@sourceware.org References: <1217498852.4594.30.camel@piko.site> <200807312204.m6VM4JQM007611@tully.CS.Berkeley.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200807312204.m6VM4JQM007611@tully.CS.Berkeley.EDU> User-Agent: Mutt/1.5.17 (2008-05-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00356.txt.bz2 On Thu, Jul 31, 2008 at 03:04:19PM -0700, Paul Hilfinger wrote: > This reminded me of an issue that I'd be curious to see discussed. > The STL container classes are certainly convenient for decreasing > memory leaks with little fuss, but they do so internally with > individual frees of allocated items. Please let's not confuse this already sprawling discussion further with this level of detail! The STL is not an obvious natural successor to custom allocators. Some things GDB uses obstacks for out of inertia, or because they were simpler than the alternatives; others are performance critical. The performance critical ones might benefit from some sort of pool allocator instead, or continue with obstacks. -- Daniel Jacobowitz CodeSourcery