Re: [lmi] [PATCH] C++ m11n: range-based for loops

[Vadim Zeitlin]

On Sun, 15 Jan 2017 17:59:34 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-01-15 15:28, Vadim Zeitlin wrote:
...
GC> >  The only other thing I might change here would be the name of the loop
GC> > variable as "i" evokes either an index (thanks, Fortran) or an iterator
GC> > while this one is neither and so should rather be called something like
GC> > "choice_value" IMHO.
GC> 
GC> There's no standard term: I think of it as a "not-an-iterator", or a
GC> "dereferenced iterator", or a "traverser". But it does model the Iterator
GC> design pattern, and therefore I still prefer names like 'i' and 'j'.

 I disagree, I think an iterator [in C++] is something that must be
dereferenced to yield a value (hence a pointer is an example of an
iterator), while here we iterate over the values directly. And this is
exactly why I think it's useful to distinguish between the two cases: we
should be seeing "*i" in the code, but not "*x".

GC> - Not applied, as explained below.
GC> 
GC> -crc32.cpp
GC> Second patch not applied. Reason: I think this function is easier to
GC> read if all three for loops in this function are left as classic C,
GC> instead of changing one of them to the C++11 dialect.

 Hmm, but the new loop is so much shorter and more readable (especially
without using a usual simplifying macro, "sizeof p / sizeof(int)" is really
unwieldy IMO). Looking at it further, I actually think it wouldn't be a bad
idea to replace the second loop with something like

        i = 0;
        for(auto& elem: crc_arrray)
            {
            if(i++ == 0)
                continue; // crc_arrray[0] not initialized??
            ...
            elem = c;
            }

 Of course, all this code is pretty weird: why do we have a static
crc_arrray and then a static crc_vector and then a static "v" in
crc_table() again? It seems it would be more than enough to have just a
single static variable.

VZ