Writing new C++ code with all the modern approaches and tooling doesn't sound so bad.
Troubleshooting a big legacy C++ codebase is probably something that Dante would have included in his Inferno as a punishment for pride and hubris.
Troubleshooting a big legacy C++ codebase is probably something that Dante would have included in his Inferno as a punishment for pride and hubris.
Uh, but it still kinda sucks, if only because the nice way that looks idiomatic is usually the incorrect way for either performance (anything newly added like std::variant or std::optional) or safety (operator[]).
The correct way is usual the ugly way, because it seems like the committee puts C++ arcanum knowledge above all else, instead of developer satisfaction or maintainability
At least the C++ compiler is doing actual work. And it is faster than the webpack madness.
I don't know where you got that idea from, but with an up-to-date compiler variants are safer and more performant than the traditional approach (classes hierarchies), and std::optional is safer and 99.9% as performant as a nullable pointer.
Except for it taking up twice the memory as a pointer (https://godbolt.org/z/5We9zEbvh) and it not doing anything in regards to safety when using pointers. Even if you're replacing a nullable-pointer with a std::optional you're still handling landmines when using operator* or operator-> - the most convenient ways to use std::optional.
C++ is doomed forever to have safety-third design.
A modern project should be able to use most of C++17 at least. Even if you still need to target some ancient garbage like Windows XP, you can use an MSVC toolchain that supports C++17. That's a good basis to work from.
So your real concern is the moldy old code that's written for C++03, that's still not using std::unique_ptr or anything equivalent. If you're given license to finally rewrite that code to modern standards, that can be fun if it's not a complete mess. But if you just have to live with it, and still write C++03, absolutely not, I would never do that job.
But that's mostly learning modern paradigms of the language.
If you also mean the tooling, then it depends: Learn CMake which is sort of an industry standard. There are books and videos, but for a concrete experience, try looking through the CMakeLists.txt of some non-trivial C++ open source project.
Probably the best resource for CMake modern best practices/ rational of those practices.
Most tutorials online are outdated, CMake documentation is hard without a firm mental model of how it works.
You say that like there's one for a project but I've been learning Blender's codebase and every folder has a CMakeLists.txt. What gives?
Use clangd, clang-tidy, cppcheck. (These will tell at you if not using best practices)
Use the stl as much as possible (or at least make "would this work using stl" your go-to question.
Write a vector with iterators from scratch in c++20
Then you aren't choosing C++20-something, you're choosing a new language altogether.
This is why the demand for C++ devs is dropping - if you're going to bite the bullet and rewrite, why not choose a better language, preferably with GC?
It's not like C++20 is completely different. There's just a lot more utilities in the stdlib so hopefully less raw pointer magic.
What was best practice for C++03 is not the same for C++20.
Switching a codebase from C++03 to C++20 for a nontrivial codebase means changing design so radically it may as well be a new project, rewritten from scratch.
It'd certainly be easier to rewrite in C++20 for the C++03 projects I've recently worked on, than to try to squash in a C++20 design.
- Immature compiler susceptible to generating performance traps
- Build times even longer than the infamous ones in C++
- Simplistic declarative-based build system
- Inability to opt-in or to opt-out from static analysis
- Harder to scratch up quick PoCs because borrow-checker
- More complicated compilation model making it harder to understand, debug and implement workarounds when codegen goes south
- Much smaller ecosystem - libraries, toolchains, tools, ...
- False sense of security - by default it relies on the ecosystem whose runtime and its OS is implemented in "unsafe" languages
- Cannot even live to its "safety" promise because hardest problems cannot be solved without unsafe sections
I sincerely wish it was different but at this moment I am not convinced that Rust trade-offs are worth switching to it. This is the PoV coming from a system-level programming, very close to the OS, and with a lot of difficult memory and concurrency scaling issues.
... with deadlines measured in hours.
I spent two months asking one guy who knew about it for help. I really understood the concept of "hostage taker" in a software team. It's the guy you cannot fire and will constantly arm-wrestle everybody where there is a problem, never really helping, and continuing to write bad code that allows him to keep his job.
Fortunately they did not hire me.
I never was so discouraged in my life.
I don't understand this, where you working for free?
This is, obviously, a very opinionated opinion.
If I was going to be forced to do it, this is how I'd want to do it.
I write software in probably a dozen languages, including C++, and using the features/STL in C++17/C++20 in no way makes using C++ a "pleasure", it simply makes using C++ "less painful".
If I want to present information processing applications to users, it's C#/Java (or Kotlin, or Scala, or F#) with some Typescript front-end and likely some form of SQL simply because those are the tools that enable me to accomplish the job the fastest with the highest quality. If I need software to work in or with embedded systems then I grab C simply because it's the tool that enables me to accomplish the job the fastest with the highest quality. If I need some software to bridge those two worlds then I reach for C++ because it's the only tool that efficiently bridges the gap.
And C++ sucks, even with C++17/C++20/STL because I can't tell from the STL documentation which pieces manage memory for me and which I have to remove on my own and when this memory management (sometimes) magically occurs. I know what it is with C, because it's all malloc()/free(), and I know what it is with JVM/C#, because it's managed for me, but with C++ it's an incomprehensible mess. Don't even get me started on the half-assed implementation of lambdas vs. function pointers vs. std::function and which can be used where and where the const/reference operators have to go.
I know C++ memory management like the back of my hand and much of the STL (with some C++17+ exceptions) by heart. But even though I’ve used both C# and Java in the past and could jump back in, my working knowledge of those languages right now is near zero.
Polyglots truly are jacks of all trades and masters of none.
Modern "pleasant" C++ is a subset of all of C++. In the realm of all C++, you can get into some REALLY bad code. That includes terse C.
I work in the NYC market, and have bounced between finance and tech. The quality of C++ at a tech company, even legacy code, is magnitudes better than the stuff in finance.
I’m lucky ;)
If you care about it, it can and will be done. Same, all warnings enabled, compiles and runs in both AMD and ARM processors, it is just 20 to 40 times faster than the thing it replaced, I really can't complain.
C++ gets underserved hate by people who don't care about doing a good job anyway.
C++ today is like Cobol in 2010. yes, there are reasons for them to exist, people tell your the good old days, probably some fresh good recent experience. but come on, there is a much better place for C++ -
Gaming has Unreal but surely you could use another game engine without C++?
For most software, the hardware has already run away to the point where you can just sort of tell the machine roughly what to do and it will do it for you in a way that doesn't affect your task, so you don't have to fiddle with minutiae like where exactly to place a thing in memory.
bumpalo doesn't cut it. Funny thing is that boring and sensible Go just came out with arenas support.
I use C and Rust for such serious stuff as I don't have free time to waste to just entertain those over designed concepts like OO or STL. you need to be honest - the stdlib of C++ is not on par with the ones in rust or golang. It is more like stone age tools compared with starlink.
I sincerely hope that all C++ users will be able to benefit from the networking addition to the C++ stdlib before their retirement - you know after 40 years waiting not all C++ developers had such pleasure.
that would the starlink whose performance slowly, inexorably degrades as more and more of my neighbors start to use it?
We release the same plugins on Windows, macOS and iOS so we get great coverage with compilers too. I should set up a build for Linux with gcc but haven’t had the time yet.
to give you some example - using the exact same toolchain on amd64/macos, I can build my golang code to run natively on risc-v/linux or arm64/windows. everything happens within seconds as I just need to override two environmental variables.
there is no "haven't had the time yet" problem in such modern languages. it is by design, in the very core of the language and its native toolchain.
first of all, audio plugins come in a variety of formats, some of which are 100% platform specific (AudioUnits, Apple, I'm looking at you). You can be using the same toolchain across N platforms, but that won't make any difference to the fact that you're having to generate code that integrates with multiple syntactically and semantically distinct APIs.
secondly, in the audio plugin space, SIMD is often a vitally important tool. no cross-compiler or cross-architectural tools there, unless you opt for a common denominator so low it's not really worth anything. You want SIMD? You can't use anything that crosses compiler and/or architecture boundaries to any meaningful extent.
thirdly, in the audio plugin space, you need to create GUIs that run inside the host application. there's no good solutions for this that span linux/macos/windows, though there is the not-so-good solution of using JUCE ... except that a solid chunk of the folks who use JUCE don't use the GUI part at all. the idea that this stuff could ever be a feature of the language and span even just those 3 OS'es is ridiculous assertion and I wager will never be realized. there is no standard C++ GUI API for good reason, and the same reasons are why there will never be one for Rust or golang either. Just look at the list of GUI toolkit crates floating around out there already.
fourthly, "building" doesn't just mean compiling. the process of creating a packaged audio plugin will vary by plugin format, and by platform, and is often one of the most critical tasks that is so often slightly screwed up. once again, golang and rust are never going to contain builtin tools for this process - that's going to have to come from some other layer of your toolchain. granted, portable build tools do exist, but they are almost necessarily language agnostic and thus violate your assertion that it must be a part of the language's "native toolchain". the process of creating working software in general often transcends the language specific parts. once you have a set of object files, creating an executable has as much to do with the OS process launch conventions as anything in the language used to create the object files.
you also need to worry about which stdlib to use in C++ - too bad!
> SIMD is often a vitally important tool. no cross-compiler or cross-architectural tools there, unless you opt for a common denominator so low it's not really worth anything. You want SIMD? You can't use anything that crosses compiler and/or architecture boundaries to any meaningful extent.
please stop such nonsense. AVX512 was extensively used in our golang codebase, the support was added to golang like 6 years ago.
> the process of creating a packaged audio plugin will vary by plugin format, and by platform, and is often one of the most critical tasks that is so often slightly screwed up. once again, golang and rust are never going to contain builtin tools for this process
why this is even related to the ongoing C++ discussion? once you have the package, you need to somehow distribute it, app store, http service, bittorrent you name it. but why it is even relate to any programming language since you brought it up here?
you can probably argue that golang's stw isn't going to help when building audio stuff, but there is just no reason how anything that can be done by a legacy language known as C++ that can't be fully handled in a more efficient way by rust. audio plugin or not, I don't care, in the end it is just the same machine code.
Well that's nice. What about ARM SIMD? And the M2 variant? You're suggesting that every SIMD instruction set should be accessible via the same language-invariant syntax or else a language is just broken?
> but there is just no reason how anything that can be done by a legacy language known as C++ that can't be fully handled in a more efficient way
the point is that it is NOT done by a legacy language known as C++, and it should not be done by the young languages that go by any other name, contrary to your claim that essentially everything should be a part of the language/compiler/toolchain itself.
I may have exaggerated with the “nearly every” sorry!
But we do use sufficiently enough tools to avoid most of the pain of c++
C++ has wide use, and will continue to have huge use, for both old, current, and new codebases, in tons of areas, from systems, finance, and OS, to scientific and games.
you know people collect old cars, computers, stamps as hobby, tens of millions of people are into that. for the exact same reason, there will be people who are just into writing software using legacy tools. I totally understand & respect such decisions.
Almost in every case, you'll find C++ at the core of them.
Last couple jobs have been heavily legacy C++ in the energy sector.
Lots of maintenance, but also opportunities to overhaul and build new objects.
Funnest project right now is porting some supercool Science code to cuda and getting about a 30x speed up.