I also know classic C++ and used it professionally, although it wasn't my main language. I've started using more C++ 11, 14, 17, lately. Particularly with constexpr, and some more stuff with templates and smart pointers.
I would say the experience is about what you would expect. There are some things that are great, that are cleaned up and more consistent. There are more conveniences. But then you run into weird edge cases / quirks, or a cascade of subtle compile errors, and just use a macro instead.
I'm writing a garbage collector and there are a bunch of things where it helps over C, but also a bunch of areas where it falls short. In summary, C++ is still great and frustrating at the same time. If anything that property seems to have increased over time: It's even more great and even more frustrating than it ever was :) Coroutines look like another example of that.
"worth the effort" is very difficult to quantify. If you haven't touched C++ in a while, I'd say the things in C++20 are intriguing, even if half-baked:
* ranges means that we're starting to get composable algorithms. Compared to doing `for_each` and then `accumulate` on a container, you can compose both operations into one reusable "pipeline" of operations. I really grew to like this from other languages, and am glad that C++ is starting to get it
* modules will help a lot, but I doubt we'll get widespread use for another year at least (until cmake has it; build2 has it, but that's a bit esoteric even though it's very pleasant to work with)
* concepts make working with template-laden code a lot easier. Most of the tricks for obscure SFINAE removal of templates are no longer necessary; one can just express it in a "positive" way as if to say "the thing matching this template should have these properties", instead of convoluted ways to turn off templates under certain circumstances.
* coroutines are very half-baked, but when combined with executors (which will hopefully come in 23) it will really be useful I think. The stackless nature makes them hard to reason about, but trying to add stackful coroutines would likely be a non-starter; it would require a lot of runtime support and modifications that would either require a lot of performance overhead OR backward-compat difficulties.
That said, unless you want to actually use it to DO something specific (e.g. make a game, work at a specific company), Rust or similar languages are probably more pleasant experiences. Without a standardized build tool with sane defaults, it's hard to just play around with things in a fun way. Trying to figure out how CMake + Conan works will take beginners at least a day in my experience, and the lack of a solid template "good defaults, applicable most places but easily changeable" for the build system + dependency system makes things a bit tedious to just try things out.
As much as I like some replacement candidates, C++ is everywhere, so if you want to do anything related with graphics, machine learning, compiler development, OS drivers ,IoT toolchains, and not having the burden to sort out infrastructure problems by yourself, then C++ is the less painful way to go.
Some would say C, but in domains like machine learning, you really don't want to write plain old C for what is running on the GPGPU.
Yes, you do not program in C++ because you want to program in C++. You do because a lot of cool, interesting (and yes, well paid) stuff is done in C++.
Still, with all its issues, I do quite like the language, but unless you want to work on some industry that is C++-centric, I do not think it is worth learning just for the sake of it.
Same here, I keep referring how C++ was the upgrade path from Turbo Pascal because I never came clear with bare bones C.
Since 2002, it has been a mix of .NET, C++ and Java, with my C++'s usage decreasing since those days, yet it is never zero, there is always a library or OS API to create bindings for.
I also like the language, but I definitely do not fit the culture of every ms and byte counts that they inherited from C.
On the C++ code where I have full control, RTTI, exceptions and STL bounds checking are always enabled, and I am yet to find a project where it mattered to have done otherwise.
Depends on what you want to use it for. Game programming with UE4 is much nicer with modern c++ syntax, or anything where you want to push the boundaries; but I use kotlin for most things because the syntax is much more concise and the performance isn't an issue.
How much C++ coding does a modern game still require? I would've thought most of the (coding) effort would be in a scripting language inside the game engine's editors.
all my friends who do gamedev for their day job are 100% C++ except that one who generally works on the menus, settings, etc. (in semi-large / large french video game companies)
I would say, yes. C++11 is, in some ways, a totally new and more powerful language. I was sold on it as soon as I started learning. C++14 and C++17 add some useful features. I know basically nothing about C++20.
As a non-C++ professional programmer question, what's the occurrence of the codebases you work on, where the standard is significantly/fundamentally C++ 14/17?
If you combine larger libraries from pre-eleven with post-eleven libraries you will see the different worlds (Qt as a prime example), small libraries can easily be enhanced with smart pointers etc. so do you don't have much of a clash. After eleven most features are nice things, which make things a bit nicer here or there, but don't change the code as much as reliance on moves and smart pointers do with eleven. Also upgrade from C++11 to C++17 is as painless as a compiler update can be. (Meaning: in some corner case you will probably hit some compiler optimization caused issue, but for most code it's a non-issue)
C++17 was backwards compatible with the venerable C++11 in almost all ways except for the removal of some library constructs few people actually use and have long been replaced by superior models, like `std::auto_ptr` and the old binder functors.
We use C++17 to make our professional 3D printers go. We look forward to C++20 features when they become available. We shed a few hundred lines of code when we upgraded to 17 because we could drop hand-rolled stuff. It works. Nothing is meaningfully faster. And if you try hard it’s faster still.
> Is learning modern C++ worth the effort in 2021?
(Hopping onto this topic,) I wonder, what are the right resources for properly diving into the modern C++? Are there books that are up to date? Tutorials? What has worked for HNs the best?
I really liked Josuttis's book on C++17 (https://www.cppstd17.com/). The only C++20 book I know of is the Grimm book linked in the referenced blog post (https://leanpub.com/c20). I'm glad I read it, but honestly it's a bit rough still. To be fair, though, it's still only a draft so will probably improve. And I'm assuming you already have C++11. There are a lot of resources for that one. I happened to use Stroustroup 4th edition, but I'm willing to believe there are better books, particularly for people already familiar with C++03.
I'm a big Rust supporter/advocate (and I do use it for personal, non-trivial, programs), but I still suggest it only for a minority of the cases, as real-world is complicated.
In strict technological terms, there's for example the gamedev domain, which is C++ dominated, so a legitimate and non-obvious doubt, is if following up with such language is an appropriate choice or not.
Then there's the business side. It's a bit obscure how much Rust is used in BigCos; it's clearly catching on, but the extent is not obvious. Therefore, if one aims at, say (random pick) a Google job, up to date C++ knowledge may be more advantageous.
For the case when one is learning a new language (which is not the parent's case) _and_ they're not constrained by legacy/context, though, I agree that one should not even mention memory unsafe languages :)
I would say the experience is about what you would expect. There are some things that are great, that are cleaned up and more consistent. There are more conveniences. But then you run into weird edge cases / quirks, or a cascade of subtle compile errors, and just use a macro instead.
I'm writing a garbage collector and there are a bunch of things where it helps over C, but also a bunch of areas where it falls short. In summary, C++ is still great and frustrating at the same time. If anything that property seems to have increased over time: It's even more great and even more frustrating than it ever was :) Coroutines look like another example of that.