On 08/24/2013 12:20 PM, Kinkie wrote: > On Sat, Aug 24, 2013 at 8:04 PM, Alex Rousskov > <[email protected]> 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.
