Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!bluemanedhawk.eternal-september.org!.POSTED!not-for-mail
From: Blue-Maned_Hawk <bluemanedhawk@invalid.invalid>
Newsgroups: comp.lang.c
Subject: Re: is STC a good supplementary library for C?
Date: Sun, 4 Aug 2024 14:05:00 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 138
Message-ID: <pan$43aba$9be34f98$8b3ff06$290b415b@invalid.invalid>
References: <j4KdnZzYDexmlDP7nZ2dnZfqn_idnZ2d@brightview.co.uk>
	<containers-20240803130427@ram.dialup.fu-berlin.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 04 Aug 2024 16:05:01 +0200 (CEST)
Injection-Info: bluemanedhawk.eternal-september.org; posting-host="071b4b32ac3ccb4834ef3e4266ca21c2";
	logging-data="87867"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX189erqSNlyo3vQuRd6vd+nvzT2dOitFu44="
User-Agent: Pan/0.154 (Izium; 517acf4)
Cancel-Lock: sha1:x6X/iUet4blNGWlhCDhopVRvQ/8=
X-Face: Taumatawhakatangihangakoauauotamateaturipukakapikimaungahoronuku
 pokaiwhenuakitanatahu
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAIAAADYYG7QAAACh0lEQVRYw71Z21bD
 MAzzevbfkr4cHjrSXJyL044+MDa6WLEl2SkvkrZ1AbAvXO+bUGSCPYnsuIVGMpm
 ZLnjX718GhAKNsp8lON2F9VrhELwIgJlBepkZjA78rVK+FkmNhEJK76UsJlz8+E
 rJsjrpYouhLo/SC6qPHgakFOR8wV9+8rCfO/I/oVnmUZUp42/LW2XkLj9TCFNM9
 jp5g2EmHZgpYZjCOkYU7sXVogRylJqpdggoFLG1g09Flah/7kErCxzR9HgXPYsq
 0glb9cxjIz2Vsk9AmAoCSxECpD713joMKjQqLAtmMqJmXjdVvlMnMQCVITotJd1
 z+fh1f1NNo+vuc1KnhWUmY7t03vydTud9BbXCtN3L2PL3bK7JCNG0GHzuZxafyB
 fxevCxpm1vrwZltqw6SILCcdoCE6PGQC8wZWDA9Or7Qp5s3lAZezys0nDazs9S9
 R0TjwEiksRxLkNPC1NMMWPs1bj0Ei0Yuo+JVtFLuzP1NRJ16qXWN8DhhtmS4PDg
 O6mqRxs4bEJrYt087mSIow/1VzW2oFlMQuiuIy/KsUagvhdw6hSjJGlIavbLF8x
 j3X47bccLcUSi0dkWh1nUZNhANT1tHKUXrNxNLbd9KPb9wDDVrKwmPQMOPQ1oy6
 k5I1DwzDeRJd3jVIhDAUxq3ngzJG4CCkNXZxZVMcjefoK2J0gUY2S3rxz/RuTFx
 2zHd9U+obimJXMG4edsk/2j5pTU5G1MmzbRLxkfq5EiT1GGsidvMGzi+1goGb2l
 GCrN+nGnV8xj3q3JLRDVPL96vUc7Z4aJ3TN1mVqWAMJMfG+Jxh6TQqP+92iZkCU
 xtglds1AB6r0aiSHKcnFck+p/c/0CbacFLQcajGcAAAAASUVORK5CYII=
Bytes: 8215

The first thing that i have to say about this message is that it looks 
like it was written by an ML system and regurgitated here with minimal 
edits, if any at all.  Don't do this—if someone wanted an ML-generated 
answer, they would go to an ML system on their own volition.

Stefan Ram wrote:

>   C is a stripped-down language designed to get close to the hardware
>   with minimal overhead. It skips many of the high-level features in
>   C++, like templates, classes, and operator overloading. Trying to make
>   C act like C++ by building a generic container library can lead to:
> 
>   Complexity: Creating generic containers in C often means dealing with
>   gnarly macros, void pointers, and type casting,
>   which can make the code a pain to read and maintain.

