[HN Gopher] Implementing Generic Types in C
___________________________________________________________________
Implementing Generic Types in C
Author : sirwhinesalot
Score : 69 points
Date : 2025-03-16 10:25 UTC (3 days ago)
(HTM) web link (btmc.substack.com)
(TXT) w3m dump (btmc.substack.com)
| lukaslalinsky wrote:
| For C with generic types, I think one should pick up Zig. It's
| exactly that, it's a low level language with manual memory
| management, but it allows you to do generic types like this
| without hacks.
| randomNumber7 wrote:
| You could use C++ and ignore the rest of it.
| huhtenberg wrote:
| Not sure why the parent is in gray. It's a perfectly valid
| and widely practiced approach.
| codr7 wrote:
| How often it works out as intended is very much up for
| debate though.
| jimbob45 wrote:
| For legacy codebases, switching the compiler is certainly
| out of the question. For everyone else, why do you think
| it would be an issue to use the C++ compiler?
| codr7 wrote:
| Because the complexity seeps in through the cracks, and
| with the language comes a mindset; same reasons Linus is
| wary about C++ in the kernel.
|
| Some say it works; I've never succeeded, even on solo
| projects.
| unclad5968 wrote:
| C3 and Odin are some other alternatives.
| alcover wrote:
| I often see such replies and wonder : the article isn't about
| choosing langs but is an exercise in C. That's the constraint.
| bsder wrote:
| If _C_ is the constraint, then why are you doing generic
| types?
|
| If you're using C, _use bloody C_. Not C with weird
| extensions that nobody will understand. Not C attempting to
| gussy up into a language with a real type system. Not C with
| a garbage collector. etc.
|
| I don't get why so many people use C but don't want _C_. This
| isn 't 1995 where you have to shoehorn everything into the C
| ecosystem because everything else sucked.
| spacedcowboy wrote:
| But ... all of those things are still C. Maybe with extra
| libraries / steps / whatever, but still C.
| bsder wrote:
| No ... this isn't C.
|
| Will it have IDE support for the abstraction? Will a
| syntax mistake explode with a non-sensical error (yes, in
| this instance, because you are splicing macros and a
| syntax mistake will splice weird)? etc.
|
| If you want C with Generic Types, use C++. Rather than
| splicing unknown garbage onto C, use a subset of your C++
| features and you will get full IDE support, proper
| template errors (okay, maybe not an improvement), proper
| elision and inlining, etc.
| spacedcowboy wrote:
| > No ... this isn't C.
|
| My test for whether something or not is "still C" is very
| simple... "Does it compile with a C compiler"
|
| These compile. They're C. End of debate.
|
| Whether something has IDE support is neither here nor
| there. When I was learning C, your IDE was "vi" and
| "csh"... It was still C.
|
| As for errors, completely normal C code can spew out
| errors up the wazoo if you miss an errant ;, " or } (to
| pluck examples out of the air) somewhere important,
| things like "function not defined" because you were using
| a function later on in the file and it can no longer be
| parsed. Error quality does not define the language
| either.
| lukaslalinsky wrote:
| See for example the last version, which is marked as
| "GOOD". It directly inlines all operations on the vector.
| The more you use it, the bigger the compiled code
| becomes. Need to debug it and want to set a breakpoint to
| vector_append? You can't. You also can't use
| callgrind/kcachegrind to see how fast the functions are.
| Yes, it's still C, but very awkward and finicky C.
| spacedcowboy wrote:
| My point was that this is still C, I wasn't advocating
| using any of it.
|
| People have different preferences though, so if someone
| has 50,000 lines of code invested in a C application, but
| wants to (for some reason) use generics in some way,
| perhaps this is their best option...
| dleslie wrote:
| I've never heard of CC before; the ergonomics of it look
| positively _modern_.
|
| https://github.com/JacksonAllan/CC
| juancn wrote:
| The Java example doesn't really compile due to generic arrays and
| mixing primitives and non-primitives, but the point still holds.
|
| Type erasure is still type checked though, it's just lost at
| runtime (i.e. the generics are not reified).
|
| This works for Java very well because the JIT will have another
| chance at further optimizations once the application runs.
| alcover wrote:
| > Type erasure is still type checked though
|
| In the C example ? What do you mean ?
| to11mtm wrote:
| If I had to guess, they were moreso referring to the java
| examples... The article states "The biggest issue is the same
| one Java had before version 5, there's no type safety"...
|
| But that's a weird way to put it... Java 5 was when generics
| were actually introduced... so comparing a C hack for
| generics to Java pre V5... is just... weird.
| huhtenberg wrote:
| > _I personally quite enjoy programming in "C with methods,
| templates, namespaces and overloading", avoiding the more
| complicated elements of C++ (like move semantics2)_
|
| Don't we all.
|
| Except for the committee, of course, and its entourage.
| marcodiego wrote:
| https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3509.pdf
| spacedcowboy wrote:
| Probably worth mentioning the C Template Library [1]...
|
| [1]: https://github.com/glouw/ctl/
| dsp_person wrote:
| I've found useful doing an implementation with void* and having
| thin macros to do casting with typeof() so the usage is type
| checked.
| jll29 wrote:
| > The former is nicer to program while the latter is nicer to
| use.
|
| When I have such a situation, I'm inclined to write myself my own
| pre-processor (as I did for Pascal once in a previous millenium,
| on an Atari ST 520+), so that you can write in a style that is
| nicer to program in, which gets pre-compiled into something that
| is nicer to use from your client code.
|
| Nothing comes without downsides: the price of this is that other
| developers need to understand your idiosyncratic pre-processor,
| so this method works best for "single author" code/personal
| projects.
|
| What you don't want in a team is each coder having their own way
| of doing things, so that you cannot share libraries and helper
| functions.
|
| BTW, the best book on the OP's topic of production coding in C
| and implementing type-safe ADTs is Chris Hanson's book "C:
| Interfaces and Implementations." It contains some eye-opening
| tricks even for experienced developers in (standard) C.
| RossBencina wrote:
| I wonder are there any existing metaprogramming frameworks for
| C? (something like C#'s Roslyn) I've been playing around with
| ANTLR and Python but curious to know what I've missed.
| usrnm wrote:
| C++. Only half-joking, this is exactly how C++ started
| dismas wrote:
| Objective-C started that was as well, too!
| WalterBright wrote:
| When moving into generic types and metaprogramming in C, your
| only real choice is macros. I've been down that path. It just
| never seems to work out very well, and the results were always
| unsatisfying.
|
| At some point, it becomes worthwhile to graduate to a more
| powerful language that still retains all the low level
| capability, like DasBetterC.
| tidwall wrote:
| Here's a b-tree library I wrote that uses a similar approach.
| https://github.com/tidwall/bgen
| cyber1 wrote:
| Unfortunately, the standardization committee plays around with
| macros and _Generic instead of investing their time in modern
| metaprogramming ideas
| codr7 wrote:
| This is how I do proper generic vectors in C, no template tricks
| needed and no pointer chasing involved:
|
| https://github.com/codr7/hacktical-c/tree/main/vector
|
| The problem was always pretending C is something it's not, that
| never works well in any language.
| wolfspaw wrote:
| Lol, thats insane.
|
| And awesome, I love it!
___________________________________________________________________
(page generated 2025-03-19 23:01 UTC)