1. 11 Apr, 2020 2 commits
  2. 20 Jan, 2020 2 commits
  3. 22 Oct, 2019 1 commit
    • Alex Hornby's avatar
      Fix for case where calling shrink_to_fit could make the map larger · df565f17
      Alex Hornby authored
      Reproduced issue by adding new test shrink_to_fit_after_insert.  Checked it was failing before doing any changes
      
      With the test in place fixes were:
      
      1. Make CHashMap::reserve be the place the amortizing growth factor LENGTH_MULTIPLIER is applied, rather than Table::with_capacity ( non-CHashMap::reserve users of Table::with_capacity are requesting a specific capacity and just need load factor applied, not amortizing growth multiplier )
      
      2. Apply load factor consistently in Table::with_capacity() vs CHashMap::capacity()
      
      3. Apply MINIMUM_CAPACITY in CHashMap::capacity to stop reported capacity being below requested.
      
      4. Add test known_size_with_capacity_matches_shrink to test the initial capacity+shrink case
      
      Tested via cargo test
      df565f17
  4. 09 Oct, 2019 1 commit
  5. 28 Feb, 2019 1 commit
  6. 27 Feb, 2019 1 commit
  7. 26 Feb, 2019 1 commit
  8. 25 Feb, 2019 3 commits