From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6333 invoked by alias); 31 Jul 2008 22:58:20 -0000 Received: (qmail 6323 invoked by uid 22791); 31 Jul 2008 22:58:19 -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:58:00 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 1C48198243; Thu, 31 Jul 2008 22:57:58 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id F209798015; Thu, 31 Jul 2008 22:57:57 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KOh5p-0007yX-6e; Thu, 31 Jul 2008 18:57:57 -0400 Date: Thu, 31 Jul 2008 23:25:00 -0000 From: Daniel Jacobowitz To: Hilfinger@CS.Berkeley.EDU Cc: gdb@sourceware.org Subject: Re: GDB to C++ issue: deletion Message-ID: <20080731225757.GA30276@caradoc.them.org> Mail-Followup-To: Hilfinger@CS.Berkeley.EDU, gdb@sourceware.org References: <20080731222950.GA27792@caradoc.them.org> <200807312240.m6VMe2XR007655@tully.CS.Berkeley.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200807312240.m6VMe2XR007655@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/msg00358.txt.bz2 On Thu, Jul 31, 2008 at 03:40:02PM -0700, Paul Hilfinger wrote: > > Please let's not confuse this already sprawling discussion further > > with this level of detail! > > 1. Ahem, which is precisely why I used a new subject, so as not to > incorporate an incidental side discussion into the same thread! Sorry. You replied to the same thread; most current Unix mailers will thread such replies together regardless of subject. I didn't even notice. > 2. On the other hand, if someone is going to claim the advantages of > not having to do delete as an advantage, it is not entirely > unreasonable to make sure it really works out that way in practice. IMO that applies to short lived variables, not the sort of things that get obstacked at all. -- Daniel Jacobowitz CodeSourcery