Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: operator precedence Date: Mon, 25 Apr 2022 22:22:32 -0700 Organization: A noiseless patient Spider Lines: 74 Message-ID: <86czh45sh3.fsf@linuxsc.com> References: <86v8ux58zx.fsf@linuxsc.com> <878rrsucd9.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="e7f354bf3c65e91fece722955444236f"; logging-data="24974"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/26P0MUwr2da9nNivNQt9sVweN4CaCPNk=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:hu7Qfr1x0Hfi4ggdsoWMX8VGHJw= sha1:zi1Hz5b1BFgF140DJzQvd8itcH8= Xref: csiph.com comp.lang.c:165937 Ben writes: > scott@slp53.sl.home (Scott Lurndal) writes: > >> Tim Rentsch writes: >> >>> Guillaume writes: >>> >>>> Le 08/04/2022 at 14:00, Stefan Ram a ecrit: >>>> >>>>> Recently, I wrote: >>>>> >>>>> board & 1 << row * COLS + col >>>> >>>> If I saw this coming from someone in my team, I would probably >>>> fire them. =) >>>> >>>> I'm not even sure this is correct from what you really intended. >>>> But even if it is, there's a rule in programming, IMO, that's >>>> above the programming language's grammar: readability for us >>>> humans. >>>> >>>> Code we write is meant for humans, not machines. That's something >>>> people forget way too often. That's why we write using higher-level >>>> languages, not assembly or even machine code. Or, look at the >>>> obfuscated C contest and such. This is proper C from a language >>>> standpoint, but nothing you'd want to deal with. >>>> >>>> The readability rule that applies here is, if you need more than >>>> a few seconds figuring out what a given statement exactly does, >>>> and may have to even open the C standard to make sure, then it's >>>> badly written. Rewrite it. >>> >>> Human readability can be improved as follows: >>> >>> board & 1 << row*COLS+col >> >> Or, >> >> inline _Bool >> test_bit(uint64_t qword, size_t bitnum) >> { >> return (_Bool) (qword & (1ul << bitnum)) != 0; >> } > > But this makes me wonder why uint64_t and not uint_least64_t. Do > you really need no more than 64 bits? And why 1ul rather than > UINT64_C(1) (or (uint64_t)1)? > > And what is going on with the cast, the != and the return value > conversion? Why does an integer value have to explicitly cast to > _Bool before testing for non-zero, but the integer result (albeit > now 0 or 1) can be implicitly converted to the _Bool return type? > This would make me cautious about other code, especially if I were > porting to some new C compiler. It looks like code that's been > copied and edited. > >> if (test_bit(board, row*COLS+col)) { > > I'd rather bit_is_set(...) since test_bit is agnostic about which > way the test goes. In the case of bits I know one is almost always > testing for set and not clear, but I like to stick to this habit. Your comments cover most of what I was going to say. To add one more thought, the function definition can be simplified: inline _Bool bit_is_set( uintmax_t bits, unsigned n ){ return bits>>n & 1; } This definition is for me easier to take in and understand than how test_bit() is defined. Of course other people may have other impressions.