From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) by sourceware.org (Postfix) with ESMTPS id 23214385780F for ; Tue, 20 Oct 2020 17:26:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 23214385780F Received: by mail-wr1-x432.google.com with SMTP id h7so3156198wre.4 for ; Tue, 20 Oct 2020 10:26:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=g2fGSTJCe41ljSaxRAK2c4J6m/U8GZ0v9/bCmppLr4I=; b=SaegzJ2wEUMbyRB7XKrBJAkE7g8woIv8eSaYFjYsN8ALYeueGzVHIhpFVc9YBW8VXJ ppcLmkV/m9NA2TdF4mBhVJKAWYvpSNwFDWLtWucifMa0jQqoBcf3BdmgmprdTrVfdQJR eev/uQypo1/cptOaCVrOXeVWD+4Ad9U2n1hQyFOpurbWHT/BGUr3ZReZ2RgXQsm218ai H2StuM3Z62mOw6vr6V44a3XxsfdJlgO5m9iGMUQl3zi8KJFLKGPleKgCAJdp2OZsYUvY TG9Ciq/scJP8y4ymzuLO9ylRKf36y7uFnFQfVlKTerbNBFSIf3P5kPpIei+ucpbEaUdL 0UJQ== X-Gm-Message-State: AOAM530nhTCb9k+cT8pDzPiygcaoP4gfn2VGkD916GfHOSuYjao+DOnJ RoE2QpJAyxK+fDm/jcCFGstJ6hHM3zg= X-Google-Smtp-Source: ABdhPJz/EsaDeLq4g3dKtrrghQwrJp3N0/uEEaZCkQRiESSuFelxGP9dj6y0fyfaTBcbcqdoTV464A== X-Received: by 2002:adf:fd82:: with SMTP id d2mr4686109wrr.304.1603214770801; Tue, 20 Oct 2020 10:26:10 -0700 (PDT) Received: from ?IPv6:2a01:e0a:1dc:b1c0:74bb:bd72:c992:3ae6? ([2a01:e0a:1dc:b1c0:74bb:bd72:c992:3ae6]) by smtp.googlemail.com with ESMTPSA id x15sm4087741wrr.36.2020.10.20.10.26.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Oct 2020 10:26:09 -0700 (PDT) Subject: Re: libstdc++ PR 57272 Fancy pointer support in Hashtable To: Jonathan Wakely Cc: "libstdc++@gcc.gnu.org" References: <20201020110422.GA926136@redhat.com> From: =?UTF-8?Q?Fran=c3=a7ois_Dumont?= Message-ID: <3934f5f5-a90d-6114-3555-e981ad2afee3@gmail.com> Date: Tue, 20 Oct 2020 19:26:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201020110422.GA926136@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: fr X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 17:26:13 -0000 On 20/10/20 1:04 pm, Jonathan Wakely wrote: > On 28/09/20 22:37 +0200, François Dumont via Libstdc++ wrote: >> Following recent changes on _Hashtable I rebase the patch and >> completely review it. >> >> I managed to integrate the allocator custom pointer type without >> touching to _Hashtable base types like _Hash_code_base or >> _Hashtable_base. However I cannot see how to use the custom pointer >> type without impacting the node types like _Hash_node_base which now >> takes a template parameter, the custom pointer type. >> >> On an abi point of view node types are different however the data >> structure is the same. The only difference is that the >> _Hash_node_base _M_nxt is now a _Hash_node<> custom pointer rather >> than a simple _Hash_node_base*. >> >> Even if this patch can't go in because of the abi breaking change I >> am going to adapt some of the code simplifications for master. >> Especially the _Hash_code_base and _Local_iterator_base simplifications. >> >> Let me know if you can think of a way to integrate the custom pointer >> without impacting abi. Unless impacting node types and associated >> iterator types is fine even if I already noticed that pretty printer >> tests are broken with those changes. > > The approach I used for the other containers (which was never > completed and committed) is something like: > > struct _Node_base > { >   _Node_base* _M_next; > }; > > template > struct _Fancy_node_base > { >   _Ptr _M_next; > }; > > template >   using node_base = conditional_t::value, >                                   _Node_base, > _Fancy_node_base<_Ptr>>; > > This way all existing code that has allocators with non-fancy pointers > continues to use the same type. Code using fancy pointers (which > doesn't currently work properly anyway) changes to use the new types > that depend on the pointer type. > Ok, thanks for the tips, I'll do something similar.