[squid-dev] [CODE] iterating over enums

[Alex Rousskov]

On 08/05/2015 09:33 AM, Kinkie wrote:

> I crossed the topic of enumerating over iterations. 

You mean iterating enum[eration]s :-)


> We kind-of follow (C-ish)best
> practices on that, but that got me wondering if we can do better.
> I came up with a trinket which on its face looks quite elegant to me,
> and I'd like to understand with you guys if it makes sense to deploy it
> in our code. 

Maybe, after quite a few changes. It is risky for me to review this
because the problems in the posted code lie on several very different
layers, the code is outside Squid context, and I am not even sure what
[CODE] thread designation means. I hope this does not lead to a long
discussion, but here are a few things to consider:

* Iterating enums under Squid control ought to be a lot easier, safer,
and cheaper because we can add begin/end markers *with standard names*
to each enum. This is important because most iterations iterate
everything _and_ C++11 range loops always iterate everything. The
"everything" case is worth focusing on! See attached files for examples
of how standardized begin/end marks can be used.

* Your Iterator class is mixing two very different interfaces/APIs: One
provides begin/end() methods and is required for range loops (I do not
know how this API is called in the C++ standard). The other one is a
[partial] iterator API. Do not mix those two APIs! Each of the attached
files illustrates how to separate them (and there are two ways to
implement the second/iterator API).

* The stand-alone iterator API implementation in
t-enum-stand-alone-v3.cc allows for nice explicit for-loops and such,
but those global operators are rather invasive, and I am worried they
will cause problems in Squid context (as opposed a tiny test file!). I
recommend that you start with t-enum-v3.cc and then diff the two
attached files to see changes related to the stand-alone iterator API
implementation. If you really like stand-alone operator side-effects,
you may want to investigate whether they would work well in Squid context.

* Avoid static variables in templates, especially when you want to
instantiate different templates based on such trivial things as range
boundaries. This is (or used to be?) one of the dark C++ corners; they
might hurt inlining/performance as well.


The attached files are unpolished, but should illustrate the above
points and how to avoid some of the problems discussed here.


HTH,

Alex.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: t-enum-stand-alone-v3.cc
Type: text/x-c++src
Size: 2480 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-dev/attachments/20150805/5c40593c/attachment.cc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t-enum-v3.cc
Type: text/x-c++src
Size: 2653 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-dev/attachments/20150805/5c40593c/attachment-0001.cc>