[PATCH] Add standard insert overloads to StringMap

Agustín K-ballo Bergé kaballo86 at hotmail.com
Mon Jun 16 16:28:04 PDT 2014


Forwarding as I hit reply instead of reply-all

-------- Original Message --------
Subject: Re: [PATCH] Add standard insert overloads to StringMap
Date: Mon, 16 Jun 2014 20:22:15 -0300
From: Agustín K-ballo Bergé <kaballo86 at hotmail.com>
To: David Blaikie <dblaikie at gmail.com>

On 16/06/2014 08:01 p.m., David Blaikie wrote:
> On Mon, Jun 16, 2014 at 3:36 PM, Agustín Bergé<kaballo86 at hotmail.com>  wrote:
>>>> >>>I would like to add a test case that triggers a table rehash but I'm not sure how to do that, suggestions?
>>> >>
>>> >>Not sure, actually. It looks like the growth function is the usual sort of thing, so probably just inserting a second element should cause a rehash - no?
>> >
>> >I did not see this in my previous tests using up to 10 values, because the hash table starts with 16 buckets. I see that I can specify how many buckets to use on construction, so creating a map with only 1 bucket and adding two elements to it would trigger a rehash. Then I'd have to make sure that the rehash actually moves the bucket around, which is the tricky part.
> Yep, you should be able to do that, as you say, by starting with a
> bucket count of 1 then if you want to make sure it actually caused a
> re-hash, you could just assert that the address of some element is
> different after the operation you expect to be a rehash.
>

The address of the elements in the map doesn't change, they are
allocated once and never copied/moved. Buckets have pointers to those
elements, and a rehash simply causes buckets to maybe point to a
different element.

The situation I would like to generate is one in which an element is
initially inserted into one bucket but rehashing moves it (the pointer
to the element) to a different one, all within `insert`. As far as I
understand, this is only possible by crafting a special insertion
sequence based on the details of the hasher used by the implementation,
and it's somewhat fragile.

Regards,
-- 
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com






More information about the llvm-commits mailing list