From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99588 invoked by alias); 13 Dec 2019 21:02:06 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 99579 invoked by uid 89); 13 Dec 2019 21:02:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1149 X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 13 Dec 2019 21:02:05 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id xBDL1tPc011782 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Dec 2019 16:02:00 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca xBDL1tPc011782 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1576270921; bh=YNJlrag9Sxnb5Fx2ia8uWOz1fKaHEka/cyrcM1WG1ek=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=IpWZovkEY9VHgIkM+YNu+QHnhBp0e4ROZ/hEoWzGcXnD6T7WIcak3h1IM5MHw+VLf XYN/J0DhYs7YPy6BWpufEaL0kAgeJ1yGT99Y5+AZ7UW8Smdc9C37duxwLtyf1POs/C tThXdEh6dtlgMuls3OPhtMwHyPESKImmN87XGny4= Received: from [172.16.0.95] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 127CB1E573; Fri, 13 Dec 2019 16:01:55 -0500 (EST) Subject: Re: [PATCH 6/7] jit: c++-ify gdb_block To: Pedro Alves , Christian Biesinger Cc: gdb-patches References: <20191213060323.1799590-1-simon.marchi@polymtl.ca> <20191213060323.1799590-7-simon.marchi@polymtl.ca> <06ec7caa-e2ed-e560-9456-0755d246633f@polymtl.ca> From: Simon Marchi Message-ID: <85f3026a-f05f-c357-d760-0b7c7cd90a02@polymtl.ca> Date: Fri, 13 Dec 2019 21:02:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00613.txt.bz2 On 2019-12-13 3:57 p.m., Pedro Alves wrote: > On 12/13/19 3:18 PM, Simon Marchi wrote: >> On 2019-12-13 10:10 a.m., Christian Biesinger via gdb-patches wrote: >>>> @@ -455,10 +463,7 @@ struct gdb_symtab >>>> ~gdb_symtab () >>>> { >>>> for (gdb_block *gdb_block_iter : this->blocks) >>>> - { >>>> - xfree ((void *) gdb_block_iter->name); >>>> - xfree (gdb_block_iter); >>>> - } >>>> + delete gdb_block_iter; >>>> } >>>> >>> >>> Have you considered making this a vector of unique_ptrs, so you don't have >>> to manually delete them? >> >> Yes, it's done in the following patch. I went perhaps a bit overboard with the >> patch splitting, but I prefer to do these changes in many smaller patches, so that >> if something goes wrong, it's easier to identify the culprit. > > I wonder whether it wouldn't be simpler to use std::list for these cases. I don't think the code would be much different if use used a list, so I don't expect it to be much simpler. If there's a compelling argument for using a list, I can do the change, but if it's equivalent, I'd rather stick with what is already done. Simon