On Thursday, 28 April 2022 at 11:30:20 UTC+1, William Ahern wrote:
> Bonita Montero <Bonita....@gmail.com> wrote:
> > Am 28.04.2022 um 02:10 schrieb William Ahern:
> >> Bonita Montero <Bonita....@gmail.com> wrote:
> >>> Am 27.04.2022 um 13:21 schrieb Thiago Adams:
> >> <snip>
> >>>> If a C programmer has concerns about qsort performance he just
> >>>> make it inline removing the function comparison pointer and using
> >>>> the function directly.
> >>>
> >>> 1. You can't inline a function with arbitrary recursion.
> >>
> >> The same is true in C++.
> >>
> >>> 2. The comparison-function for qsort() is never inlined.
> >>
> >> That's a toolchain issue. Nothing prevents C environments from inlining
> >> qsort and it's callback; ...
> >
> > The qsort-function is a static piece of code and the comparison
> > -function is never inlined.
> See disassembly posted elsethread. I've given all the information needed to
> quickly reproduce this for yourself, assuming some minimal familiarity with
> GCC.
>
> Alpine Linux isn't even needed, it's just what I started with out of
> caution. I just now reproduced the distinctive benchmark profiles between
> qsort-inline and qsort-extern on macOS 12.3.1 after removing -Wl,-rpath from
> CFLAGS. (The macOS/mach-O linker doesn't recognize the -rpath option, but
> it's linker embeds and uses the original location by default, anyhow.) I
> don't know off-hand how to get a proper disassembly on macOS (-flto
> complicates things considerably), but there's no reason to believe that the
> comparator wasn't inlined like it was on Linux.
>
> As another poster mentioned, templates are good for much more than
> performance inlining. But I've always had a gripe with the qsort vs
> std::qsort meme in particular: it confuses C toolchains and historical
> linking semantics with the language itself. It should be clear, now, that C
> language semantics don't prevent inlining of a comparator passed to a
> sorting function; now even one defined externally to the invoking source
> unit. (Unless somehow I've missed that a standard routine can't be inlined
> without violating the standard--e.g. that the symbol has to have a unique
> address.)
>
That an interesting one. The comparison function can have side-effects,
so it could do something with its own address, like printing it out. Does
that address have to match the address of the fucntion when taken globally?
I think it does.
That would make inlining a lot more complicated, just to catch one almost
useless exceptional case.

On Thursday, April 28, 2022 at 1:59:23 AM UTC-3, Bonita Montero wrote:
> Am 28.04.2022 um 02:10 schrieb William Ahern:
> > Bonita Montero <Bonita....@gmail.com> wrote:
> >> Am 27.04.2022 um 13:21 schrieb Thiago Adams:
> > <snip>
> >>> If a C programmer has concerns about qsort performance he just
> >>> make it inline removing the function comparison pointer and using
> >>> the function directly.
> >>
> >> 1. You can't inline a function with arbitrary recursion.
> >
> > The same is true in C++.
> >
> >> 2. The comparison-function for qsort() is never inlined.
> >
> > That's a toolchain issue. Nothing prevents C environments from inlining
> > qsort and it's callback; ...
>
> The qsort-function is a static piece of code and the comparison
> -function is never inlined.

What I mean by " removing the function comparison pointer and using
the function directly." is to create a copy of the code replacing the
function pointer. Like instantiating the template function manually.
The idea C++ is faster than C is always very superficial. C is not
a language to expect a big framework to compare against something else
(samples like qsort x std::sort are rare), instead C is a language what you
do whatever you want given you fine control about performance.

> {
> unsigned
> &l = *(unsigned *)left,
> &r = *(unsigned *)right;
> return l < r ? -1 : l > r ? 1 : 0;
> } );

(l > r ? 1 : 0) means exactly the same thing as (l > r)

On 5/7/2022 9:45 PM, Dolores Filandro wrote:
>
>> {
>> unsigned
>> &l = *(unsigned *)left,
>> &r = *(unsigned *)right;
>> return l < r ? -1 : l > r ? 1 : 0;
>> } );
>
>
> (l > r ? 1 : 0) means exactly the same thing as (l > r)

.... which is why one usually expresses the above as the idiomatic

return (l > r) - (l < r);

--
Best regards,
Andrey

