This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: unordered containers: reuse nodes on assignment
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: François Dumont <frs dot dumont at gmail dot com>
- Cc: Paolo Carlini <paolo dot carlini at oracle dot com>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 4 Jul 2013 23:28:30 +0100
- Subject: Re: unordered containers: reuse nodes on assignment
- References: <51D083D4 dot 9090401 at gmail dot com> <61ed3bee-3e86-44ce-88a3-32d3f08f2126 at email dot android dot com> <51D08A74 dot 1020909 at oracle dot com> <51D1D9F3 dot 9090709 at gmail dot com> <51D1F635 dot 2030501 at oracle dot com> <51D5E0F6 dot 90406 at gmail dot com>
On 4 July 2013 21:54, François Dumont wrote:
>
> And about the patch itself, is it ok ?
Yes, that latest patch is OK, thanks.
It's made me think about the design a bit more though ...
I've been a little uncomfortable for some time with the number of
template parameters that are needed everywhere in hashtable_policy.h.
In most cases they seem necessary, but does the _ReuseOrAllocNode
template really need 10 template parameters? Couldn't it just be
passed the relevant _Hashtable type? Unfortunately with the current
design it does seem necessary to know the full _Hashtable type, even
though the functionality only really depends on the allocator type
(and node and value types, but they can be obtained from the
allocator.) That means if I instantiate unordered_set<T, H, P, A> and
unordered_set<T, H2, P2, A> the compiler has to instantiate two
different specializations of _ReuseOrAllocNode (and other code in
_Hashtable) even though it doesn't care about the two function
objects, and the executable is larger.
Would it be possible to separate _M_node_allocator, _M_allocate_node,
_M_deallocate_nodes and _M_deallocate_node into a separate base class
of _Hashtable, and have _ReuseOrAllocNode only depend on that? That
would allow unordered_set<T, H, P, A> and unordered_set<T, H2, P2, A>
to share more code.