I think that this is greatly exaggerated.  Macros can get into the realm 
of unreadability, but there's an unfortunate feedback loop here:  people 
are told to not use macros because they're unreadable, which means that 
people don't get as much experience with macros, which means that they 
find it hard to read macros, which means people are told that macros are 
unreadable…  I've found myself able to write macros that i've found 
readable and usable perfectly fine—something that i've found to be key to 
this is to ignore dogma and format the macro code to be readable instead 
of strictly compliant to a ideal of style.

I don't consider void pointers or type casting to be complex—i'd be 
curious about the reasoning for this claim.

>   Inefficiency: Generic containers in C might not be as slick as those
>   in C++ due to the lack of compile-time type checking and
>   optimizations. And,

I'd be more concerned about practicality than slickness.  I'm not sure 
what's being referred to with a “lack of compile-time type checking”—would 
an example be possible?

The lack of optimizations _is_ a sound claim, but i don't think it's very 
relevant here.  Optimization is always the last stage of developing a 
piece of software, and even then it's only ever really done for big, 
public projects.  For small personal projects, worrying about optimization 
isn't necessary.

>   error-prone code: Without the type safety provided by C++ templates,
>   generic containers in C are more likely to cause runtime errors.

I still don't get this.  C _does_ have a type system.  Macros _can_ expand 
to constructs that take advantage of this type system.

>   Idiomatic C programming rolls with the language's strengths and works
>   within its constraints. This often involves:

Normalcy is orthogonal to optimality.

>   Explicit typing: C programmers usually define data structures and
>   functions explicitly for each type they need, rather than leaning on
>   generic solutions.

…and by doing so, they violate the principle of nonrepetition.  Macros are 
a useful tool, y'all—they aren't inherently evil.

>   Manual memory management: C programmers are used to managing memory by
>   hand, which can be more predictable and efficient than relying on a
>   generic container library. And,

I cannot see the relevancy of generic types to memory management at all.

>   simplicity and clarity: C code is often straightforward and simple,
>   focusing on clear and direct solutions rather than abstract and
>   generalized ones.

Doesn't all code do that?

>   The old pros of C came up with several techniques to handle the lack
>   of generic containers:
> 
>   Structs and pointers: Using structs and pointers to create custom data
>   structures tailored to specific needs.
> 
>   Function pointers: Employing function pointers to pull off a form of
>   polymorphism. And,

These are not remotely specific to C.
 
>   Macros: Utilizing preprocessor macros to create reusable code
>   snippets, though this can lead to less readable and maintainable code
>   if overdone.

Any tool can be used incorrectly.

>   Some problems encountered when using generic container libraries in C
>   might be:
> 
>   portability: Generic container libraries in C can be less portable
>   across different compilers and platforms.

GCC's extensions and Clang's extensions can be useful, but standard C is 
plenty powerful enough for genericity.  Extension-wielding code can be 
bracketed with conditional inclusion.

Here's an example:  There's a macro i've written where one of the 
arguments _must_ be a valid identifier.  Standard C has no way to check 
for this, but Clang defines the __is_identifier macro that can check for 
this.  In the header file, i check if __is_identifier is defined, and 
define it to always evaluate to true if it isn't.  This means that i can 
use the macro in static assertions to make sure that the argument to the 
macro is a valid identifier, and if it can be checked, it is, without any 
problems if it can't be.

>   Debugging: Debugging generic code in C can be more of a hassle due to
>   the lack of type information and the use of void pointers. And,

Still don't know what's meant by the “lack of type information”.

>   performance: Hand-crafted, type-specific data structures and
>   algorithms can often be more performant than generic implementations.
> 
>   While it's technically possible to whip up a generic container library
>   in C, doing so often goes against the grain of idiomatic C
>   programming.
> 
>   C shines in simplicity, explicitness, and low-level control.

Not anymore.

>   Embracing these traits leads to more maintainable, efficient, and
>   understandable code. Instead of trying to force C to act like C++,
>   it's generally better to leverage C's strengths and use techniques
>   that are well-suited to the language's design and philosophy.

Genericity is not exclusive to CXX.



-- 
Blue-Maned_Hawk│shortens to Hawk│/blu.mɛin.dʰak/│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
Why did i arse myself about with this?