Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: sort - C, python, C++, glibc Was: Baby X is bor nagain
Date: Wed, 19 Jun 2024 12:53:21 +0200
Organization: A noiseless patient Spider
Lines: 71
Message-ID: <v4udb1$1u14i$2@dont-email.me>
References: <v494f9$von8$1@dont-email.me>
 <v49seg$14cva$1@raubtier-asyl.eternal-september.org>
 <v49t6f$14i1o$1@dont-email.me>
 <v4bcbj$1gqlo$1@raubtier-asyl.eternal-september.org>
 <v4bh56$1hibd$1@dont-email.me> <v4c0mg$1kjmk$1@dont-email.me>
 <v4c8s4$1lki1$4@dont-email.me> <20240613002933.000075c5@yahoo.com>
 <v4emki$28d1b$1@dont-email.me> <20240613174354.00005498@yahoo.com>
 <v4okn9$flpo$2@dont-email.me> <20240617002924.597@kylheku.com>
 <v4pddb$m5th$1@dont-email.me> <20240618115650.00006e3f@yahoo.com>
 <v4rv0o$1b7h1$1@dont-email.me> <20240618184026.000046e1@yahoo.com>
 <v4sd75$1ed31$1@dont-email.me> <v4tr8c$1qoda$1@dont-email.me>
 <20240619131758.0000032e@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 19 Jun 2024 12:53:22 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="496e798c2f4d7717891a7779c6d418c6";
	logging-data="2032786"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+voM0SInjKtuuBsGwiZ38xCODg2/YAkSA="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:UdZpPdElywbK0lFrJ9Wgrc/l4Fk=
In-Reply-To: <20240619131758.0000032e@yahoo.com>
Content-Language: en-GB
Bytes: 4610

On 19/06/2024 12:17, Michael S wrote:
> On Wed, 19 Jun 2024 07:44:44 +0200
> David Brown <david.brown@hesbynett.no> wrote:
> 
>> On 18/06/2024 18:39, Malcolm McLean wrote:
>>>>
>>>>   
>>> My main experience of Python was that we had some resource files
>>> which were icons, in matching light and dark themes. The light
>>> theme had suffix _L followed by extension, and the dark themes had
>>> _D. And they needed to be sorted alphabetically, except that _L
>>> should be placed before _D.
>>> And it didn't take long to get Python to sort the list
>>> alphabetically, but there seemed no way in to the sort comparision
>>> function itself. And I had to give up.
>>>    
>>
>> Python "sort" is a bit like C "qsort" (desperately trying to relate
>> this to the group topicality) in that you can define your own
>> comparison function, and use that for "sort".  For simple comparison
>> functions, people often use lambdas, for more complicated ones it's
>> clearer to define a function with a name.
>>
>>
> 
> Off topic:
> Indeed, Python sort has option for specifying comparison function, but
> I would not call it very similar to comparison function of C qsort
> since in Python comparison is not applied directly to the record.

Yes, it seems that the comparison function support in sort() was in 
Python 2 but was dropped for Python 3.

> Instead, it applied to the keys that are derived from record.
> Besides, my impression is that in Python sorting by user-supplied
> comparison function is less idiomatic than doing all heavy lifting in
> user-supplied key function.

A key function can be applied once per item, while a comparison function 
is called once per comparison - thus key functions will be (or at least 
/can/ be) more efficient.

> For the case, presented by Malcolm, I'd certainly do it all in key(),
> without custom cmp_to_key(). May be, it's a little less efficient, but
> significantly easier to comprehend.
> 
> Back to topic:
> C qsort() sucks. They forgot to provide an option for 3rd parameter
> (context) in comparison callback.

It is also not guaranteed to be stable (which is important in some 
contexts), and it is a misnomer - it is rarely a quicksort.

> Back to O.T.:
> Python's sort bypasses the problem by allowing lambda as a key()
> function, so it could have visibility of variables of the caller. IMHO,
> it still sucks.
> C++ way, where comparison can be functor, sucks far less. I find it
> less than obvious, but at least all functionality one can ever want is
> available.

The C++ way is also massively more efficient than C in cases where the 
comparison function is simple.  And it is typesafe.

> 
> Back to topic: why C standard committee still didn't add something like
> gnu qsort_r() to the standard?
> 

That is a little more flexible, but it's still ugly!