In article <t580j5$hlc$1@dont-email.me>,
Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>On 5/7/2022 9:45 PM, Dolores Filandro wrote:
>>
>>> {
>>> unsigned
>>> &l = *(unsigned *)left,
>>> &r = *(unsigned *)right;
>>> return l < r ? -1 : l > r ? 1 : 0;
>>> } );
>>
>>
>> (l > r ? 1 : 0) means exactly the same thing as (l > r)
>
>... which is why one usually expresses the above as the idiomatic
>
> return (l > r) - (l < r);

Which is why I've always thought it was dumb that the standard library
(both in C and in some "C-like" languages) doesn't provide the sgn()
function. It means that everybody has to re-invent the above idiom.

Incidentally, is any of this necessary? I have not been following this
discussion, so I may have missed something, but if we are talking about the
qsort() function, then it is not necessary to return exactly one of -1, 0,
or 1. Any negative number will do, as will any positive one. So, all you
need is (l-r).

--
The single most important statistic in the US today - the one that explains all the
others - is this: 63 million people thought it was a good idea to vote for this clown
(and will probably do so again). Everything else is secondary to that. Everything else
could be fixed if we can revert this one statistic. Nothing can be fixed until we do.

Dolores Filandro <dolfiland8@gmail.com> writes:
>> {
>> unsigned
>> &l = *(unsigned *)left,
>> &r = *(unsigned *)right;
>> return l < r ? -1 : l > r ? 1 : 0;
>> } );
>(l > r ? 1 : 0) means exactly the same thing as (l > r)

A programmer might implement a specification that says,

-1 if l < r
result = { 1 if l > r
0 , otherwise.

. Then, - somewhat redundant - code such as

return
l < r? -1:
l > r? 1:
0;

might make it easier to verify during code inspections that
the code implements the specification.

On 5/8/2022 8:06 AM, Kenny McCormack wrote:
> In article <t580j5$hlc$1@dont-email.me>,
> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>> On 5/7/2022 9:45 PM, Dolores Filandro wrote:
>>>
>>>> {
>>>> unsigned
>>>> &l = *(unsigned *)left,
>>>> &r = *(unsigned *)right;
>>>> return l < r ? -1 : l > r ? 1 : 0;
>>>> } );
>>>
>>>
>>> (l > r ? 1 : 0) means exactly the same thing as (l > r)
>>
>> ... which is why one usually expresses the above as the idiomatic
>>
>> return (l > r) - (l < r);
>
> Which is why I've always thought it was dumb that the standard library
> (both in C and in some "C-like" languages) doesn't provide the sgn()
> function. It means that everybody has to re-invent the above idiom.
>
> Incidentally, is any of this necessary? I have not been following this
> discussion, so I may have missed something, but if we are talking about the
> qsort() function, then it is not necessary to return exactly one of -1, 0,
> or 1. Any negative number will do, as will any positive one. So, all you
> need is (l-r).

No. `l - r` is a major anti-pattern and is often a bug.

Firstly, this will not work at all for unsigned types as in the original
example. Secondly, in general this will not work for signed types since
it can/will overflow.

