From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id DACAB385AC30 for ; Thu, 18 Nov 2021 16:17:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DACAB385AC30 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [172.16.0.95] (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 506CB1EDEE; Thu, 18 Nov 2021 11:17:31 -0500 (EST) Subject: Re: [PATCHv2] Changes to gdb.Value.__init__ To: Andrew Burgess , gdb-patches@sourceware.org Cc: Tom Tromey References: <20211118152023.GO2352@redhat.com> From: Simon Marchi Message-ID: <6790e063-8273-9ac7-1596-638764c7aa64@simark.ca> Date: Thu, 18 Nov 2021 11:17:30 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20211118152023.GO2352@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: tl Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Thu, 18 Nov 2021 16:17:33 -0000 On 2021-11-18 10:20 a.m., Andrew Burgess wrote: > Simon, > > Thanks for your feedback on the v1 series. > > I tried to take your suggestion, but I don't think it can "just > work". The intrusive_list_node definition looks like this: > > template > struct intrusive_list_node > { > bool is_linked () const > { > return next != INTRUSIVE_LIST_UNLINKED_VALUE; > } > > T *next = INTRUSIVE_LIST_UNLINKED_VALUE; > T *prev = INTRUSIVE_LIST_UNLINKED_VALUE; > }; > > When embedded into a Python type the default values will not be > honoured during object creation, in some cases these fields will be > zero'd and in other cases they are left uninitialised. We'd have to > manually set these fields ourselves, which, to me, feels worse than > just not using intrusive_list at all - a user seeing that we use > intrusive_list might make assumptions about the behaviour which are > not correct, by using some other data structure these assumptions will > be avoided. Ah shoot, I forgot that unlinked value was -1, I thought it was 0. I don't even remember why it's -1 and not 0. > Given your concerns about the overhead of using std::unordered_set > I've just dropped the old first patch. I did briefly consider > std::list, but finding items for deleting becomes expensive, so I > discarded that. In that case, I wouldn't mind using unordered_set if it makes some things easier. As I said, I didn't have any practical concerns with using unordered_set, it was just that using intrusive_list seemed easy. Simon