Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #399456 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2026-05-27 19:53 +0200 |
| Last post | 2026-05-30 11:18 +0200 |
| Articles | 20 on this page of 172 — 17 participants |
Back to article view | Back to comp.lang.c
this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 19:53 +0200
Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 20:15 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-27 18:49 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 04:53 +0000
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 02:35 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:32 +0000
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 20:07 -0500
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-28 11:48 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-28 09:18 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 04:57 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:35 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:52 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 05:20 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-29 13:22 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 15:16 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 13:52 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-30 14:40 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 16:36 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-30 15:48 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:14 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-31 13:25 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:14 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 15:22 +0200
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-30 03:49 +0000
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-28 12:47 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:56 +0200
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-29 11:00 -0700
Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-28 17:12 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 14:07 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:54 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 10:02 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 12:19 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 14:46 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 14:22 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 17:15 +0200
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-05-29 15:59 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:12 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:48 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 19:09 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:00 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:14 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:05 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:34 +0200
Re: this girl calls c ugly tTh <tth@none.invalid> - 2026-05-29 19:29 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 18:53 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:28 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 20:49 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:03 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 13:56 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:54 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 15:52 -0700
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-29 20:31 -0400
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 02:03 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 19:02 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 12:12 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-30 12:29 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 13:56 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 16:43 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-31 03:37 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 19:53 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:16 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:47 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:55 +0200
Re: this girl calls c ugly Richard Harnden <richard.nospam@gmail.invalid> - 2026-05-31 09:12 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:49 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 11:10 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 13:18 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 10:24 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 17:35 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 12:46 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:24 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 18:26 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:28 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 15:54 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:39 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:33 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:48 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-02 06:37 -0400
Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 05:06 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:28 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:35 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 06:29 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 16:10 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:29 -0700
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-02 13:59 -0700
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 13:05 +0000
Parentheses (was: this girl calls c ugly) Bart <bc@freeuk.com> - 2026-06-02 14:38 +0100
Re: Parentheses (was: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:19 +0000
[OT] Fancy graphics (was Re: this girl calls c ugly) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 15:54 +0200
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Bart <bc@freeuk.com> - 2026-06-02 15:19 +0100
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:19 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 17:39 +0200
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:36 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 21:33 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-06-02 14:43 -0700
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-02 17:08 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 19:19 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:39 -0700
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-03 13:14 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 15:10 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:31 +0000
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 10:15 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 16:29 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 03:45 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 04:02 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 09:04 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 18:11 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-31 19:34 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 19:10 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 11:12 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:36 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 14:26 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 09:52 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:42 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:50 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 11:47 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:55 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 14:39 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 15:11 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 08:41 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 02:07 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:38 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:01 -0700
It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:39 +0000
Re: It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:42 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 11:46 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 11:09 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:25 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 14:20 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 15:12 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 04:16 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-01 15:23 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 16:06 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 23:24 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:35 +0200
Operator precedence in other (non-C, but "C-like") languages (Was: something about a girl) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:36 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 11:04 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 14:04 +0200
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 18:48 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 21:04 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:17 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:09 +0200
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 12:07 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 14:37 +0200
Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 15:06 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-31 19:11 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 16:08 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 16:32 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 17:12 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 14:07 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:10 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 19:18 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:17 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 21:47 +0100
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-29 15:57 -0400
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:34 +0200
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-29 23:18 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 01:26 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-30 04:25 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 12:01 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-31 00:29 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 10:59 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-01 00:33 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 02:26 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 13:24 +0200
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-29 08:09 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 04:15 -0500
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-29 14:58 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-30 01:04 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-29 23:20 +0000
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-30 11:18 +0200
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-02 08:41 +0200 |
| Message-ID | <10vltvd$2ne3j$1@dont-email.me> |
| In reply to | #399596 |
On 02/06/2026 00:11, Keith Thompson wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > [...] >> I vaguely recall that there's some language that uses the ?: syntax >> for the conditional operator, but with a different precedence and/or >> associativity than C. I can't remember which language it is. > > The language I was thinking of is PHP. C's ?: operator associates > right-to-left, which makes it possible to write chained conditional > expressions like: > > cond1 ? expr1 : > cond2 ? expr2 : > cond3 ? expr3 : > default_expr > > PHP's ?: operator originally associated right-to-left. > Newer versions of PHP require parentheses. > I thought you were thinking of C++, where ? has the same precedence as assignment, while in C it has higher precedence. It does not make a lot of difference, and if you are writing an expression where it matters, then I think parentheses would be a good idea. <https://cppreference.com/c/language/operator_precedence> <https://cppreference.com/cpp/language/operator_precedence>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-02 02:07 -0700 |
| Message-ID | <10vm6h4$2qdor$1@kst.eternal-september.org> |
| In reply to | #399601 |
David Brown <david.brown@hesbynett.no> writes:
> On 02/06/2026 00:11, Keith Thompson wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> [...]
>>> I vaguely recall that there's some language that uses the ?: syntax
>>> for the conditional operator, but with a different precedence and/or
>>> associativity than C. I can't remember which language it is.
>>
>> The language I was thinking of is PHP. C's ?: operator associates
>> right-to-left, which makes it possible to write chained conditional
>> expressions like:
>> cond1 ? expr1 :
>> cond2 ? expr2 :
>> cond3 ? expr3 :
>> default_expr
>> PHP's ?: operator originally associated right-to-left.
>> Newer versions of PHP require parentheses.
>
> I thought you were thinking of C++, where ? has the same precedence as
> assignment, while in C it has higher precedence. It does not make a
> lot of difference, and if you are writing an expression where it
> matters, then I think parentheses would be a good idea.
>
> <https://cppreference.com/c/language/operator_precedence>
> <https://cppreference.com/cpp/language/operator_precedence>
Hmm. I'm not sure I either follow or trust those tables.
Looking at the grammar in the C++ standard, there is a difference.
C has:
conditional-expression:
logical-OR-expression
logical-OR-expression ? expression : conditional-expression
while C++ has:
conditional-expression:
logical-or-expression
logical-or-expression ? expression : assignment-expression
But the difference isn't mentioned in the Compatibility annex of the C++
standard.
I'd be interested in seeing a conditional expression whose legality or
semantics differs between C and C++.
(Digression: I hate the fact that such a long and sometimes
informative thread has such a stupid subject header.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-02 11:38 +0200 |
| Message-ID | <10vm8au$3uus8$11@dont-email.me> |
| In reply to | #399604 |
On 2026-06-02 11:07, Keith Thompson wrote: > [...] > > (Digression: I hate the fact that such a long and sometimes > informative thread has such a stupid subject header.) And what did prevent you from changing it? :-} Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-02 05:01 -0700 |
| Message-ID | <10vmgn2$2tjoi$1@kst.eternal-september.org> |
| In reply to | #399606 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-06-02 11:07, Keith Thompson wrote:
>> [...]
>> (Digression: I hate the fact that such a long and sometimes
>> informative thread has such a stupid subject header.)
>
> And what did prevent you from changing it? :-}
Futility. At best, I could start a new subthread. The existing
subject line would live on.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2026-06-02 12:39 +0000 |
| Subject | It is not futile to change the subject line (Was: this girl calls c ugly) |
| Message-ID | <10vmitc$o9ge$2@news.xmission.com> |
| In reply to | #399614 |
In article <10vmgn2$2tjoi$1@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 2026-06-02 11:07, Keith Thompson wrote: >>> [...] >>> (Digression: I hate the fact that such a long and sometimes >>> informative thread has such a stupid subject header.) >> >> And what did prevent you from changing it? :-} > >Futility. At best, I could start a new subthread. The existing >subject line would live on. See. That wasn't so hard, was it? I maintain that there are several good reasons why changing the Subject line is a good thing. Many other people disagree with me, but I don't care about that. It is, as you imply, especially a good idea where, as here, the original (i.e., carried) Subject line is dumb. -- I shot a man on Fifth Aveneue, just to see him die.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2026-06-02 12:42 +0000 |
| Subject | Re: It is not futile to change the subject line (Was: this girl calls c ugly) |
| Message-ID | <10vmj31$o9ge$3@news.xmission.com> |
| In reply to | #399621 |
In article <10vmitc$o9ge$2@news.xmission.com>,
Kenny McCormack <gazelle@shell.xmission.com> wrote:
...
>I maintain that there are several good reasons why changing the Subject
>line is a good thing. Many other people disagree with me, but I don't care
>about that.
>
>It is, as you imply, especially a good idea where, as here, the original
>(i.e., carried) Subject line is dumb.
Oh, and please read this, which I recently composed on the subject:
3 Reasons Why People Don't Change Subject Lines
1) Because they don't know how (and can't be bothered to learn). Or,
eqv, that whatever crappy newsreader they are using makes it difficult
or impossible to do so.
2) Because they think it is a violation of netiquette to do so. I.e.,
they think it "breaks" the thread". The theory is that doing so creates
problems for people who use poor newsreaders.
3) Because they get a perverse thrill out of keeping an old, totally
inappropriate thread title, when they clearly know better.
--
Many people in the American South think that DJT is, and will be remembered
as, one of the best presidents in US history. They are absolutely correct.
He is currently at number 46 on the list. High praise, indeed!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-02 11:46 +0200 |
| Message-ID | <10vm8ps$2ne3j$5@dont-email.me> |
| In reply to | #399604 |
On 02/06/2026 11:07, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 02/06/2026 00:11, Keith Thompson wrote: >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>> [...] >>>> I vaguely recall that there's some language that uses the ?: syntax >>>> for the conditional operator, but with a different precedence and/or >>>> associativity than C. I can't remember which language it is. >>> >>> The language I was thinking of is PHP. C's ?: operator associates >>> right-to-left, which makes it possible to write chained conditional >>> expressions like: >>> cond1 ? expr1 : >>> cond2 ? expr2 : >>> cond3 ? expr3 : >>> default_expr >>> PHP's ?: operator originally associated right-to-left. >>> Newer versions of PHP require parentheses. >> >> I thought you were thinking of C++, where ? has the same precedence as >> assignment, while in C it has higher precedence. It does not make a >> lot of difference, and if you are writing an expression where it >> matters, then I think parentheses would be a good idea. >> >> <https://cppreference.com/c/language/operator_precedence> >> <https://cppreference.com/cpp/language/operator_precedence> > > Hmm. I'm not sure I either follow or trust those tables. cppreference.com is normally very accurate - it is linked from the isocpp.org website and AFAIUI maintained or checked by people involved in the C++ standards. Mistakes here are definitely something that should be taken seriously. > > Looking at the grammar in the C++ standard, there is a difference. > C has: > > conditional-expression: > logical-OR-expression > logical-OR-expression ? expression : conditional-expression > > while C++ has: > > conditional-expression: > logical-or-expression > logical-or-expression ? expression : assignment-expression > > But the difference isn't mentioned in the Compatibility annex of the C++ > standard. > > I'd be interested in seeing a conditional expression whose legality or > semantics differs between C and C++. There is a little information in the "discussion" page of the C++ side linked above. An example is true ? a : b = 7; In C, the ternary operator has higher precedence than assignment and this therefore parses as : (true ? a : b) = 7; In C, the ternary operator does not return an lvalue, so this is a constraint error. In C++, the precedence of ternary and assignment are the same, with right-to-left associativity, so this is parsed as : true ? a : (b = 7) and evaluates as the value of "a", leaving "b" untouched. I am not confident enough in my standardese, especially for C++, to judge if the above explanation is correct according to the standards. But a quick test on godbolt shows that both gcc and clang follow that line of reasoning. (It is possible that they are both wrong, but that would be surprising.) The difference in precedences here is, I think, related to the ternary operator being able to evaluate to an lvalue in C++ but not in C - and that /is/ mentioned in the C++ compatibility annex. > > (Digression: I hate the fact that such a long and sometimes > informative thread has such a stupid subject header.) > Agreed.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-02 11:09 +0100 |
| Message-ID | <10vma48$2rcbn$1@dont-email.me> |
| In reply to | #399607 |
On 02/06/2026 10:46, David Brown wrote: > On 02/06/2026 11:07, Keith Thompson wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> On 02/06/2026 00:11, Keith Thompson wrote: >>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>>> [...] >>>>> I vaguely recall that there's some language that uses the ?: syntax >>>>> for the conditional operator, but with a different precedence and/or >>>>> associativity than C. I can't remember which language it is. >>>> >>>> The language I was thinking of is PHP. C's ?: operator associates >>>> right-to-left, which makes it possible to write chained conditional >>>> expressions like: >>>> cond1 ? expr1 : >>>> cond2 ? expr2 : >>>> cond3 ? expr3 : >>>> default_expr >>>> PHP's ?: operator originally associated right-to-left. >>>> Newer versions of PHP require parentheses. >>> >>> I thought you were thinking of C++, where ? has the same precedence as >>> assignment, while in C it has higher precedence. It does not make a >>> lot of difference, and if you are writing an expression where it >>> matters, then I think parentheses would be a good idea. >>> >>> <https://cppreference.com/c/language/operator_precedence> >>> <https://cppreference.com/cpp/language/operator_precedence> >> >> Hmm. I'm not sure I either follow or trust those tables. > > cppreference.com is normally very accurate - it is linked from the > isocpp.org website and AFAIUI maintained or checked by people involved > in the C++ standards. Mistakes here are definitely something that > should be taken seriously. > >> >> Looking at the grammar in the C++ standard, there is a difference. >> C has: >> >> conditional-expression: >> logical-OR-expression >> logical-OR-expression ? expression : conditional-expression >> >> while C++ has: >> >> conditional-expression: >> logical-or-expression >> logical-or-expression ? expression : assignment-expression >> >> But the difference isn't mentioned in the Compatibility annex of the C++ >> standard. >> >> I'd be interested in seeing a conditional expression whose legality or >> semantics differs between C and C++. > > There is a little information in the "discussion" page of the C++ side > linked above. An example is > > true ? a : b = 7; > > In C, the ternary operator has higher precedence than assignment and > this therefore parses as : > > (true ? a : b) = 7; > > In C, the ternary operator does not return an lvalue, so this is a > constraint error. > > In C++, the precedence of ternary and assignment are the same, with > right-to-left associativity, so this is parsed as : > > true ? a : (b = 7) > > and evaluates as the value of "a", leaving "b" untouched. > > I am not confident enough in my standardese, especially for C++, to > judge if the above explanation is correct according to the standards. > But a quick test on godbolt shows that both gcc and clang follow that > line of reasoning. (It is possible that they are both wrong, but that > would be surprising.) > > The difference in precedences here is, I think, related to the ternary > operator being able to evaluate to an lvalue in C++ but not in C - and > that /is/ mentioned in the C++ compatibility annex. I was surprised that there would be such a subtle difference given that the languages are that close; there are totally unrelated languages that slavishly follow C precedence rules more closely! But the behaviour only seems to vary in code that would be invalid in C anyway (unbracketed ?: term on LHS of '=' operator). Your table however also shows || had same precedence as both ?: and =. There, I couldn't find an example that made a difference. Still, I'd find that unsettling; I would rather that ?: was distinct from bother, either with its own level, or via other language rules. (In my stuff it is always written with parentheses.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-02 05:25 -0700 |
| Message-ID | <10vmi4h$2tjoi$2@kst.eternal-september.org> |
| In reply to | #399609 |
Bart <bc@freeuk.com> writes:
[...]
>>> David Brown <david.brown@hesbynett.no> writes:
[...]
>>>> <https://cppreference.com/c/language/operator_precedence>
>>>> <https://cppreference.com/cpp/language/operator_precedence>
[...]
> Your table however also shows || had same precedence as both ?: and
> =. There, I couldn't find an example that made a difference.
>
> Still, I'd find that unsettling; I would rather that ?: was distinct
> from bother, either with its own level, or via other language
> rules. (In my stuff it is always written with parentheses.)
I think you're misreading the table due to its poor formatting.
In the C++ table (second URL above), the precedence levels are
numbered from 1 to 17, but the number in the first column is aligned
to the *middle* of the list of operators in the second column.
So level 15 is just "a || b", and level 16 goes from "a ? b : c" to
"a &= b a ^= b a |= b". You can tell where the level 16 section
starts by the "Right-to-left" associativity in the last column,
which is aligned with the *first* item in the list. I've submitted
a suggestion to fix it (and then saw that someone else had already
done so), but apparently cppreference.com is being hit by vandalism,
so it might take a while before it's corrected.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-02 14:20 +0100 |
| Message-ID | <10vmlaf$2utb2$1@dont-email.me> |
| In reply to | #399617 |
On 02/06/2026 13:25, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > [...] >>>> David Brown <david.brown@hesbynett.no> writes: > [...] >>>>> <https://cppreference.com/c/language/operator_precedence> >>>>> <https://cppreference.com/cpp/language/operator_precedence> > [...] >> Your table however also shows || had same precedence as both ?: and >> =. There, I couldn't find an example that made a difference. >> >> Still, I'd find that unsettling; I would rather that ?: was distinct >> from bother, either with its own level, or via other language >> rules. (In my stuff it is always written with parentheses.) > > I think you're misreading the table due to its poor formatting. > > In the C++ table (second URL above), the precedence levels are > numbered from 1 to 17, but the number in the first column is aligned > to the *middle* of the list of operators in the second column. > So level 15 is just "a || b", and level 16 goes from "a ? b : c" to > "a &= b a ^= b a |= b". You can tell where the level 16 section > starts by the "Right-to-left" associativity in the last column, > which is aligned with the *first* item in the list. I've submitted > a suggestion to fix it (and then saw that someone else had already > done so), but apparently cppreference.com is being hit by vandalism, > so it might take a while before it's corrected. > You're right, it is a confusing layout. But it might explain why I couldn't find different behaviours between C/C++ in my examples involving || and ?:.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-02 15:12 -0700 |
| Message-ID | <10vnkgp$382un$1@kst.eternal-september.org> |
| In reply to | #399617 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>>>> David Brown <david.brown@hesbynett.no> writes:
[...]
>>>>> <https://cppreference.com/c/language/operator_precedence>
>>>>> <https://cppreference.com/cpp/language/operator_precedence>
[...]
Both tables are now much clearer. Someone added dividing lines
between the precedence levels.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-02 04:16 -0700 |
| Message-ID | <86mrxdchun.fsf@linuxsc.com> |
| In reply to | #399604 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: [syntax for conditional expressions] > Looking at the grammar in the C++ standard, there is a difference. > C has: > > conditional-expression: > logical-OR-expression > logical-OR-expression ? expression : conditional-expression > > while C++ has: > > conditional-expression: > logical-or-expression > logical-or-expression ? expression : assignment-expression > > But the difference isn't mentioned in the Compatibility annex of the > C++ standard. Like I have said before, there are lots of differences between C and C++ that aren't mentioned in the Compatibility annex of the C++ standard. It isn't surprising to find another one.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-06-01 15:23 -0700 |
| Message-ID | <86qzmpdho2.fsf@linuxsc.com> |
| In reply to | #399595 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > The "and" macro in <iso646.h> is exactly equivalent to "||". I don't think so.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-01 16:06 -0700 |
| Message-ID | <10vl3ad$2id47$1@kst.eternal-september.org> |
| In reply to | #399598 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> The "and" macro in <iso646.h> is exactly equivalent to "||".
>
> I don't think so.
Right, that was a typo/thinko.
The "and" macro is (almost) exactly equivalent to "&&".
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-01 23:24 +0100 |
| Message-ID | <10vl0q8$2hmnd$1@dont-email.me> |
| In reply to | #399595 |
On 01/06/2026 22:39, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 01/06/2026 08:52, David Brown wrote: > [...] >>> That still leaves extra parentheses around the equality operators, >>> but the decision to keep or remove them is subjective (as is the >>> choice of "pData1 == NULL" vs. "!pData1"). >> >> Maybe it's due to || being a symbol; compare: >> >> if (pData1 == NULL || pData2 == NULL || Length == 0U) >> >> if (pData1 == NULL or pData2 == NULL or Length == 0U) >> >> To me, || seems to draw in the terms on either side as strongly as >> ==. That happens less using 'or'. >> >> (Both are valid C if using iso646.h.) > > The "and" macro in <iso646.h> is exactly equivalent to "||". I don't think so. > If your intuition tells you they have different precedences, that > could be a problem. I'm not saying that, just that having a named operators helps to separate that expression into three groups better than a symbolic operator. At least for me.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-02 11:35 +0200 |
| Message-ID | <10vm85t$3uus8$10@dont-email.me> |
| In reply to | #399599 |
On 2026-06-02 00:24, Bart wrote:
> On 01/06/2026 22:39, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 01/06/2026 08:52, David Brown wrote:
>> [...]
>>>> That still leaves extra parentheses around the equality operators,
>>>> but the decision to keep or remove them is subjective (as is the
>>>> choice of "pData1 == NULL" vs. "!pData1").
>>>
>>> Maybe it's due to || being a symbol; compare:
>>>
>>> if (pData1 == NULL || pData2 == NULL || Length == 0U)
>>>
>>> if (pData1 == NULL or pData2 == NULL or Length == 0U)
>>>
>>> To me, || seems to draw in the terms on either side as strongly as
>>> ==. That happens less using 'or'.
>>>
>>> (Both are valid C if using iso646.h.)
[...]
>> [...]
>
> I'm not saying that, just that having a named operators helps to
> separate that expression into three groups better than a symbolic operator.
>
> At least for me.
I suppose because, as words, they stand out, are easier to distinguish,
especially in that mass of in "C" existing punctuation characters, and
psychologically suggest their dominance? - Yes, maybe.[*] - But don't
count on such "perception logic"; you generally won't get happy.[**]
Janis
[*] In the above quoted example where there's identifiers around the
operators it appears to me that the 'and'/'or' variants would be worse,
though, concerning visual perceivability.
It would certainly be different if the example had used numbers, like
if ( pData1 == 0 || pData2 == 0 || Length == 0 )
or the '!var' variant (for those who prefer that)
if ( !pData1 || !pData2 || !Length )
[**] For example, with Pascal. While that language has only very few
precedence groups - as you said you'd prefer fewer to many groups! -
they put the 'and' together with arithmetic * and / , and the 'or'
together with + and - . Given that all the comparisons are in the
lowest precedence group you will have to use parenthesis, say, for
'a < b && c == d' (in "C") would be '(a < b) and (c = d)' (in Pascal).
The keyword didn't help given the precedence groups' design with only
few precedence groups [in Pascal].
Back these days, that demand of parenthesis sightly annoyed me, since I
thought (and still think) that the boolean keywords would sufficiently
hint on the semantic intention, and with more precedence levels in the
language design they could easily have simplified those common cases.
To each [language] its own [flaw].
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2026-06-02 12:36 +0000 |
| Subject | Operator precedence in other (non-C, but "C-like") languages (Was: something about a girl) |
| Message-ID | <10vmio9$o9ge$1@news.xmission.com> |
| In reply to | #399595 |
In article <10vku5o$2glfs$2@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: ... >Digression: Perl borrows most or all of C's operators, and keeps >the same precedences. "Operators borrowed from C keep the same >precedence relationship with each other, even where C's precedence >is slightly screwy." But Perl has "and" and "or" operators that >work like "&&" and "||" but have lower precedence (that turns out >to be convenient in some contexts). > >I vaguely recall that there's some language that uses the ?: syntax >for the conditional operator, but with a different precedence and/or >associativity than C. I can't remember which language it is. (It turns out it was PHP that you were thinking of) There is another language that claims to be C-like in terms of its operators and functions (although its overall syntax and reason for existence are completely not like C), but which has the quirk that || and && work like in C, except that they don't do "short circuit" evaluation. Both sides of the operator are always evaluated. Working in this language, I found this lack of short-circuit jarring, but when I mentioned it on the support board (for this particular language), they had no idea what I was talking about... And that language is: WinBatch. -- Men rarely (if ever) manage to dream up a God superior to themselves. Most Gods have the manners and morals of a spoiled child.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-01 11:04 +0000 |
| Message-ID | <10vjp02$6dk$1@reader1.panix.com> |
| In reply to | #399582 |
In article <10vjdn8$22tgu$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: >On 31/05/2026 19:11, Bart wrote: >> On 31/05/2026 17:04, Tim Rentsch wrote: >>> Richard Harnden <richard.nospam@gmail.invalid> writes: >>> >>>> just write complex expressions in a way that a human can most >>>> easily understand, >>> >>> Unfortunately, (1) different people have different ideas of what >>> writing is most easily understood, and (2) different readers have >>> different notions of which writings are easily understood, and >>> which writings are not so easily understood. To make things >>> worse "easily understood" is not a boolean condition, nor is it >>> necessarily well-ordered -- "most easily understood" isn't always >>> a well-defined quality, even for a given audience. >>> >>> Sadly the idea of writing in a way that is "most easily understood" >>> has resulted in a race to the bottom, where writers are more and >>> more encouraged to take the view that (some) readers are pretty >>> much arbitrarily stupid, with the result that expressions become >>> littered with scads of unnecessary parentheses that actually >>> detract from ease of reading. Good writing is always a balance >>> between too much and too little. >> >> Actual examples of too many parentheses? > >Any source code written in LISP :-) Hey now. Some of us have programmed in Lisp professionally, and rather enjoy it. Lisp is often maligned for its parentheses; I don't think that's fair. They really aren't that onorus once you start working in it, and they're unambiguous; one may of the structure of Lisp code as a shorthand notation for the resulting program's AST. >(And for too few parentheses, any source code in Forth.) No comment. > From a quick grep of an SDK in a project I am working on, I saw this >example : > > if ((((pData1 == NULL) || (pData2 == NULL))) || (Length == 0U)) > >The number of parentheses there is so high it's hard to see that not >only is there an unnecessary extra parentheses for the first || >operator, but there is a second set of extra parentheses around it. >Eliminating these would give : > > if ((pData1 == NULL) || (pData2 == NULL) || (Length == 0U)) > >or, with an extra space for clarity, > > if ( (pData1 == NULL) || (pData2 == NULL) || (Length == 0U) ) > >That still leaves extra parentheses around the equality operators, but >the decision to keep or remove them is subjective (as is the choice of >"pData1 == NULL" vs. "!pData1"). > >But IMHO, the original line had at least two sets of completely >redundant and unhelpful parentheses which made it harder to read - the >reader is left wondering whether these parentheses are there for a >purpose and have an effect on what should have been a simple and clear >expression. I see code like this all the time; usually it comes from hardware vendors (I take it this was from a BSP or something similar?). I often wonder about vendor programming standards when I run across things like it. >The SDK also contains examples of parentheses used because it mixes >relatively rare operators (shifts and binary operators). Parentheses >around such sub-expressions are not uncommon, and can definitely be >helpful, but the quantity here makes things hard to read. Ironically, >though it is a macro, there are not "safety" parentheses around the >argument in the expression. > >And yes, these really are the names of the macro in this code. > >#define CONVERTARGB88882ARGB4444(Color) \ > ((((Color & 0xFFU) >> 4) & 0xFU) |\ > (((((Color & 0xFF00U) >> 8) >> 4) & 0xFU) << 4) |\ > (((((Color & 0xFF0000U) >> 16) >> 4) & 0xFU) << 8) | \ > (((((Color & 0xFF000000U) >> 24) >> 4) & 0xFU) << 12)) > >#define CONVERTRGB5652ARGB8888(Color) \ > (((((((Color >> 11) & 0x1FU) * 527) + 23) >> 6) << 16) |\ > ((((((Color >> 5) & 0x3FU) * 259) + 33) >> 6) << 8) |\ > ((((Color & 0x1FU) * 527) + 23) >> 6) | 0xFF000000) > >It can be argued that the parentheses themselves are not the problem >here - it is doing too much in one expression. Static inline functions >would make things clearer, as would a separation of the steps of >breaking down the original colour format into parts, scaling or >conversions, then building up the new colour format. Different named >types for the different formats would go a long way towards usability >and safety - at least using typedefs, but preferably using structs to >make real different types. And surely nicer names could have been found! Not to mention symbolic names for the magic constants. :-/ This is exactly the sort of thing that, as you point out, a `static inline` function is far better suited for. Some code bases don't want to use them for a variety of reasons, usually compatibility concerns with older code, compilers, or language standards. Some variants of Unix, for instance, worry about header compatibility with C90 [and in some cases K&R C] code. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-01 14:04 +0200 |
| Message-ID | <10vjsg2$259m3$3@dont-email.me> |
| In reply to | #399590 |
On 01/06/2026 13:04, Dan Cross wrote: > In article <10vjdn8$22tgu$1@dont-email.me>, > David Brown <david.brown@hesbynett.no> wrote: >> On 31/05/2026 19:11, Bart wrote: >>> On 31/05/2026 17:04, Tim Rentsch wrote: >>>> Richard Harnden <richard.nospam@gmail.invalid> writes: >>>> >>>>> just write complex expressions in a way that a human can most >>>>> easily understand, >>>> >>>> Unfortunately, (1) different people have different ideas of what >>>> writing is most easily understood, and (2) different readers have >>>> different notions of which writings are easily understood, and >>>> which writings are not so easily understood. To make things >>>> worse "easily understood" is not a boolean condition, nor is it >>>> necessarily well-ordered -- "most easily understood" isn't always >>>> a well-defined quality, even for a given audience. >>>> >>>> Sadly the idea of writing in a way that is "most easily understood" >>>> has resulted in a race to the bottom, where writers are more and >>>> more encouraged to take the view that (some) readers are pretty >>>> much arbitrarily stupid, with the result that expressions become >>>> littered with scads of unnecessary parentheses that actually >>>> detract from ease of reading. Good writing is always a balance >>>> between too much and too little. >>> >>> Actual examples of too many parentheses? >> >> Any source code written in LISP :-) > > Hey now. Some of us have programmed in Lisp professionally, and > rather enjoy it. > > Lisp is often maligned for its parentheses; I don't think that's > fair. They really aren't that onorus once you start working in > it, and they're unambiguous; one may of the structure of Lisp > code as a shorthand notation for the resulting program's AST. > I did include a smiley - I know there are people here who enjoy working with LISP, and have probably heard a few too many jokes about parentheses! >> (And for too few parentheses, any source code in Forth.) > > No comment. > >> From a quick grep of an SDK in a project I am working on, I saw this >> example : >> >> if ((((pData1 == NULL) || (pData2 == NULL))) || (Length == 0U)) >> >> The number of parentheses there is so high it's hard to see that not >> only is there an unnecessary extra parentheses for the first || >> operator, but there is a second set of extra parentheses around it. >> Eliminating these would give : >> >> if ((pData1 == NULL) || (pData2 == NULL) || (Length == 0U)) >> >> or, with an extra space for clarity, >> >> if ( (pData1 == NULL) || (pData2 == NULL) || (Length == 0U) ) >> >> That still leaves extra parentheses around the equality operators, but >> the decision to keep or remove them is subjective (as is the choice of >> "pData1 == NULL" vs. "!pData1"). >> >> But IMHO, the original line had at least two sets of completely >> redundant and unhelpful parentheses which made it harder to read - the >> reader is left wondering whether these parentheses are there for a >> purpose and have an effect on what should have been a simple and clear >> expression. > > I see code like this all the time; usually it comes from > hardware vendors (I take it this was from a BSP or something > similar?). I often wonder about vendor programming standards > when I run across things like it. > Yes, this was from a hardware vendor (who shall remain nameless to protect the guilty - not that I have found other vendors to be much better). They have a tendency to be obsessed with MISRA, with sticking to C90, and with filling headers with huge Doxygen templates giving no information and obscuring the code. (I'm fine with Doxygen comments that actually add useful information, but not a dozen lines repeating the names and types from a function signature.) >> The SDK also contains examples of parentheses used because it mixes >> relatively rare operators (shifts and binary operators). Parentheses >> around such sub-expressions are not uncommon, and can definitely be >> helpful, but the quantity here makes things hard to read. Ironically, >> though it is a macro, there are not "safety" parentheses around the >> argument in the expression. >> >> And yes, these really are the names of the macro in this code. >> >> #define CONVERTARGB88882ARGB4444(Color) \ >> ((((Color & 0xFFU) >> 4) & 0xFU) |\ >> (((((Color & 0xFF00U) >> 8) >> 4) & 0xFU) << 4) |\ >> (((((Color & 0xFF0000U) >> 16) >> 4) & 0xFU) << 8) | \ >> (((((Color & 0xFF000000U) >> 24) >> 4) & 0xFU) << 12)) >> >> #define CONVERTRGB5652ARGB8888(Color) \ >> (((((((Color >> 11) & 0x1FU) * 527) + 23) >> 6) << 16) |\ >> ((((((Color >> 5) & 0x3FU) * 259) + 33) >> 6) << 8) |\ >> ((((Color & 0x1FU) * 527) + 23) >> 6) | 0xFF000000) >> >> It can be argued that the parentheses themselves are not the problem >> here - it is doing too much in one expression. Static inline functions >> would make things clearer, as would a separation of the steps of >> breaking down the original colour format into parts, scaling or >> conversions, then building up the new colour format. Different named >> types for the different formats would go a long way towards usability >> and safety - at least using typedefs, but preferably using structs to >> make real different types. And surely nicer names could have been found! > > Not to mention symbolic names for the magic constants. :-/ Names for magic constants can be good, but they are not always helpful - if the magic number is only used once, its definition is far from its use, and it is polluting the global name space, then it can be a lot better to simply use the number directly and add a comment at the point of use. But the shift-and-mask constants could be replaced by either a struct with bit-fields, or inline functions for field extractions, or at separate local variables for the extracted fields. > > This is exactly the sort of thing that, as you point out, a > `static inline` function is far better suited for. Some code > bases don't want to use them for a variety of reasons, usually > compatibility concerns with older code, compilers, or language > standards. Some variants of Unix, for instance, worry about > header compatibility with C90 [and in some cases K&R C] code. > Indeed. But even if they don't want to use "inline", a static function is better - the compiler will do the inlining anyway (if it makes sense according to its heuristics).
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-06-01 18:48 +0000 |
| Message-ID | <10vkk65$l8v$1@reader1.panix.com> |
| In reply to | #399591 |
In article <10vjsg2$259m3$3@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 01/06/2026 13:04, Dan Cross wrote:
>> In article <10vjdn8$22tgu$1@dont-email.me>,
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 31/05/2026 19:11, Bart wrote:
>>>> [snip]
>>>> Actual examples of too many parentheses?
>>>
>>> Any source code written in LISP :-)
>>
>> Hey now. Some of us have programmed in Lisp professionally, and
>> rather enjoy it.
>>
>> Lisp is often maligned for its parentheses; I don't think that's
>> fair. They really aren't that onorus once you start working in
>> it, and they're unambiguous; one may of the structure of Lisp
>> code as a shorthand notation for the resulting program's AST.
>
>I did include a smiley - I know there are people here who enjoy working
>with LISP, and have probably heard a few too many jokes about parentheses!
It's fine; many variants of Lisp are deserving of criticism, and
that community has a tendency to get too touchy about defending
the language's honor. People like Stallman are fond of calling
Lisp "the most powerful language" but I think that's nonsense.
A problem with many Lisp variants is that they're dynamically
typed; I once had to fix a production outage that happened with
a programmer converted a pair of integers into a triple. The
pair had been represented using a single `CONS` cell, but when
it became apparent that a triple was needed, it was changed into
a proper list. The operation for retrieving the first half of a
`CONS` cell is `CAR`; the operation for retrieving the second
half is `CDR`. Lisp hackers usually refer to the two halves as
"the CAR" and "the CDR" of the cell.
If a `CONS` cell just holds a pair of scalar values, as in this
example, these functions give back those scalars. However,
lists are built from `CONS` cells, where the CAR of the list is
the first element, and the CDR is the tail of the list, which is
itself a list.
Anyway, to access the values from the pair, the programmer used
`CAR` and `CDR`, but when the pair was converted to a list, this
was no longer correct; the first element was still accessible as
the CAR, but the CDR was now a list; to get the second element
of the list one would use `CADR` (or the better named `SECOND`).
Unfortunately, the programmer missed one place, and passed the
CDR of the list to a function that expected a `FIXNUM` and tried
to do arithmetic on it. Lisp is usually strongly typed, so you
can't just add a list to a number; that raises a "condition"
(which is like an exception, though that you can often restart
the thing that raised the condition). In this program, that
resulted in an ISE and an error returned to the user.
The fix was trivial, but it struck me at the time that in a
statically typed language it would have been a compile time
error.
>>> (And for too few parentheses, any source code in Forth.)
>>
>> No comment.
>>
>>> From a quick grep of an SDK in a project I am working on, I saw this
>>> example :
>>>
>>> if ((((pData1 == NULL) || (pData2 == NULL))) || (Length == 0U))
>>>
>>> The number of parentheses there is so high it's hard to see that not
>>> only is there an unnecessary extra parentheses for the first ||
>>> operator, but there is a second set of extra parentheses around it.
>>> Eliminating these would give :
>>>
>>> if ((pData1 == NULL) || (pData2 == NULL) || (Length == 0U))
>>>
>>> or, with an extra space for clarity,
>>>
>>> if ( (pData1 == NULL) || (pData2 == NULL) || (Length == 0U) )
>>>
>>> That still leaves extra parentheses around the equality operators, but
>>> the decision to keep or remove them is subjective (as is the choice of
>>> "pData1 == NULL" vs. "!pData1").
>>>
>>> But IMHO, the original line had at least two sets of completely
>>> redundant and unhelpful parentheses which made it harder to read - the
>>> reader is left wondering whether these parentheses are there for a
>>> purpose and have an effect on what should have been a simple and clear
>>> expression.
>>
>> I see code like this all the time; usually it comes from
>> hardware vendors (I take it this was from a BSP or something
>> similar?). I often wonder about vendor programming standards
>> when I run across things like it.
>
>Yes, this was from a hardware vendor (who shall remain nameless to
>protect the guilty - not that I have found other vendors to be much
>better). They have a tendency to be obsessed with MISRA, with sticking
>to C90, and with filling headers with huge Doxygen templates giving no
>information and obscuring the code. (I'm fine with Doxygen comments
>that actually add useful information, but not a dozen lines repeating
>the names and types from a function signature.)
Yes. I see all of this, and it mystifies me; I have seen how
excessive abstraction can lead to opaque code, but many times
hardware people go in the opposite direction, and one hardly
ever sees useful abstraction; for example, often the same code
sequence could be trivially extracted into a function, but it is
instead repeated multiple times, inline.
>>> The SDK also contains examples of parentheses used because it mixes
>>> relatively rare operators (shifts and binary operators). Parentheses
>>> around such sub-expressions are not uncommon, and can definitely be
>>> helpful, but the quantity here makes things hard to read. Ironically,
>>> though it is a macro, there are not "safety" parentheses around the
>>> argument in the expression.
>>>
>>> And yes, these really are the names of the macro in this code.
>>>
>>> #define CONVERTARGB88882ARGB4444(Color) \
>>> ((((Color & 0xFFU) >> 4) & 0xFU) |\
>>> (((((Color & 0xFF00U) >> 8) >> 4) & 0xFU) << 4) |\
>>> (((((Color & 0xFF0000U) >> 16) >> 4) & 0xFU) << 8) | \
>>> (((((Color & 0xFF000000U) >> 24) >> 4) & 0xFU) << 12))
>>>
>>> #define CONVERTRGB5652ARGB8888(Color) \
>>> (((((((Color >> 11) & 0x1FU) * 527) + 23) >> 6) << 16) |\
>>> ((((((Color >> 5) & 0x3FU) * 259) + 33) >> 6) << 8) |\
>>> ((((Color & 0x1FU) * 527) + 23) >> 6) | 0xFF000000)
>>>
>>> It can be argued that the parentheses themselves are not the problem
>>> here - it is doing too much in one expression. Static inline functions
>>> would make things clearer, as would a separation of the steps of
>>> breaking down the original colour format into parts, scaling or
>>> conversions, then building up the new colour format. Different named
>>> types for the different formats would go a long way towards usability
>>> and safety - at least using typedefs, but preferably using structs to
>>> make real different types. And surely nicer names could have been found!
>>
>> Not to mention symbolic names for the magic constants. :-/
>
>Names for magic constants can be good, but they are not always helpful -
>if the magic number is only used once, its definition is far from its
>use, and it is polluting the global name space, then it can be a lot
>better to simply use the number directly and add a comment at the point
>of use. But the shift-and-mask constants could be replaced by either a
>struct with bit-fields, or inline functions for field extractions, or at
>separate local variables for the extracted fields.
I don't mind some magic: the shift constants and the masks, for
instance, are fine. But the magic 527, 259, 23, and 33, and why
the subsequent values are shifted right by 6, could be better
explained by naming those constants.
Btw, with respect to this specific algorithm, I looked them up,
and they seem to be empirically discovered lore, though derived
from a relatively standard algorithm for projection of a
discrete value into a larger space. This stack overflow page
has some details:
https://stackoverflow.com/questions/2442576/how-does-one-convert-16-bit-rgb565-to-24-bit-rgb888
Anyway, I don't think the constants have to be defined far away
from the code; I'd be happy with a local `const uint32_t FOO`,
though in this case it should probably just be a comment.
Here's my offering:
// Converts a 16-bit RGB16 (5-6-5) value to an ARGB32
// ("RGBA8888") value.
static inline uint32_t
rgb16_to_argb(uint16_t color)
{
const uint32_t blue5 = (color >> 0) & 0x1F;
const uint32_t green6 = (color >> 5) & 0x3F;
const uint32_t red5 = (color >> 11) & 0x1F;
// Map from a 5 or 6 bit space into an 8 bit space. A
// 5-bit number has 32 possibilities; a 6 bit number
// has 64. We can calculate the projected 8-bit
// value for a k-bit number v, we can use the formula,
// v_8 = (v*2^8-1 + (k - 1)/2)/(2^k-1), or
// (v*255 + 15)/31 (for k=5) or (v*255 + 31)/63 (for
// k=6.
//
// To remove division by a prime and turn it into a
// shift, the constants below were empirically
// discovered to generate good results. See
// https://stackoverflow.com/questions/2442576/how-does-one-convert-16-bit-rgb565-to-24-bit-rgb888
// for details.
const uint32_t blue = (blue5 * 527 + 23) >> 6;
const uint32_t green = (green6 * 259 + 33) >> 6;
const uint32_t red = (red5 * 527 + 23) >> 6;
const uint32_t alpha = 0xFF000000;
return blue | (green << 8) | (red << 16) | alpha;
}
It's longer, yes, but I'd argue it's much easier to understand.
On my compiler, it generates almost identical code, except that
some instructions are in a different order.
>> This is exactly the sort of thing that, as you point out, a
>> `static inline` function is far better suited for. Some code
>> bases don't want to use them for a variety of reasons, usually
>> compatibility concerns with older code, compilers, or language
>> standards. Some variants of Unix, for instance, worry about
>> header compatibility with C90 [and in some cases K&R C] code.
>
>Indeed. But even if they don't want to use "inline", a static function
>is better - the compiler will do the inlining anyway (if it makes sense
>according to its heuristics).
Assuming the compiler they're working with is known to do so,
then I agree.
- Dan C.
[toc] | [prev] | [next] | [standalone]
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web