The only case when you can get away with `l - r` is smaller-than-int
types (which are promoted to `int` and can't overflow), and situations
where "you are absolutely sure" the values are so small that overflow
can't happen.

But it is not really worth it, when one has `(l > r) - (l < r)`.

--
Best regards,
Andrey

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>. Then, - somewhat redundant - code such as
>return
>l < r? -1:
>l > r? 1:
> 0;
>might make it easier to verify during code inspections that
>the code implements the specification.

I did a search for it, and found only few definitions:

|#define sign(z) ((z) < 0 ? -1 : ((z) > 0 ? 1 : 0))
nethack

. Sometimes, first, a two-argument sign is defined,
sign(a,b), as the value of a with the sign of b. The
one-argument sign then sometimes is defined as sign(1,b).

Sometimes, just two values are wanted.

|double
|sgn (double __x)
|{
| return __x >= 0.0 ? 1.0 : -1.0;
|}
gcc testsuite

Sometimes, non-portable code is accepted.

|#define SIGN(fp) ((fp) & SIGNBIT)
libgcc

On 5/8/2022 10:07 AM, Andrey Tarasevich wrote:
> On 5/8/2022 8:06 AM, Kenny McCormack wrote:
>> In article <t580j5$hlc$1@dont-email.me>,
>> Andrey Tarasevich  <andreytarasevich@hotmail.com> wrote:
>>> On 5/7/2022 9:45 PM, Dolores Filandro wrote:
>>>>
>>>>> {
>>>>> unsigned
>>>>> &l = *(unsigned *)left,
>>>>> &r = *(unsigned *)right;
>>>>> return l < r ? -1 : l > r ? 1 : 0;
>>>>> } );
>>>>
>>>>
>>>> (l > r ? 1 : 0)  means exactly the same thing as  (l > r)
>>>
>>> ... which is why one usually expresses the above as the idiomatic
>>>
>>>    return (l > r) - (l < r);
>>
>> Which is why I've always thought it was dumb that the standard library
>> (both in C and in some "C-like" languages) doesn't provide the sgn()
>> function.  It means that everybody has to re-invent the above idiom.
>>
>> Incidentally, is any of this necessary?  I have not been following this
>> discussion, so I may have missed something, but if we are talking
>> about the
>> qsort() function, then it is not necessary to return exactly one of
>> -1, 0,
>> or 1.  Any negative number will do, as will any positive one.  So, all
>> you
>> need is (l-r).
>
> No. `l - r` is a major anti-pattern and is often a bug.
>
> Firstly, this will not work at all for unsigned types as in the original
> example. Secondly, in general this will not work for signed types since
> it can/will overflow.
>
> The only case when you can get away with `l - r` is smaller-than-int
> types (which are promoted to `int` and can't overflow), and situations
> where "you are absolutely sure" the values are so small that overflow
> can't happen.
>
> But it is not really worth it, when one has `(l > r) - (l < r)`.

Of course, one can always argue that `(l > r) - (l < r)` is also a
variation of `l - r` where the values are pre-normalized to ensure they
"are so small that overflow can't happen".

:O)

--
Best regards,
Andrey

On Sunday, May 8, 2022 at 1:13:58 PM UTC-4, Andrey Tarasevich wrote:
> On 5/8/2022 10:07 AM, Andrey Tarasevich wrote:
> > On 5/8/2022 8:06 AM, Kenny McCormack wrote:
> >> In article <t580j5$hlc$1...@dont-email.me>,
> >> Andrey Tarasevich <andreyta...@hotmail.com> wrote:
> >>> On 5/7/2022 9:45 PM, Dolores Filandro wrote:
> >>>>
> >>>>> {
> >>>>> unsigned
> >>>>> &l = *(unsigned *)left,
> >>>>> &r = *(unsigned *)right;
> >>>>> return l < r ? -1 : l > r ? 1 : 0;
> >>>>> } );
> >>>>
> >>>>
> >>>> (l > r ? 1 : 0) means exactly the same thing as (l > r)
> >>>
> >>> ... which is why one usually expresses the above as the idiomatic
> >>>
> >>> return (l > r) - (l < r);
> >>
> >> Which is why I've always thought it was dumb that the standard library
> >> (both in C and in some "C-like" languages) doesn't provide the sgn()
> >> function. It means that everybody has to re-invent the above idiom.
> >>
> >> Incidentally, is any of this necessary? I have not been following this
> >> discussion, so I may have missed something, but if we are talking
> >> about the
> >> qsort() function, then it is not necessary to return exactly one of
> >> -1, 0,
> >> or 1. Any negative number will do, as will any positive one. So, all
> >> you
> >> need is (l-r).
> >
> > No. `l - r` is a major anti-pattern and is often a bug.
> >
> > Firstly, this will not work at all for unsigned types as in the original
> > example. Secondly, in general this will not work for signed types since
> > it can/will overflow.
> >
> > The only case when you can get away with `l - r` is smaller-than-int
> > types (which are promoted to `int` and can't overflow), and situations
> > where "you are absolutely sure" the values are so small that overflow
> > can't happen.
> >
> > But it is not really worth it, when one has `(l > r) - (l < r)`.
> Of course, one can always argue that `(l > r) - (l < r)` is also a
> variation of `l - r` where the values are pre-normalized to ensure they
> "are so small that overflow can't happen".
> :O)
>
> --
> Best regards,
> Andrey

But what I was getting at, is that
for OP representing any relational or equality operator, ==, !=, >, <, et cetera,
and with any text substitutions for A and B
the expression ((A) OP (B)) means *Exactly* the same thing as the expression ((A) OP (B) ? 1 : 0)
Same type
Same value
Same side effects
to the extent that a compiler can always render the exact same op code for either expression.

