From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41695 invoked by alias); 14 Dec 2019 17:39:05 -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 41687 invoked by uid 89); 14 Dec 2019 17:39:04 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy= 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; Sat, 14 Dec 2019 17:39:03 +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 xBEHcrPe016905 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 14 Dec 2019 12:38:58 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca xBEHcrPe016905 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1576345139; bh=f+Jie5mnZbE0RWdCG7l9t2NynoDB7ivKrWae7YKdQc4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=jJyvFaFoKzoaohw4EKC7DEWHOhUjU2PebrIaNvoBI9HUnDEakO7Rvj0QIicITm7Vp 6lKRlw1e5VX0GiUZCZu0JDHM6TfTAi+7W1CqbX56B2hCRaymexPsCX/6ISvu/easNq sXFCdj+D4vJ2q7VtAI424J4ll31KcfKBcjiKPsDs= Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id A56B01E5F8; Sat, 14 Dec 2019 12:38:53 -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> <85f3026a-f05f-c357-d760-0b7c7cd90a02@polymtl.ca> From: Simon Marchi Message-ID: Date: Sat, 14 Dec 2019 17:39:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0 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/msg00664.txt.bz2 On 2019-12-13 5:20 p.m., Pedro Alves wrote: > On 12/13/19 9:01 PM, Simon Marchi wrote: >> On 2019-12-13 3:57 p.m., Pedro Alves wrote: >>> 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. >> > > It wouldn't be that much simpler, but simpler regardless, I believe. > Instead of a vector of heap-allocated pointers, with means an extra levels of > indirection and use of a unique_ptr to manage memory, the list would hold > the objects directly, and you'd get address stability encoded in the > data structure. I don't think changing it would be anything remotely > complicated, since vector/list's apis are quite similar, if not the same > for the uses here. Seems like a win to me. But I'm not unhappy with > what you have. Ok, I can do a v2 with that. Simon