Re: hash_table vs unordered_map

On 08/24/2013 12:20 PM, Kinkie wrote:
> On Sat, Aug 24, 2013 at 8:04 PM, Alex Rousskov
> <rousskov_at_measurement-factory.com> wrote:
>> On 08/24/2013 10:01 AM, Kinkie wrote:
>>> Hi all,
>>> I'm looking into some refactoring activity while I'm waiting for
>>> some merge reviews to be completed, and by idly browsing the code I
>>> crossed paths with hash_table.
>>>
>>> I was about to code a c++ templatized wrapper, but then I started
>>> wondering what is the advantage of hash_table versus
>>> std::unordered_map?
>>
>> hash_table does not require C++11 support in the compiler and, at least
>> in theory, does not have unknown compatibility problems with Squid code
>> (such as frequently hitting worst-case search or update scenarios).
>>
>> On the other hand, hash_table does not work well with C++ objects.
>
>>> Would it be useful to refactor from one to the other while waiting
>>> such as now?
>>
>> Do all compilers we care about support std::unordered_map?
>
> Checked; unfortunately it's not enough supported yet. It's a pity.
>
>> If yes, switching to a standard, C++-friendly class would be useful.
>> However, there are other, more useful projects available if you are
>> looking for something fun to do (and new code can use std::unordered_map
>> if you declare it supported).
>
> I'm looking for things which are limited in scope - after all, it's
> just filling in the gaps while waiting for input (e.g. on StringNG);
> in other words, I'd like to limit these activities to refactoring.

I am afraid you underestimate the complexity of properly/fully
converting hash_table into a C++ class then. I bet it requires more than
just replacing function calls with method calls.

> If
> there is any which you think should be done, let me know :)

Here are just a few candidates that do not require fiddling with complex
C++ issues, in no particular order:

* Multiple occurrences of /* TODO: remove this file as unused */

* Remove COSS (in preparation from Store API cleanup).

* Make sure Squid quits when "all workers are dead and should not be
restarted". Recent trunk code appears to get stuck there in my tests.

* src/adaptation/icap/ModXact.cc: // TODO: use HttpMsg::clone()!

* Add reply_header_add, mimicking request_header_add.

* Make sure 403 Forbidden responses to CONNECT requests do not have
Connection:keep-alive if the CONNECT request has Connection:close.

* Aggregate or, to be more precise, report once the shared memory cache
stats in mgr:storedir.

HTH,

Alex.
Received on Sun Aug 25 2013 - 16:40:12 MDT