On Monday, 9 May 2022 at 18:00:51 UTC+1, Dolores Filandro wrote:
> On Sunday, May 8, 2022 at 1:13:58 PM UTC-4, Andrey Tarasevich wrote:
> > On 5/8/2022 10:07 AM, Andrey Tarasevich wrote:
> > > On 5/8/2022 8:06 AM, Kenny McCormack wrote:
> > >> In article <t580j5$hlc$1...@dont-email.me>,
> > >> Andrey Tarasevich <andreyta...@hotmail.com> wrote:
> > >>> On 5/7/2022 9:45 PM, Dolores Filandro wrote:
> > >>>>
> > >>>>> {
> > >>>>> unsigned
> > >>>>> &l = *(unsigned *)left,
> > >>>>> &r = *(unsigned *)right;
> > >>>>> return l < r ? -1 : l > r ? 1 : 0;
> > >>>>> } );
> > >>>>
> > >>>>
> > >>>> (l > r ? 1 : 0) means exactly the same thing as (l > r)
> > >>>
> > >>> ... which is why one usually expresses the above as the idiomatic
> > >>>
> > >>> return (l > r) - (l < r);
> > >>
> > >> Which is why I've always thought it was dumb that the standard library
> > >> (both in C and in some "C-like" languages) doesn't provide the sgn()
> > >> function. It means that everybody has to re-invent the above idiom.
> > >>
> > >> Incidentally, is any of this necessary? I have not been following this
> > >> discussion, so I may have missed something, but if we are talking
> > >> about the
> > >> qsort() function, then it is not necessary to return exactly one of
> > >> -1, 0,
> > >> or 1. Any negative number will do, as will any positive one. So, all
> > >> you
> > >> need is (l-r).
> > >
> > > No. `l - r` is a major anti-pattern and is often a bug.
> > >
> > > Firstly, this will not work at all for unsigned types as in the original
> > > example. Secondly, in general this will not work for signed types since
> > > it can/will overflow.
> > >
> > > The only case when you can get away with `l - r` is smaller-than-int
> > > types (which are promoted to `int` and can't overflow), and situations
> > > where "you are absolutely sure" the values are so small that overflow
> > > can't happen.
> > >
> > > But it is not really worth it, when one has `(l > r) - (l < r)`.
> > Of course, one can always argue that `(l > r) - (l < r)` is also a
> > variation of `l - r` where the values are pre-normalized to ensure they
> > "are so small that overflow can't happen".
> > :O)
> >
> > --
> > Best regards,
> > Andrey
> But what I was getting at, is that
> for OP representing any relational or equality operator, ==, !=, >, <, et cetera,
> and with any text substitutions for A and B
> the expression ((A) OP (B)) means *Exactly* the same thing as the expression ((A) OP (B) ? 1 : 0)
> Same type
> Same value
> Same side effects
> to the extent that a compiler can always render the exact same op code for either expression.
>
The relational operators don't have to be overloaded to return a boolean.
It's normal to do so, but not required.
I suppose a use case would be a fuzzy logic type system whereby you could have
full or partial equality, and == returned a real on 0.0 - 1.0.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> The relational operators don't have to be overloaded to return a boolean.
> It's normal to do so, but not required.
> I suppose a use case would be a fuzzy logic type system whereby you could have
> full or partial equality, and == returned a real on 0.0 - 1.0.

C doesn't have operator overloading. The equality and relational
operators return a result of type int with the value 0 or 1.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Am 08.05.2022 um 06:45 schrieb Dolores Filandro:
>
>> {
>> unsigned
>> &l = *(unsigned *)left,
>> &r = *(unsigned *)right;
>> return l < r ? -1 : l > r ? 1 : 0;
>> } );
>
>
> (l > r ? 1 : 0) means exactly the same thing as (l > r)

The result of the comparison-callback of qsort() is -1, 0 or 1.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 08.05.2022 um 06:45 schrieb Dolores Filandro:
>>
>>> {
>>> unsigned
>>> &l = *(unsigned *)left,
>>> &r = *(unsigned *)right;
>>> return l < r ? -1 : l > r ? 1 : 0;
>>> } );
>>
>>
>> (l > r ? 1 : 0) means exactly the same thing as (l > r)
>
>The result of the comparison-callback of qsort() is -1, 0 or 1.
>

Neither of the relevant standards agree with you.

C99 (n1256.pdf)

