C++ this remind me of my university days
nowadays only doing python, nodejs and ansible
C++: The Documentary
291–300 of 334 posts
Re: C++: The Documentary
#292C++ needs to die. I get so many people are invested in it and so much code is written in it. I used to be a fan and it's still my main job. But, in 2026 with LLMs able to find all the exploits, and with more and more adversarials, we need a language that is opt-out of safety, not C++ which is opt-in + super vigilance to get safety. It doesn't work and decades of experience proves it.
And replace it with what?
Re: C++: The Documentary
#293Personal opinion: C++ is the most elegant language I have used (for about 15 years). If you are the 'systemizer' type and like to have an extremely precise mental model of the thing you write down to the last bit, nothing beats C++. I acknowledge the limitations and uncertainties that come from compilers etc, but still
I would think c would?
Re: C++: The Documentary
#294Earlier quoted context omitted.
Wow is this just a shitpost (it was funny!) or do your builds actually take about an hour? That's nuts, if so.
A fresh build of a large C++ project taking 1 hour does not sound strange at all. If that's an incremental build though (i.e. simply rebuilding after changing a few files), there's something very wrong.
Your org needs better distributed build caching if you can't get that number lower. All builds should be "incremental" with appropriate caching.
Re: C++: The Documentary
#295It's surprising that C++'s development trend continues. When a game or program is made with C++, it's usually nice because performance is mostly guaranteed. But if someone told me to write C++ myself, I'd cry. There's too much to memorize, and the standards are too varied. When I go to a project site for maintenance and it's a C++ project, I instantly lose energy — because it's just too difficult. I'd be happy if som…
> There's too much to memorize, and the standards are too varied. When I go to a project site for maintenance and it's a C++ project, I instantly lose energy — because it's just too difficult.
I've been feeling this way about web dev for a while now, and sometimes look at C++ devs with jealousy, wishing that the crazy amount of memorization/varied standards/rough maintenance/high difficulty I experience were only limited to the language that I write.
Re: C++: The Documentary
#296Ken Thompson's criticism of C++ as incoherent, complex and garbage heap of ideas still resonates with me; C++98 was the last version I used for work although I've dabbled in 11/17/20 out of curiosity. IMO, if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use, but then, that's its main identity which limited it in ways that C++ was not willing to change; It is highly irritating to…
The last one from Scott Meyers was the final nail in the coffin for me. The chapter about auto and template parameter deduction specifically. Since then, I've been happy with Golang and Java.
Auto is great
Re: C++: The Documentary
#297Ken Thompson's criticism of C++ as incoherent, complex and garbage heap of ideas still resonates with me; C++98 was the last version I used for work although I've dabbled in 11/17/20 out of curiosity. IMO, if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use, but then, that's its main identity which limited it in ways that C++ was not willing to change; It is highly irritating to…
> IMO, if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use
Obviously. C++ was a "better C" in that you could keep a lot of your "legacy" C code while improving your codebase piecemeal with C++ features. Your management didn't even have to care, in that C/C++ was accepted as a valid descriptor even by people who should have known better. It's a wonder Java/C# and Perl/PHP never caught on.
Re: C++: The Documentary
#298Ken Thompson's criticism of C++ as incoherent, complex and garbage heap of ideas still resonates with me; C++98 was the last version I used for work although I've dabbled in 11/17/20 out of curiosity. IMO, if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use, but then, that's its main identity which limited it in ways that C++ was not willing to change; It is highly irritating to…
Little known fact - when I was contemplating enhancing Zortech C into C++, I was concerned about AT&T's intellectual property. I contacted Ryan Williams (I think that was his name), AT&T's IP lawyer. I asked him: 1. do I need a license to create a C++ compiler? 2. do I need to call it something other than C++? He laughed and said, no, I could do whatever I wanted. He also thanked me for being the only compiler guy to…
I looked up my notes. It was William Ryan.
Re: C++: The Documentary
#299Earlier quoted context omitted.
I very much prefer to work in Rust but it does force you to design things in an counter-intuitive way in certain situations (linked lists for the canonical example). Specially for lower level software I find C or C++ to allow for much more flexibility and thus the most straightforward design possible.
I really don't think Rust does, but that's if you're outright refusing to use `unsafe` anywhere. Might be a little noisier if you're using things like ManuallyDropped instead of just using raw pointers, but the language doesn't stop you from doing things in ways you would with C or C++, it encourages you to encapsulate the hard parts so you can worry less about correctness of 98% of your codebase, instead of fearing…
That's absolutely correct. Wild to see it downvoted without explanation, while you preemptively mentioned the tradeoff that you do need to worry about correctness in that case (just as much as in C/C++), but that only applies to a small part of your codebase, so it's still a huge benefit.
The only downside is that unsafe rust is more verbose than C/C++.
Re: C++: The Documentary
#300Earlier quoted context omitted.
> a similar type, but whose size and capacity are fixed on construction and never change. There is std::array for that. Also, for a type with fixed capacity but variable (up to that capacity) size, we're getting std::inplace_vector soon™.
std::array requires the size to be set at compile-time, while I was talking about arrays whose size is determined at construction-time. Of course std::array is also quite the useful class :-)
You can construct the vector with a given size. As long as you don’t push_back, beyond capacity, these should be o dynamic allocations.
If you want to get f cy you can also give it a custam allocator and throw an exception if you do this by mistake