On 31/05/2026 03:37, Janis Papanagnou wrote:To me, the precedence is as clear as the structure. That's not theOn 2026-05-31 01:43, Keith Thompson wrote:Bart <bc@freeuk.com> writes:[...]This is an example of how readability depends on the reader. To me, there is no benefit in having a sub-expression here because the structure is clear - this is how you do table-based crc's with 4-bit chunks.>If not, people can choose to ignore those them when writing C code,>
for example like this where all () are technically superfluous:
>
crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];
Yes, they can, and I personally tend to agree that they should.
The more complex the expressions are the more structure they need.
>
IMO, the parenthesis above make precedence clear (if unknown!), but
are not contributing to readability. It would have made more sense
to separate the sub-expression within the [...] in an own object to
enhance readability and to more easily understand what's going on.
>
To emphasize; not the precedences are the problem above, but the
complexity of the expression in connexion with lack of structuring.
>
issue I see with that expression.
It's the overloaded expression that is what makes it "unreadable".
(It's actually similar to those overloaded expressions that we saw
in another recent sub-/thread about color-conversions.)
But to someone unfamiliar with CRC calculations, splitting the expression up might make it clearer. (Alternatively, a comment block with an explanation could help.)And that has also nothing to do neither with table-based algorithms
(which are a triviality) nor with the CRC (or other) coding-programs.
(Note that I'm saying that as someone who has implemented a lot of
such things, various CRCs, directly calculated and table-based, and
a lot much more demanding coding software than these simple CRCs.)
I /do/ think the parentheses here are helpful for readability, precisely because they emphasise the structure of the expression. You could write:Yes, I recognize that in that example the parentheses help combining
crcu32 = crcu32 >> 4 ^ s_crc32[crcu32 & 0xF ^ b & 0xF];
but that needs significantly more cognitive effort to parse when reading it, could be misinterpreted, and has lost all the structure that makes it easy to see what is going on.
parts. (But as said, I see the primary problem in the complexity of
the expression.)
(I regularly use bit-manipulation and shift instructions in my code - but I still felt it best to check the details in a precedence table before writing that.)Agreed.
The expression as originally parenthesised is thus definitely easier for /me/ to read, and is almost exactly the way I would write it myself :Acknowledged.
crcu32 = (crcu32 >> 4) ^ s_crc32[(crcu32 & 0xF) ^ (b & 0xF)];
The only differences I would have are the names (why would anyone put variable types into the names like "crcu32" ?Given the more obvious problem I see with that expression I hadn't
commented on that; but you are right and I certainly agree.
The coding algorithms that I implemented had always been just plain
straight ("unsigned") registers. (So there's no need to reflect that
property in the names of such variable.)
We are not writing BASIC), and I'd use a small case "0xf". Unlike almost every example Bart has shown before, it even has nice spacing!I'm not that picky with the hexadecimal constants it seems; I seem to
use both forms, depending on subjective readability in the respective
context. A quick glimpse into my table-driven CRC C-code shows that I
used lower-case, and that seems generally to be the prevalent form.[*]
Janis
[*] Anecdotally: lowercase tables may have their issues though; once
I had implemented a DES-3 algorithm, which was full of tabular data.
(That was at times when we could obtain standards only as paper.)
My code failed against my tests in about 30% of the test cases. The
reason of the problem was a single table entry 'db' vs. 'bd' (or vv.)
It was a horror to find that typo in that huge stack of table data;
somehow it was difficult to find that even after having read several
times across all that constant data. I'm not sure the same could have
happened with uppercase, though...
Les messages affichés proviennent d'usenet.