141–150 of 196 posts
Earlier quoted context omitted.
It is part of the C standard. Whether it is part of a separate binary is an implementation choice.
True on both counts. But they are still separate and distinct languages.
Earlier quoted context omitted.
When all you have are arrays, everything looks like a problem you solve with arrays. There are quite a few problems that specialised containers are suited for, that's why they were created.
And you can write them when you need them. The situation where you need a red black tree with 10 different key/value combos isn’t real.
Another way is to not try to write generic data structures. When you tailor them to the use case you can simplify. The #1 data structure in any program is array.
Earlier quoted context omitted.
Surely part of the problem is having a distinct term and handling for parameters passed to functions. What is the point? It seems confusing with no upside.
Do you find the difference between abstract and concrete confusing? Or the difference between container and contents? Is that a pointless distinction with no upside?
For my own hashmap implementation I followed a wasteful aproach since I’m. It targeting embedded.
I created a structure called a hashmap object. It has two elements: a void pointer and a char pointer. The first one is the data and the second one is the metadata. The metadata is basically a string were the user can put anything, the type of the data, more data, whatever.
Then I preallocate 10s of thousands of hashmap objects. That way users of my hashmap don’t have to think about aollocating and de allocating hashmap nodes, they just insert, delete and search freely. They still have to care about allocating and de allocating they’re own data though.
Earlier quoted context omitted.
That's possible, but then the people building your extension need a C++ toolchain. The question was "please provide examples where switching to C++ involves jumping through even more hoops", and in my view requiring downstream to use a C++ environment when they're expecting to use a C environment qualifies.
Most C compilers are C++ toolchain as well, we are no longer in the 1990's. Unless of course the project is using such a old compiler.
> Structurally identical types will be considered the same type in GCC 15 and Clang later in 2025 thanks to a rule change Beware that only tagged unions are considered the same type under the new rule, provided they have the same structrure and the same tag. The List(T) macro should be changed to generate a different tag for each different T. Which is trivial (with ##) for simple one-word types, but impossible for ev…
> Beware that only tagged unions are considered the same type I don't get it. Tagged union is just a design pattern.
> struct { ... } foo;
> struct bar { ... } foo;
Earlier quoted context omitted.
i am firmly of the opinion that compiling to c is a better route than doing clever c tricks to sort of get what you want. the compiler can be pretty minimal and as you note it pays for itself.
There’s some prior work called CFront. It implements a superset of C that’s just an “increment”. I think it’s worth looking into, it might take off one day!
I think the idea of using a union to store the element type without any extra run-time memory cost might have some use, specifically in cases where the container struct wouldn't typically store a variable of the element type (or, more likely, a pointer to the element's type) but we want to slip that type information into the struct anyway. However, the problem that I have with this idea as a general solution for gene…