Re: is STC a good supplementary library for C?

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?