Re: operator precedence

From	Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups	comp.lang.c
Subject	Re: operator precedence
Date	2022-04-25 22:22 -0700
Organization	A noiseless patient Spider
Message-ID	<86czh45sh3.fsf@linuxsc.com> (permalink)
References	<thought-20220408125437@ram.dialup.fu-berlin.de> <t2v61c$ej9$1@gioia.aioe.org> <86v8ux58zx.fsf@linuxsc.com> <KeC9K.123254$Kdf.96421@fx96.iad> <878rrsucd9.fsf@bsb.me.uk>

Show all headers | View raw

Ben <ben.usenet@bsb.me.uk> writes:

> 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.

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.

Back to comp.lang.c | Previous | Next — Previous 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