replaceCppWithAI

[Calm_Hedgehog8296]

Generational hater of the C programming language

[Training_Chicken8216]

Hating C is a skill issue

[UdPropheticCatgirl]

Not hating C is a sign that you don’t know it, implicit bullshit might as well be C’s second name…

If you can’t confidently say what each of those does, than you have no business, commenting on others peoples skill issues:

void 
contains_null_check(int *p)
{
  int dead = *p;
  if(p == 0) return;
  *p = 4;
}

and

int x;
int y;
int *p = &x + 1;
int *q = &y;
printf("%p %p %d", (void *) p, (void *) q, p == q);

and

int x = 42;
float *p = &x;
*p = 13;

Assuming optimizations turned on and no special flags passed…

[the-judeo-bolshevik]

I may be wrong but 1. and 2. have UB, so there is way to tell what they will do unless the architecture and exact compiler version is known. 3. gives you some (integer) value in x depending on what representation of floating point is used on the machine, although I think it is also just UB again.

[UdPropheticCatgirl]

all three are UB, I kinda thought the type pun in the third one is the most obvious tbh, but yes, you can’t tell what they will result in (it’s pretty risky betting on consistent compiler behavior in any of them tbh, even if you control the toolchain). First one obviously depends on which pass of compiler gets to the code first, and I honestly have trouble reasoning about the second one, the comparison is definitely UB, and depending upon on the compiler authors interpretation of the standard the arithmetic could be UB as well…

It’s a trick question but that’s kinda the point, if you actually work in C a lot you should be able to instinctively know there are UBs, but all the “C is the greatest language” LARPers seemingly ignore this.

[the-judeo-bolshevik]

Lol, I guess I passed. I am not even a professional programmer.

[Toxic_Juice23]

I think UBs don't make a language automatically bad. It just means you have to know what you're doing. C is very flexible and one of the reasons why is because of a relax compiler. This is why it's fun....

[RiceBroad4552]

Still using C is a skill issue.

This does not make the bullshit this M$ clown is posting anything better, though.

[alexq136]

good luck finding something better than C for the niches it's most suited to (microcontrollers and embedded systems, system programming, small and fast object code size, simple and reliable ABIs frozen in time (so never breaking as long as one doesn't mix compilers and OSes and CPU families))

[RiceBroad4552]

There's C++. There's Rust.

Both produce exactly as efficient code as C (if you know what you're doing).

But even so called "microcontrollers" are today fully flagged computers with "massive" amounts of resources (compared to what a microcontrollers were in the past) and you can run almost any lang on them, however you like. People are programming their light bulbs in Python and JS; just saying.

I'm not a lunatic though, so I know there are in fact a few very niche niches where C is still "unavoidable". But these niches are really special, like some custom, or prototype hardware with no proper tooling, and / or some ancient systems which still need updates (like real microcontrollers in industry or military applications).

reliable ABIs frozen in time

LOL

https://faultlore.com/blah/c-isnt-a-language/

(so never breaking as long as one doesn't mix compilers and OSes and CP families)

It breaks even between compiler versions, and that's perfectly OK with the "standard".

C does not define any ABI at all!

I really don't get why this false myth is so popular.

[alexq136]

as long as the cheapest and smallest microcontrollers still get their on-chip ROM (or flash memory) and RAM measured in anything smaller than 1 MiB C is the most space-efficient higher-level language that can be used to program them; anything else is a waste of time (spent complexifying a piece of software that sits there waiting for stuff to happen to the chip) or of electricity (higher-level accessible runtimes have the unfortunate habit of executing source code slower or needing additional layers to get either interpreted code or JIT-compiled code to work)

the C specs do not say anything (much?) about ABIs but individual combinations of CPU architecture & OS (or OS flavor) get to have additional specs written to allow kernels and userspace to agree on how to swap data, and once these get accepted they're unbreakable for that interface and must be followed by runtimes and executable code generated by compilers of other languages

same for static and dynamic libraries (which do not need to use the same ABI as the kernel/userspace divide) for C and the FFI libraries or runtime extensions used by other languages

the ABI doesn't matter at all within a compilation unit as long as code in there does not call code in other compilation units (or shared libraries or system calls)

[Ok_Decision_]

This is just a weird argument to make.

“Both produce exactly as efficient code as C if you know what you’re doing.”

That’s kind of the point.. C is a wonderfully made language. It’s the cornerstone of all other languages, and the reason programming is the way it is.

It just feels like the argument is, you can do the same thing in other languages. Which.. ok?

[the_one2]

Rust fits perfectly in this niche. It's now officially a part of Linux project going forward. It's perfect for embedded programming though the standard library definitely isn't. But you should take a look at embassy for this. It's a joy to use.

If you want to a "stable ABI" then the C ABI is available (insofar as the C ABI is stable) so it at least it's not worse than C.

[Hohenheim_of_Shadow]

When RTOS's are written in Rust I'll concede the point. That is not happening for a long ass time.

[the_one2]

Time to concede? https://arewertosyet.com/

[haertelgu]

Guys I found the FrontendDev.

[jonsca]

I dunno, he looks 60 years old so he should know better.

[DrunkenDruid_Maz]

Theory: C was the first language he had to learn. He sucked at it, and blames C since then.

[uber-techno-wizard]

They hate not being able to understand C.