On Thu, 14 Nov 2024, 06:06 François Dumont, <frs.dum...@gmail.com> wrote:
> Sounds like a very good idea. > > Moreover friend declaration could be limited to another _Hashtable<> > type with same _Key, _Value and _Alloc types to be compatible. > C++ doesn't support friends with some template arguments fixed, you either need to declare every specialization as a friend, or a specific specialization with all template arguments fixed. We would need some intermediate helper like the _Hash_merge_helper, and use that to access all members. > On 08/11/2024 11:33, Jonathan Wakely wrote: > > On Thu, 7 Nov 2024 at 22:18, Jonathan Wakely wrote: > >> I realised that _M_merge_unique and _M_merge_multi call extract(iter) > >> which then has to call _M_get_previous_node to iterate through the > >> bucket to find the node before the one iter points to. Since the merge > >> function is already iterating over the entire container, we had the > >> previous node a moment ago. Walking the whole bucket to find it again is > >> wasteful. We could just rewrite the loop in terms of node pointers > >> instead of iterators, and then call _M_extract_node directly. However, > >> this is only possible when the source container is the same type as the > >> destination, because otherwise we can't access the source's private > >> members (_M_before_begin, _M_begin, _M_extract_node etc.) > > Of course we could just make _Hashtable<A...> a friend of > > _Hashtable<B...> so that we can always access the private members, and > > not need the separateimplementations using the private and public > > APIs. > > > > That would compile faster, be less code to maintain, and have more > > test coverage (because all the tests would use the same code). > > > > I tend to avoid granting friendship when possible, but maybe here it's > > the better option. >
