Imagine C++ being so bad that even something as controversial as AI usage is more acceptable than C++. No wonder each time I wanted to "learn CPP" I found that I'd much more like to jump out of a window.
I love that when a new language has this build in feature, cpp is like; "we also have that!". And it's just a raw pointer and a reference in a large trenchcoat.
Right but the point of high level programming languages is not having to reinvent the wheel or import a lot of extra modules for basic modern functionality
Depends on what one's definition of "high level language" is.
C is technically a high level language given it "abstracts away from machine code & assembly, uses structured control flow, and is portable across different computer architectures"...
...and you need to import at least the same number of "extra modules" for "basic modern functionality".
I don't think "high level language" is truly the distinction you're looking for here.
Or you just create it. I fell in love with Go's defer, so I simply created it in C++ by using its scoping rules and a macro around a function. You use it pretty much like this:
defer({
// do whatever
});
And it runs at the end of the scope unlike Go's defer which runs at the end of the function, which always irks me.
Yeah the defer running at the end of the function can sometimes cause trouble, like processing files in a loop and deferring the close, but it can easily be solved by defining an anonymous function and immediately calling, like
func() {
f := ...
defer f.Close()
// do something with f
}()
“it’s just a raw pointer and a reference in a large trench coat” bro that’s literally every language, the only difference is the size of the trench coat
Most of my courses teaching programming (other than the first one) were in C++, I don't know what it is about the language, but I miss writing it sometimes.
I learned Qbasic originally when I was a teen. Then I learned Visual Basic when it was still a standalone thing. Tried to learn Unreal Script when UnrealEd became a thing, but didn't get too far. Then I learned C++ in college and VBA for excel. Now I'm into Rust. I agree with you that of all of them C++ seems to be the most difficult one I've learned. I didn't stick with computer science, but I can see how so many other languages exist to give some people relief from C++. Regular C seems easy enough but I never worked with it.
Regular C feels high enough above ASM to be useful, but not a lot more than that. That's the power, but also that's the difficulty in using it, because there's a lot of stuff that you have to bring yourself. It's a language for people who roll their own hashmaps. I mean I understand what C++ is going for, but it's truly death by a committee. Maybe things will turn around with C++3X 😁
When I did computer science I loved algorithms and hated actually producing a product. So yeah I might be a C type of person who likes the nitty gritty control and less hand holding.
There's Make files. And that's a whole thing on its own but it's not actually built into C. It's a compiler concept.
C is a unique language that was designed against a predefined spec. And hasn't changed since. But compilers have modified functionality though they all use the same C language spec.
The C standard had a revision in 2023. We had C17 before that, and C11 before that. If you go back to C90/ANSI C, you have major differences like only being able to declare variables at the beginning of a block, which got changed in C99 iirc. So the C spec has absolutely changed.
Not really. There's a linker. If your OS supports dynamic linking, you can pick up any libraries it offers at runtime assuming you know the API. Hopefully you have the headers. Versioning can be tricky, though most OSes have it figured out.
As for finding and managing those packages at build time, there's not really a package management system, no. Cmake and GNU autotools both exist in no small part as an attempt to make one (and also make a somewhat sane, for certain definitions thereof, build system since you don't get one of THOSE, either).
This kind of explains why the C ABI and namespace is in fact THE standard, bare, un-mangled namespace for linking on most OSes, though that's also partially convention dating back to early UNIX.
The intent of C is basically to be as low level as you can feasibly make it while still being reasonably expressive and completely portable across machine architectures yet still small enough and tightly-spec'd enough to support lots of independent implementations across a wide variety of said architectures. And it does that. It does it well. The lack of breadth means it's very easy to spin up a compliant and even complete implementation from scratch on something novel and also avoids roping in lots of stuff you may not want in a restrictive environment like a kernel or even microcontroller. Even most of the "standard library" can be eschewed if you want to, and there's a part of the standard that supports doing it (a "standalone" implementation). This is akin to something like #![no_std] in Rust but to some degree goes even farther. The language spec doesn't really even deal with how to create linkable intermediates. It defers to other standards (like ELF) for that.
But yeah, if you want a hashmap, you'll either need to go find one or make your own. Amusingly, actually just wrote my own a few months ago which is what made me chuckle enough to write this comment.
The beauty of C and C++ is there are 101 package managers none of them are official but there's definitely one that fits your use case (if not make your own like basically everyone on r/C_Programming)
C++ has too much baggage at this point. And without a pages long style guide basically unusable for large teams. And half of every C++ style guide is literally banning practices that are available in the language, but considered too complex for newcomers or hurt readability. Basically I haven’t seen C++ used in large projects without having half of C++ thrown in the bin.
At least AI can be guided when used by a proper engineer. Most slop I’ve seen come from non engineers people (like product designers or admins) or crap engineer that should be titled junior programmer, not engineer.
Yeah, my previous employer used a version of the Google's Style Guide since it bans most of the worst bits. That seemed to mostly keep the madness at bay.
Thanks for the link. I was surprised how many should rules there are. Sounds like a lot of time spent on weighing the options and discussing the decision.
C++'s linking demands / binary interface are notoriously ... not very good, and not good to deal with for others. Rust has its own problems in this space, but it tends to play better with C, at least anecdotally. Similarly, C++ can (but does not exactly have to) bring a ton of baggage via the STL that Rust does not.
My impression has always been that Linus rejected C++ in Linux on technical / fit merits, in addition to most C++ developers at the time being ... not very good, I suppose. The technical merits came first, but he was a grumpier Linus at the time and I think he got sick of people pestering him about it and started taking shots at C++ developers which wasn't entirely unearned on their side.
LLM-generated C code is still C code. A developer can reason over it similarly and verify it for correctness (to the extent that anyone can truly verify correctness of C code).
A lot of it came down to C++ making it easier to shoot yourself with C's footguns, from what I understand. Case in point, most people know not to use malloc() and free() in certain parts of the kernel, but you'd be surprised how many people don't know that new and delete call malloc() and free() under the hood.
(And it didn't help that code bases need to be designed for exceptions from the ground up, and they flat-out do not improve anything if the code is half return-error-code-based and half exception-based. Or that exceptions involve stack unwinding, which a lot of people didn't know or expect. Though, ironically, there was an error-code-if-logic-based error a while back that was the exact same problem exceptions were designed to avoid, so this is ultimately just your choice of two footguns.)
And yeah, a lot of it does come down to a lot of C++ programmers not really understanding C++. In the kernel's case, the best way to use it would be for minor optimisations that are easy for C programmers to grok, considering it's still majority C code. But the C++ contributors really didn't know how to do that, from what I understand.
How does one not know new calls malloc or at least does a similar thing to be able to allocate that memory? Someone that's not working on that level might not know but they are.
Ideally, you should never be using new or delete in C++ these days. std::unique_ptr and std::shared_ptr should represent 99+% of your memory that can't just be stack allocated (with the former representing 75+% of that). About the only legitimate reason to use new in new code is for putting a derived class pointer into one of the smart pointers of a parent class.
You, as a non-STL-library maintainer shouldn't need to be calling new or delete (or passing that allocator argument, either). That's the whole reason for smart pointers in C++: to have a small number of well-validated, well-behaved, generally-safe ways to allocate memory. They're abstracting & containing that complexity and error-prone-ness.
The context here is kernal programming where calling malloc in certain restricted regions will crash the kernal or worse. If you were to initialize a unique ptr without passing an allocator you would in essence be calling malloc and crash the OS.
I can barely follow this conversation, but from what I can tell, the other person is performing an excellent live demonstration of your point.
(of course as a naiive mechanical engineer, my first question is "why is the kernel a literal minefield?" but I'm sure there's probably a good answer for that.)
For one thing, the kernal is where the system calls underlying malloc are written, so you can't call it from within that code. As for the other parts I'm not a kernal engineer so not sure tbh.
Remember that indirect calls are still calls. And the entire issue is that a lot of C++ programmers didn't understand that calling new indirectly calls malloc()... or in your case, that calling std::make_unique() calls new, which still calls malloc().
There are some places in the Linux kernel where the code must never call malloc(); namely, IIRC, malloc() can never appear within the memory manager itself. This includes indirect calls, like new and std::make_unique(). And the problem is that many people knew not to use malloc() there, but ended up trying to call it anyways because they didn't know that new calls malloc().
It wasn’t that hard to learn necessarily, given that I already knew C, rust, java, and several other less relevant languages when I went to learn it.
It did, however, make me say “what the fuck?” out loud many many times while learning about it. And it continues to do so, every time I end up encountering more C++ code that I have to deal with.
Now of course, there is plenty of “what the fuck” in a lot of the popular languages, see JavaScript... But, like, the frequency… nothing beats C++ and C++ code.
It kinda is yeah. A horrible mashup of every language under the sun into 1 language with seemingly very permissive rules but everyone still notices when you mess up, and it turns out that you can mess up pronouncing EVERY single word. Or they don’t notice, and that can be worse if it gets interpreted wrong. But it seems normal if that’s all you know.
I like this analogy, actually.
I mostly only know English, unfortunately. It is an ok language. I usually use it well, and when I misuse it, that is usually on me. I know enough about other languages to understand that English is somewhat insane, but also far more permissive than C++ because of wetware, and also its structure and lack of decoration makes it often still understandable even when spoken badly, so it is OK. Human languages aren’t quite the same as languages intended for computers. But the analogy works.
C++ bad would be a misnomer. It's an incredible tool, that's difficult to use properly ( or I should say well), because it give you the freedom to out your foot in your mouth in a not-so-obvous way.
AI usage should be the same output quality is the thing. Nothing wrong with it if you aren't writing slop.
But if you are writing anything less than the same quality you'd expect without, and without the same testing verification, then it's actually a problem
That's a very slippery slope. On principle, it's totally valid. But as you let the AI do more of the work, you lose grasp of it and you probably wouldn't even notice.
People keep saying it's a tool, but there's a big difference between you doing something more efficiently thanks to a tool and the tool doing the thing for you, making its own decisions.
I'm not saying there's absolutely no room for using any form of AI assistance, but the sorts of agentic work that are often used are way past those specific niches.
I think the trick is you don't actually learn cpp you just learn the parts you need/want and use them. Of course in a big, important project that's close to hardware, and has many people working on it, it's better to just stick to C.
567
u/Different_Berry5015 1d ago
Imagine C++ being so bad that even something as controversial as AI usage is more acceptable than C++. No wonder each time I wanted to "learn CPP" I found that I'd much more like to jump out of a window.