Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #165933

Re: operator precedence

Show all headers | View raw

scott@slp53.sl.home (Scott Lurndal) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>Guillaume <message@bottle.org> 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.

>         ...
>      }
>
> Easily extended to support an array of uint64_t
> when ROWS*COLS > sizeof(uint64_t) * BITS_PER_BYTE.

s/BITS_PER_BYTE/CHAR_BIT/?

-- 
Ben.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: operator precedence Guillaume <message@bottle.org> - 2022-04-10 20:01 +0200
  Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-10 20:34 +0100
    Re: operator precedence Guillaume <message@bottle.org> - 2022-04-11 20:52 +0200
      Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-11 21:27 +0100
        Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-14 13:38 +0200
          Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-14 14:07 +0100
            Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-18 14:00 +0200
        Re: operator precedence Guillaume <message@bottle.org> - 2022-04-15 19:28 +0200
          Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-15 19:25 +0100
            Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-18 14:12 +0200
              Re: operator precedence Kaz Kylheku <480-992-1380@kylheku.com> - 2022-04-18 16:38 +0000
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-18 19:20 +0200
                Re: operator precedence Kaz Kylheku <480-992-1380@kylheku.com> - 2022-04-19 17:40 +0000
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-19 22:41 +0200
              Re: operator precedence James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-18 23:08 -0400
                Re: operator precedence Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-25 08:40 -0700
                Re: operator precedence "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-04-25 10:35 -0700
  Re: operator precedence Vir Campestris <vir.campestris@invalid.invalid> - 2022-04-10 21:51 +0100
  Re: operator precedence Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-11 11:35 +0200
  Re: operator precedence gazelle@shell.xmission.com (Kenny McCormack) - 2022-04-11 13:53 +0000
  Re: operator precedence Guillaume <message@bottle.org> - 2022-04-11 20:36 +0200
  Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-14 13:14 +0200
  Re: operator precedence Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-25 11:10 -0700
    Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-25 20:52 +0200
      Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-25 21:18 +0100
        Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-26 15:30 +0200
          Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-26 15:58 +0100
            Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-26 21:19 +0200
              Re: operator precedence Sams Lara <samlara622@gmail.com> - 2022-04-27 02:15 +0100
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-27 09:13 +0200
                Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-27 19:43 +0100
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-28 10:09 +0200
                Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-28 10:44 +0100
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-28 11:59 +0200
                Re: operator precedence Giovanni <lsodgf0@home.net.it> - 2022-04-28 12:29 +0200
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-28 12:56 +0200
                Re: operator precedence Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-28 04:17 -0700
                Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-28 12:24 +0100
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-28 14:28 +0200
                Re: operator precedence Dan Purgert <dan@djph.net> - 2022-04-28 14:00 +0000
                Re: operator precedence Dan Purgert <dan@djph.net> - 2022-04-28 14:38 +0000
                Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-28 20:36 +0100
                Re: operator precedence Richard Harnden <richard.nospam@gmail.com> - 2022-04-28 21:22 +0100
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-29 09:43 +0200
                Re: operator precedence Kaz Kylheku <480-992-1380@kylheku.com> - 2022-04-28 20:51 +0000
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-29 10:04 +0200
                Re: operator precedence Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-29 03:01 -0700
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-29 15:02 +0200
                Re: operator precedence James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-29 10:48 -0400
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-29 17:29 +0200
            Re: operator precedence bart c <bart4858@gmail.com> - 2022-04-26 14:30 -0700
              Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-27 00:00 +0100
              Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-27 09:46 +0200
          Re: operator precedence Öö Tiib <ootiib@hot.ee> - 2022-04-27 00:10 -0700
    Re: operator precedence scott@slp53.sl.home (Scott Lurndal) - 2022-04-25 19:02 +0000
      Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-25 21:38 +0100
        Re: operator precedence Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-25 22:22 -0700

csiph-web