From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id N8MKL9TV62MjyzIAWB0awg (envelope-from ) for ; Tue, 14 Feb 2023 13:41:24 -0500 Received: by simark.ca (Postfix, from userid 112) id B711D1E222; Tue, 14 Feb 2023 13:41:24 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=KINwXUO2; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 6D22E1E128 for ; Tue, 14 Feb 2023 13:41:24 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D0A163858D35 for ; Tue, 14 Feb 2023 18:41:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D0A163858D35 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1676400083; bh=eDCTQjVlIdpX8qdnKJs2omtiLfmhCvKZbqRjYDrlbOw=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=KINwXUO28vaPdqq9T+D0EanwbB3TzhpaRdlfs+ZttHAOh3j0jEHEDmoIjXaNIYPIg mdtRJN14eZSXwUMTIRQMb41lOXO/MwIW+NyQtN/vyYNHfnpBLW1hboUO6zgakn9eAZ qhtueVejZUuQFEu8nd4pWmKl24IXsIcD+4DpkFJs= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 6AA073858D1E for ; Tue, 14 Feb 2023 18:41:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6AA073858D1E Received: from [172.16.0.192] (192-222-180-24.qc.cable.ebox.net [192.222.180.24]) (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 B8A3D1E0D3; Tue, 14 Feb 2023 13:41:03 -0500 (EST) Message-ID: <748f35a2-bb69-2362-de5d-81481c4e408e@simark.ca> Date: Tue, 14 Feb 2023 13:41:03 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Subject: Re: [PATCH 1/3] gdb: store internalvars in an std::vector Content-Language: fr To: Lancelot SIX , Simon Marchi Cc: gdb-patches@sourceware.org References: <20230214042139.73638-1-simon.marchi@efficios.com> <20230214105446.desfcw5xz5wpiqbt@octopus> In-Reply-To: <20230214105446.desfcw5xz5wpiqbt@octopus> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 2/14/23 05:54, Lancelot SIX via Gdb-patches wrote: > On Mon, Feb 13, 2023 at 11:21:37PM -0500, Simon Marchi via Gdb-patches wrote: >> Change the storage of internalvars to an std::vector of unique pointers >> to internalval. This helps automate memory management, and will help >> keep internalvars sorted in a subsequent patch. >> >> I initially tried to use an std::vector initially, but some >> parts of the code need for the addresses of internalvars to be stable. >> > > Hi Simon, > > As the end-goal is to have an order, did you consider using a container > which enforces it like a std::map? For small number of objects (for > some definition of small…) vector is usually more efficient but as here > you hold pointers, I am not sure the vector brings a huge benefit. > > You could use a std::map as the internalvar’s > address will remain stable. No need to have a unique_ptr. > > One downside of the std::map is that you might end up with the name > stored twice (once as key, and maybe still once in the internalvar > object). std::set can also be used, but with other downsides. I had not thought of that, but I think it's a good idea. Having the name stored twice is not an issue, I think. > The main difference with vector can come if we had 2 internal variables > with the same name. The current code does not prevent this AFAICT, but > as one of the vars would effectively shadow the other, I am not sure > this is a case we want to support anyway. I don't think it can really happen today anyway. create_internalvar_type_lazy is only used to create variable known in advance, for which we know there are no clashes. And through lookup_internalvar, create_internalvar is only called after seeing that there is no variable by that name. So, I think we'll be fine with a map. Simon