The comparison function pointed to by compar is called with two arguments that point
to the key object and to an array element, in that order. The function shall return an
integer less than, equal to, or greater than zero if the key object is considered,
respectively, to be less than, to match, or to be greater than the array element. The array
shall consist of: all the elements that compare less than, all the elements that compare
equal to, and all the elements that compare greater than the key object, in that order.264)

POSIX:

The contents of the array shall be sorted in ascending order according to a comparison
function. The compar argument is a pointer to the comparison function, which is
called with two arguments that point to the elements being compared. The
application shall ensure that the function returns an integer less than,
equal to, or greater than 0, if the first argument is considered respectively
less than, equal to, or greater than the second. If two members compare
as equal, their order in the sorted array is unspecified.

https://pubs.opengroup.org/onlinepubs/9699919799/functions/qsort.html

On 5/10/2022 9:21 AM, Bonita Montero wrote:
> Am 08.05.2022 um 06:45 schrieb Dolores Filandro:
>>
>>> {
>>> unsigned
>>> &l = *(unsigned *)left,
>>> &r = *(unsigned *)right;
>>> return l < r ? -1 : l > r ? 1 : 0;
>>> } );
>>
>>
>> (l > r ? 1 : 0)  means exactly the same thing as  (l > r)
>
> The result of the comparison-callback of qsort() is -1, 0 or 1.
>

What point are you trying to make? The result of `(l > r ? 1 : 0)` is 1
or 0. The result of `(l > r)` is also 1 or 0. So?

P.S. Notwithstanding that callback result does not have to be "-1, 0 or 1"

--
Best regards,
Andrey

Am 10.05.2022 um 18:37 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 08.05.2022 um 06:45 schrieb Dolores Filandro:
>>>
>>>> {
>>>> unsigned
>>>> &l = *(unsigned *)left,
>>>> &r = *(unsigned *)right;
>>>> return l < r ? -1 : l > r ? 1 : 0;
>>>> } );
>>>
>>>
>>> (l > r ? 1 : 0) means exactly the same thing as (l > r)
>>
>> The result of the comparison-callback of qsort() is -1, 0 or 1.
>>
>
> Neither of the relevant standards agree with you.

I'm not referring to the standard but what I implement.

Am 10.05.2022 um 19:22 schrieb Andrey Tarasevich:
> On 5/10/2022 9:21 AM, Bonita Montero wrote:
>> Am 08.05.2022 um 06:45 schrieb Dolores Filandro:
>>>
>>>> {
>>>> unsigned
>>>> &l = *(unsigned *)left,
>>>> &r = *(unsigned *)right;
>>>> return l < r ? -1 : l > r ? 1 : 0;
>>>> } );
>>>
>>>
>>> (l > r ? 1 : 0)  means exactly the same thing as  (l > r)
>>
>> The result of the comparison-callback of qsort() is -1, 0 or 1.
>>
>
> What point are you trying to make? The result of `(l > r ? 1 : 0)` is 1
> or 0. The result of `(l > r)` is also 1 or 0. So?

Of course, but isn't a sufficient result for the qsort-callback.

On Wednesday, 11 May 2022 at 08:17:02 UTC+3, Bonita Montero wrote:
> Am 10.05.2022 um 19:22 schrieb Andrey Tarasevich:
> > On 5/10/2022 9:21 AM, Bonita Montero wrote:
> >> Am 08.05.2022 um 06:45 schrieb Dolores Filandro:
> >>>
> >>>> {
> >>>> unsigned
> >>>> &l = *(unsigned *)left,
> >>>> &r = *(unsigned *)right;
> >>>> return l < r ? -1 : l > r ? 1 : 0;
> >>>> } );
> >>>
> >>>
> >>> (l > r ? 1 : 0) means exactly the same thing as (l > r)
> >>
> >> The result of the comparison-callback of qsort() is -1, 0 or 1.
> >>
> >
> > What point are you trying to make? The result of `(l > r ? 1 : 0)` is 1
> > or 0. The result of `(l > r)` is also 1 or 0. So?
> Of course, but isn't a sufficient result for the qsort-callback.

The qsort does not require you to write redundant code in callback.
The "l > r ? 1 : 0" you are discussing is subexpression that is exactly
equivalent with "l > r" so the "? 1 : 0" part of it is superfluous.

