public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
From: "François Dumont" <frs.dumont@gmail.com>
To: Jonathan Wakely <jwakely@redhat.com>
Cc: "libstdc++@gcc.gnu.org" <libstdc++@gcc.gnu.org>
Subject: Re: libstdc++ PR 57272 Fancy pointer support in Hashtable
Date: Tue, 20 Oct 2020 19:26:08 +0200	[thread overview]
Message-ID: <3934f5f5-a90d-6114-3555-e981ad2afee3@gmail.com> (raw)
In-Reply-To: <20201020110422.GA926136@redhat.com>

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<typename _Ptr>
> struct _Fancy_node_base
> {
>   _Ptr _M_next;
> };
>
> template<typename _Ptr>
>   using node_base = conditional_t<is_pointer<_Ptr>::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.


  reply	other threads:[~2020-10-20 17:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-19 17:31 François Dumont
2020-05-15 21:12 ` François Dumont
2020-09-28 20:37   ` François Dumont
2020-10-20 11:04     ` Jonathan Wakely
2020-10-20 17:26       ` François Dumont [this message]
2020-11-01 21:48       ` François Dumont
2020-11-02 14:11         ` Jonathan Wakely
2020-11-02 21:33           ` François Dumont
2021-01-11 18:10           ` François Dumont
2021-06-10 17:22           ` François Dumont

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3934f5f5-a90d-6114-3555-e981ad2afee3@gmail.com \
    --to=frs.dumont@gmail.com \
    --cc=jwakely@redhat.com \
    --cc=libstdc++@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).