I still use some primitive tools, and know there are better alternatives, but I'm not going to defend sticking with them.
BTW, I did win the Obfuscated C contest one year, and (naturally) used the preprocessor:
I've also seen people use pages of algrebra as a substitute for a couple lines of calculus.
I struggled for years with a soldering iron, always frustrated by bad solder joints. Then, I discovered a Weller thermostat controlled iron, and get a perfect joint every time.
Not everyone knows there are better ways to do things.
You could do this with C++ templates, for instance. But the LESS and SWAP operations may or may not get inlined. With the C pre-processor you can be certain that the operations get inlined, since no other alternative interpretation is available to the compiler.
If someone asked, I would. But since I do have a dog in that hunt, I felt it would be more appropriate for others to make a suggestion, as there are several.
True. But modern inliners are pretty good, and if they can't inline it due to its complexity, it's pretty unlikely it'll be faster.
Note the performance comparison in the article.
Low level hand-optimizations paid off handsomely in the 1980s, but are usually best left to the compiler's optimizer these days.
We have experienced this with LDC in D.
What I've been told is that LDC produces better IR than clang (I haven't compared, I only know that LDC is practically magical from both mine and other peoples experiments).
About the only thing I've seen that has problems with inlining is inline assembly. Intrinsics are fine (which you don't need thanks to vectorization being practically magical as long as you do some annotations like assert and get the memory layout right).
Talk is cheap, show the code!
/* Sort 3 elements. */
void Q_SORT3(alias Q_LESS, alias Q_SWAP, Q_UINT) (Q_UINT q_a1, Q_UINT q_a2, Q_UINT q_a3)
{
if (Q_LESS(q_a2, q_a1)) {
if (Q_LESS(q_a3, q_a2))
Q_SWAP(q_a1, q_a3);
else {
Q_SWAP(q_a1, q_a2);
if (Q_LESS(q_a3, q_a2))
Q_SWAP(q_a2, q_a3);
}
}
else if (Q_LESS(q_a3, q_a2)) {
Q_SWAP(q_a2, q_a3);
if (Q_LESS(q_a2, q_a1))
Q_SWAP(q_a1, q_a2);
}
}
Note that D allows the following ways to pass a parameter:
1. by value
2. by reference
3. by name
4. by type
The alias parameters are "by name". C++ has by name parameters in the form of template template parameters, along with the restriction that such a parameter can only be a template. D allows any symbol or type to be passed by name.
Passing the lambdas by name means a direct function call/inlining rather than an indirect call through a function pointer.
Anyhow, with this example you can see how the rest can be fairly easily translated.
So, you might ask, what's the advantage?
1. name hygiene
2. your debugger will see the symbols
3. no ugly \ line splicing
4. no wacky do-while(0) kludge
5. the names are actual symbols rather than transitory apparitions seen only by the preprocessor
6. color syntax highlighting in your editor works
7. the compiler will check the syntax and give error messages in terms of the symbols, not generated preprocessor text
8. It's not going to conflict with another symbol named Q_SORT
In theory you might be right but I doubt it is applicable in this particular case.
None of the new languages managed to capture what makes C great
The few "modern" ones are interesting, Zig, Jai and Odin for example, I like how they took C designated initialization to the next level
Zig's comptime is also nice
D is nice, but is loosing its charm now that the competition is here.. also what used to be a D strength now is a weakness; it's slow to compile thanks to the std.. debugging still is a pain, and code can become quite overly verbose
But TBH I'm a bit tired of people shitting on the C preprocessor. It's a relatively simple text replacement tool, and provides an incredible amount of bang for the buck (e.g. many problems can be solved without having to add more specialized bells and whistles to the language). It's a trade-off like anything else in computing.
You mean something like a type checker?
C has been adding generics anyway, like _Generic.
The compiler was very basic, nothing like you'd expect from a compiler even from the dragon book.
So simple and it was a production compiler too!
Sadly I can't remember the name of it to reference here.
A few years later, I was at a C++ conference where they asked me to sit on an "Ask us anything" panel. I was there along with the developers of Microsoft C, Borland C, etc.
The first question was "do you still ship a version of your compiler that will run on a floppy disk system?"
Vendor 1 said sure, and launched into a long description of how the files could be shuffled about on the floppy to make it work.
Vendor 2 said sure, and launched into ...
My turn. I said sure, and said the floppy disk version costs $200 and comes with a hard disk drive. (That was the price of a hard disk in those days.)
That was the end of that, I never heard that question again from anybody.
Progress...
"_Generic" added function overloads to c, not generics. The naming is exceptionally poor.
The submission is an example of generic programming. It an implementatin of something that works on all types that fullfill certain constrains. In this case comparable and swapable. "All types" include user defined types.
"_Generic" does something completely different. The C++ equvivalent would be std::conditional_v<std::is_same<T, int>, myIntFunc, std::conditional<std::is_same<T, double>, myDoubleFunc ............ The exact opposite of a generic, I'd argue, as myIntFunc and myDoubleFunc do depend on the type. You might use the preprocessor to create these functions that differ only in type, but then again, you might do what OP did.
People often take bias to mean that a source is false or untrustworthy and I think this is a nice counterexample.