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.
next prev parent 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).