Re: hash_table vs unordered_map

On 08/25/2013 10:56 PM, Amos Jeffries wrote:
> 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.

I think COSS removal should be done just before the Store API cleanup.
Since the latter should start as soon as Collapsed Forwarding is in,
there is no compelling reason to delay the former now.

Alex.
Received on Mon Aug 26 2013 - 15:16:30 MDT