On Wednesday, May 11, 2022 at 1:17:02 AM UTC-4, Bonita Montero wrote:
> Am 10.05.2022 um 19:22 schrieb Andrey Tarasevich:
> > On 5/10/2022 9:21 AM, Bonita Montero wrote:
> >> Am 08.05.2022 um 06:45 schrieb Dolores Filandro:
> >>>
> >>>> {
> >>>> unsigned
> >>>> &l = *(unsigned *)left,
> >>>> &r = *(unsigned *)right;
> >>>> return l < r ? -1 : l > r ? 1 : 0;
> >>>> } );
> >>>
> >>>
> >>> (l > r ? 1 : 0) means exactly the same thing as (l > r)
> >>
> >> The result of the comparison-callback of qsort() is -1, 0 or 1.
> >>
> >
> > What point are you trying to make? The result of `(l > r ? 1 : 0)` is 1
> > or 0. The result of `(l > r)` is also 1 or 0. So?
> Of course, but isn't a sufficient result for the qsort-callback.

No one suggested that it was. The original code was

return l < r ? -1 : l > r ? 1 : 0;

Doloros was pointing out that the sub-expression l > r ? 1 : 0 was
exactly equivalent to l > r, implying that the code should be changed to

return l < r ? -1 : l > r;

No on was suggesting that it be changed to

return l > r;

> The qsort does not require you to write redundant code in callback.
> The "l > r ? 1 : 0" you are discussing is subexpression that is exactly
> equivalent with "l > r" so the "? 1 : 0" part of it is superfluous.

Right, but that's not what qsort needs. qsort doesn't need a less
-predicate like std::sort but a ternary result which is either
negative, zero or positive.

On Wednesday, May 11, 2022 at 10:52:51 AM UTC-4, Bonita Montero wrote:
> > The qsort does not require you to write redundant code in callback.
> > The "l > r ? 1 : 0" you are discussing is subexpression that is exactly
> > equivalent with "l > r" so the "? 1 : 0" part of it is superfluous.
> Right, but that's not what qsort needs. qsort doesn't need a less
> -predicate like std::sort but a ternary result which is either
> negative, zero or positive.

Which is precisely what you get with either

return l < r ? -1 : l > r ? 1 : 0;,

as you originally wrote it, or with l > r ? 1 : 0 simplified to l > r, giving

return l < r ? -1 : l > r;

as was implicitly by Dolores' comment.

Am 11.05.2022 um 18:13 schrieb james...@alumni.caltech.edu:
> On Wednesday, May 11, 2022 at 10:52:51 AM UTC-4, Bonita Montero wrote:
>>> The qsort does not require you to write redundant code in callback.
>>> The "l > r ? 1 : 0" you are discussing is subexpression that is exactly
>>> equivalent with "l > r" so the "? 1 : 0" part of it is superfluous.
>> Right, but that's not what qsort needs. qsort doesn't need a less
>> -predicate like std::sort but a ternary result which is either
>> negative, zero or positive.
>
> Which is precisely what you get with either
>
> return l < r ? -1 : l > r ? 1 : 0;,
>
> as you originally wrote it, or with l > r ? 1 : 0 simplified to l > r, giving
>
> return l < r ? -1 : l > r;
>
> as was implicitly by Dolores' comment.

The optimizer generates the same code and mine is more readable.

On Wednesday, May 11, 2022 at 12:44:23 PM UTC-4, Bonita Montero wrote:
> Am 11.05.2022 um 18:13 schrieb james...@alumni.caltech.edu:
....
> > Which is precisely what you get with either
> >
> > return l < r ? -1 : l > r ? 1 : 0;,
> >
> > as you originally wrote it, or with l > r ? 1 : 0 simplified to l > r, giving
> >
> > return l < r ? -1 : l > r;
> >
> > as was implicitly by Dolores' comment.
> The optimizer generates the same code and mine is more readable.

Readability is a judgment call, and I've learned there's not much point in
arguing about judgment calls. Dolores' is simpler, and to me, at least, more
readable. Code like yours would make me wonder whether the author was
so unfamiliar with C that she didn't realize the extra complication was
unnecessary. It wouldn't occur to me to think she might have written it
because she found the unnecessarily complicated code more readable.

> Readability is a judgment call, ...

I think most people generally understanding code would argue like that.

> Dolores' is simpler, ...

Less code, not simpler.

> Code like yours would make me wonder whether the author was
> so unfamiliar with C that she didn't realize the extra complication

It's less complication.