As someone who learned C++ when it was C++03 and followed the language as it went through 0x all the way to 20, I have no idea how you would be able to avoid crippling a newcomer with the sheer volume of permutations of symbols and language behaviors that a C++ developer might regularly encounter. As a consequence of the ecosystem of older libraries, I've never had the pleasure of fully stepping away from old C++-isms. There's always a naked pointer or a malloc floating around somewhere in code I have to be able to read.

I still occasionally write C++ when I need to, but it's been a long time since I actually enjoyed doing it.

The closest you'll get to that is probably Scott Meyer's effective modern c++ which is for c++14. Scott has retired around in 2015 so don't expect an updated book.

Actually there is a recently released book[1] by No Starch that gives a tour of modern C++ with details about implementations and librairies and even has a great chapter on unit testing.

[1]:https://www.amazon.com/C-Crash-Course-Josh-Lospinoso/dp/1593...

+1 Lospinoso is the real deal

One problem for trying to just learn "modern C++" (so, C++ 20 and explicitly preferring the modern "right" way to do things, Kate Gregory talks about teaching C++ this way) is that C++ got this influential partly by having a lot of libraries. But for a library author, choosing C++20 over C++11 (or worse) means fewer users.

So, sure, all the code from people learning "modern C++" is smart pointers and ranges, but to get work done you have to call this library that takes raw pointers and you're immediately out of your depth.

raw pointers.. or homegrown strings, vectors and hash tables.

C++ soldiers on because it can support such things and adapt to decades of changing hardware and philosophy. But the pain of using and composing libraries in C++ is not just about not having cargo or npm - it's the lack of consensus on data types for anything beyond C primitives.

This sounds like you're describing C++ from 20 years ago. Or maybe some ugly monstrosity like Qt.

Everything uses/supports standard library containers or interfaces now.

There's nothing ugly about Qt. In particular, the core system defines a way to add features to classes that were missing (MOC) and provides a full foundation of types up to network and other event-driven multi-threaded servers. Frankly I think it's one of the best examples of C++ I've seen.

Some counterexamples that I've dealt in the recent years include LLVM, Abseil and Windows COM APIs.

Smart pointers are a weird example because they're ancient. I'd say the majority of C++ libraries expect C++11, many C++14.

Also it's still completely normal to use raw pointers or references when a function doesn't care about ownership.

> Smart pointers are a weird example because they're ancient.

I am an old man, and to me 2011 doesn't feel ancient, but fair. C++ 11 has unique_ptr and shared_ptr (if your library uses a previous generation of smart pointers you're in worse trouble than if it had raw pointers) and that's what you'd probably teach in class today.

> Also it's still completely normal to use raw pointers or references when a function doesn't care about ownership.

This is true. So you can't tell. And, with a different hat on it's also something that Kate Gregory has given talks about. As the new maintainer for several MLOC of C++ what can I conclude about this function that takes a raw pointer to a foo ?

Maybe, it just wants to look at a foo, immediately and then has no further interest in it.

Maybe, it will mutate the foo, immediately, and then loses interest.

Maybe, it will hang on to this pointer and use it later, who knows when. Thus, now it "owns" the foo, I hope it will clean up after it ceases using it because I can't now.

Maybe, I'm supposed to provide an "empty" foo and the contents of it afterwards are the primary result of the function.

Those are pretty different, so it's disappointing that we don't learn which it is from the function signature.

Huh. There simply aren't that many C++ compilers in the world that matter... who is working with a C++11 compiler, but doesn't have at least C++17? (The core problem with C++20 is that support is still spotty: like, I am waiting with baited breadth for clang to finally get around to P1091R3/P1381R1... they list it as "partial", but it feels like "not even started".)

I'm on the same line. I'd love to see a book focused on practical C++/11/17 with non trivial projects. Effective Modern C++ explains a lot of things, but concrete examples are a lot better.

Some projects in mind:

C++/SFML/SDL2 game programming using modern C++

Interpreter/compiler construction in modern C++

Explains how to implement things in modern C++ (e.g.unique_ptr) without modern C++ (maybe just use C)

Yes, just talking about the language isn't enough.

Solving somewhat complex problems with standard data structures (maps, trees, hashtables, etc.) and doing it in the modern, efficient way is the kind of thing I'm really looking for.

In Python it's easy (which isn't to say everything should use Python) because you don't have to do anything but use the builtin datastructures and solve your problem.

Maybe modern C++ works the same way but if it does, I still need someone to show it since that isn't how it used to be (to my knowledge).

Yeah the thing is I don't know if there is any _good_ small-medium modern C++ code base to read.

Eventually I just gave up and use raw pointers. My theory is that since people don't care about JVM not returning memory to system, they should also not care a bout a few MBs of memory leak in my small game.

What about a book or resources for someone who already knows C++? I haven't used it in 10 years and even then, where I worked at the time, using C++11 features was "off-limits". Just from a cursory glance, a lot seems to have changed since then?

I would love to see a book on modern C++ (11 and beyond) in general, for people used to other languages. I'd like to learn it at some point but it's honestly really intimidating.