From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2372 invoked by alias); 31 Jul 2008 23:25:40 -0000 Received: (qmail 2323 invoked by uid 22791); 31 Jul 2008 23:25:39 -0000 X-Spam-Check-By: sourceware.org Received: from tully.CS.Berkeley.EDU (HELO tully.CS.Berkeley.EDU) (128.32.153.206) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 31 Jul 2008 23:25:21 +0000 Received: from tully.CS.Berkeley.EDU (localhost [127.0.0.1]) by tully.CS.Berkeley.EDU (8.13.8+Sun/8.13.8) with ESMTP id m6VNPI7u007784; Thu, 31 Jul 2008 16:25:18 -0700 (PDT) Message-Id: <200807312325.m6VNPI7u007784@tully.CS.Berkeley.EDU> To: Daniel Jacobowitz cc: gdb@sourceware.org Subject: Re: GDB to C++ issue: deletion Reply-To: Hilfinger@CS.Berkeley.EDU MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7780.1217546718.1@tully.CS.Berkeley.EDU> Date: Thu, 31 Jul 2008 23:34:00 -0000 From: Paul Hilfinger 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/msg00359.txt.bz2 > > 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. How "helpful" of them. Sorry; I didn't edit my header stringently enough. My bad. > > 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. Actually, I had already concluded that short-lived variables would NOT be a great problem. To a first approximation, the effect of using STL's storage management is to increase allocation costs by some constant factor, because deallocation cost for an object tends to be limited by some constant times its allocation cost. As long as GDB's allocation costs are not huge (and the constant factors are not huge), we shouldn't have much pain. But that's just an overall argument about total execution time. Common sources of short-lived variables (say during parsing and (sub)expression evaluation) don't produce that many variables between prompts (usually). What I was more interested in was the possibility of noticeably large changes in pause times for expensive operations (such as re-reading a symbol table) on large executables. I can think of approaches, certainly, but have no actual experience with how well they integrate with STL classes in practice. Paul