>C has been adding generics anyway, like _Generic.
"_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.
for a definiton of "just memory" that includes the strict aliasing rule. Certainly not a buffer of bytes, what most people would assume when they hear "just memory".
The strict aliasing rule that you point out is not part of the “just memory” part, but rather the “syntax sugar” part. Now you can debate if it’s the right kind of sugar, however.
"Memory" might not even be a concept in the C standard, rather it is what C programmers think about in practice. The culture around the language is that the language should get out of the way as much as possible while still providing a good amount of convenience, portability, and performance. The standard is a necessity, but is not the center of attention while working.
But then there's the memcpy escape hatch that lets you treat anything and everything as a raw sequence of bytes with no concern for types or aliasing. So arguably the fundamental memory model is still "just memory" (albeit not necessarily a single address space), and the rest is bolted on top and applies only to specific language constructs.
And outstreams where not that bad, aswell. Sure, the operator overloading looks a bit rough. But that's IMHO a pragmatic choice if you want to offer customisation points and didn't have variadic functions yet. They where introduced only in c++11.
Do you mean this feature [0]? I'm not aware of any differences in c and c++ about this. Can you get a type of a argument in C? How? At compile time, or at runtime? Both sound very un-C-like to me. cppreference is usually excellent documentation but it doesn't mention something like this.
I don't considers this to be "proper" variadic arguments, because a functions argument has to have a type. and these, as far as I'm aware of don't have one. This is about a powerfull as passing a void**. This is essentially memcopying multiple differently typed into a char* buffer and then passing that buffer. You can than correctly copies them back you have pretty much the same behaviour. Both methodss obviously lacks important aspects of the language abstraction of a function parameter and i don't what that feature can bring to the table that the previous techniques don't.
Sorry my bad. Yes, it works for proper function arguments. Does this work for variadic arguments? Parent seems to suggest, but i'm not aware of any mechanism for this.
When i want to print a string i don't want to worry about the security implications of that. With printf i have to. [0]
And i certainly don't want a turing complete contraption. [1] Also looking at log4j.
And even if everything is correct, it's has to parse a string at runtime. I consider that alone unaesthetic.
>Edit: It's almost like the whole world got a lot of work done with the tools they already had.
The best metaphor i know for this attitude is "stacking chairs to reach to moon". If you don't care about the limits of the tech you will be stuck within it.
I'm time and time again amused how anti intellectual and outright hostile to technological progress the programming profession is. programmers, out of all of them.
> And even if everything is correct, it's has to parse a string at runtime. I consider that alone unaesthetic.
Technically, it doesn’t have to do that. If a program includes the header declaring printf using the <> header defined in the standard and then calls printf the compiler is allowed to assume that the printf that the program will be linked to will behave according to the standard, and need not compile a call to printf. It can generate code that behaves identically.
> If you don't care about the limits of the tech you won't be able exceed what you think is possible.
Did you propose/implement/release something better than printf?
> I'm time and time again amused how anti intellectual and outright hostile to technological progress the programming profession is. programmers, out of all of them.
Perfect is the enemy of good. Some people talk about getting work done, some people get the actual work done and move on.
> Perfect is the enemy of good. Some people talk about getting work done, some people get the actual work done and move on.
In my experience, people with this motto generally produce code which frustrates the whole team.
Being a perfectionist is toxic in its own way, though.
There needs to be a balance. I think that balance is to think and plan a few steps ahead (not too much, as it's counter productive) before hitting the keyboard. I know this sounds a bit like a "d'oh, of course" but it really—and unfortunately—isn't something that people practice; they just think they do.
Lets consider #embed which is new for C23. It allows you to import binary blobs of data into a C program at compile time. Like say if you want to import an image or sound file or a table.
How hard was that to implement? Seriously no reason it couldn't have been part of C89. Why wasn't it? Because the compiler writers and the C++ standards committee have no personal use for it. It took 40 years of waiting and five years to get it just barely past the standards committee. If you think no one would strenuously oppose a feature like embed you'd be wrong.
Those guys also have no interest in printf type functions. And improving printf would be a lot more work than implementing #embed.
That’s neat - Borland C had the same thing with the `emit()` pseudo-function with their C89 compiler. I guess Borland’s compiler writers wanted it more than gcc’s?
Consider the difference between what a compiler does and say a video game or embedded firmware. Compilers are old school batch mode programs that import data from a file, parse it, transform it to something, and emit it as a file.
These people's "actual work" often ends up causing endless streams of security vulnerabilities and bugs too.
Most of the same people you are referring to don't seem to believe that security vulnerabilities exist or are important enough to care about for some reason, but in the real world these are very important issues.
> These people's "actual work" often ends up causing endless streams of security vulnerabilities and bugs too.
On the other hand, we have people that apparently wouldn't make a program if they are not guaranteed (by another human being) that it will be safe.
If those people generating bugs and vulnerabilities would had to sit tight waiting for someone to make a safe language to do anything, today the world would be 40 years or more behind.
(safe languages that, sarcastically, were created using all those unsafe tools and insfrastructure)
Also in this real world a trillion of printf are being output right now, and will be for a long long time. Is the world falling apart?
You can also list all the printf CVEs but... how many println! are being output?
Everything has security implications in c, but printf isn't particularly bad. Common use of it involves a fixed format string specified at the call site. This prevents the most dangerous use of it (user specified format string) and also allows the compiler to detect when the format string doesn't correspond to the types of the arguments. Both these failures can be converted into compile time errors in common compilers. Printf, for all C's other faults, really isn't that bad.
I think you are looking for (one specific implementation of) Cold district heating.
It can be implemented as a single line of force water flow with 20-25 Celsius. It is viable as both a heat source and a heat sink at the same time.
This thing can be connected to both your coolers and heaters, and thus transfere heat from one to another. Maybe you could even get you desktop computer into the loop.
Usually it implemented on a lager scale, but i don't see why this would work scaled down.
Seatbelts have issues. Some of them undiscovered yet. What suggests that Seatbelts won't introduce issues that will be larger than the 70% of issues that it solves with crashes? Because to me, it just sounds like we can't know so we're being hopeful that we don't run into that situation.
What a ridiculous way to make an argument. Even a silly seatbelt had to wait for about 10 years after being released before it was required to be in cars. Maybe write a few other kernels in Rust before using it in billions of devices? But no, shoot straight for Linux because "C bad, Rust good".
If professional chefs would constantly maim themself and each other despite extensive occupancy safety training, knives have no place in the hands of a responsible professional.
Using C is the SE equivalent of taping down one button of the two-hand control device of a die cutter.
Kernel hackers are considered the most skilled people in the whole profession. The Linux kernel is one of the most read source code on the planet. The code is audited to death. Much of the research into static code analysis starts there. They have tools available most other people don't. That's what i mean.
If, what ever the happens there, is not up to your standard of professionalism, maybe your standard is unrealistic?
That's not training. That's being thrown in the lake to learn how to swim.
Now you're measuring how many people drowned, and you're saying "let's enforce that everyone use a flotation device, and there will be fewer deaths".
Sure, but there will also be fewer actual swimmers.
To make this more concrete, you can't look at something in aggregate and say "well, we are having this one type of issue, let's just throw everything away and start over".
Yes we must do something, I just don't think that Rust is the best answer. Maybe have an actual safety training. The language is hard. Write a compiler for it, study the spec, simplify the spec, upgrade the language, etc.
Just because you didn't understand my argument doesn't make it in bad faith.
If working on the Linux kernel is the training then you're measuring incidents that occur _during training_.
The whole point of training is to practice and make mistakes _before_ the actual work. Once they're considered experts, you can measure the knife cuts in their work.
Some of the first software I ever wrote was C and then C++. I’ve since worked on Billion+ line Java code bases. I’ve also worked professionally in python, ruby, Type/JavaScript.
When I picked up Rust 15 years into writing software, it taught me to write better code.
Let me repeat that: even after extensive training and professional use of other languages, rustc the compiler taught me to write better code.
If you’re looking for a “we should train people better to not make mistakes” you want people to learn software development from rustc. That training is very transferable back to C and C++ and even Java. Could this automated “teacher” be better? Sure. Could it be less strict? In certain cases sure. Is it the best training program we have? This best I’ve ever seen.
I understand your argument. It works with starting from a massive misrepresentation of what I have said (aka bad faith). Your argument is fatally flawed due to the reason i stated. And that's why there is nothing to be said to the substance, other than what was written and this discussion was and remains over.
>It does not misrepresent what you said, and failure to see that means you did not actually understand it
Oh yes, I do. I do know what i mean and I can see that your quote of it was either extremely unintelligent, something you can by definition not see, or intentionally miss representing and therefore bad faith and therefore something you by definition lie about.
I'm heavily leaning to bad faith, because you never make any attempts to refute arguments anywhere in the whole thread.
So, of course, I'm obviously correct on on this one, so it's good thing either of us wasted any time talking on the substance.
It's like telling people you are burning a puppy with napalm "for demonstrating the effect" at an anti-viet-nam-war-protests. First people get crazy angry at you, then they change their attitude about napalm.
Perhaps. But convincing the military to replace napalm with a variety of other weapons - also designed to hellishly maim and kill people - is not exactly a huge moral victory, nor a big defeat for them.
Vs. the big oil companies, culture-war conservatives, etc. might be considerably more invested in giving little ground on climate change.
"_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.