From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 4D3FE3857C43 for ; Tue, 20 Oct 2020 11:04:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4D3FE3857C43 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-578-vvrl_arEMiyUyWF1uhsU7w-1; Tue, 20 Oct 2020 07:04:25 -0400 X-MC-Unique: vvrl_arEMiyUyWF1uhsU7w-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B503D8049E3; Tue, 20 Oct 2020 11:04:23 +0000 (UTC) Received: from localhost (unknown [10.33.36.242]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6209355760; Tue, 20 Oct 2020 11:04:23 +0000 (UTC) Date: Tue, 20 Oct 2020 12:04:22 +0100 From: Jonathan Wakely To: =?iso-8859-1?Q?Fran=E7ois?= Dumont Cc: "libstdc++@gcc.gnu.org" Subject: Re: libstdc++ PR 57272 Fancy pointer support in Hashtable Message-ID: <20201020110422.GA926136@redhat.com> References: MIME-Version: 1.0 In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-8.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, 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 11:04:29 -0000 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.