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
<[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).
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
