Re: hash_table vs unordered_map

On 26/08/2013 4:39 a.m., Alex Rousskov wrote:
> 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).

You are voting for this one now instead of requesting that it stays
present? yay.

> * 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.

* copying all these small tasks into the wiki RoadMap/Tasks list :-)

Amos
Received on Mon Aug 26 2013 - 04:56:23 MDT