Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!bluemanedhawk.eternal-september.org!.POSTED!not-for-mail From: Blue-Maned_Hawk 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: References: 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?