Maybe, in this context it makes lots of sense, if you know C well there are things which "just work how you expect" in C++ and so they need at most a brief refresher.
I agree with Kate Gregory that this is a bad way to teach C++ from scratch. That is, if you know only say, Python or Java (or nothing) and want to learn C++, you should not begin by learning C. Kate's approach skips many of the things you can do in C++ but you shouldn't, whereas if we try to start with C you're going to see that a lot, because "they were legal in C" is why they're allowed in C++ even though they're a bad idea and then you have to unlearn things. You're maybe expecting some of that if you've years of C programming experience, but there's no need to introduce an idea on Monday only to tell students on Tuesday that it's a bad idea and they must never do that.
The most insidious cases are where something is legal and correct in C but it's wrong in C++ yet it will compile and you maybe have broken software. There are some nasty type punning examples, where the pun was an idiomatic C expression which does exactly what you wanted, but in C++ that's Undefined Behaviour and all bets are off. You'd just never teach those type puns in a pure C++ course, they're never the Right Thing™.
There is a considerable divergence of opinion on that subject. In my view, C++ isn't remotely suitable as a programming language for someone without a healthy understanding of C. Perhaps a dialect of C++ could be developed that was more of a cousin to Rust, but C++ as we know it is a C like programming language with a very large number of features added and all the ways to fail just like a C program does. There are real world advantages of course, but it is not a language for the faint of heart, not even close.
> C++ isn't remotely suitable as a programming language for someone without a healthy understanding of C.
I always look askance at folks who say they know C++ but not C. The C++ abstract machine is built over the C abstract machine and it becomes even more clearer when you go down to the binary level.
Depends what you mean by "understand C". As you say, understanding the C abstract machine and memory model is critical for a C++ programmer.
Understanding C idioms, the standard library, best practices, and general C software architecture , is less important if not downright negative early in your formation. You will end up picking a lot up anyway if you stick to C++ long enough.
You have to have a decent C base (not necessarily expert level with knowledge of dark corners/tricky idioms/etc.) before you start with C++. One example is being comfortable with raw pointers. I often see "Modern C++" proponents say you should never use (and by inference learn) raw pointers which is absolutely counter-productive. It is also easier to learn C++ as a "better C" in the beginning else it becomes overwhelming. I believe this is the main reason most beginning C++ programmers find the language "scary/difficult/huge/overwhelming/confusing". They are trying to learn everything at the same time which is an impossibility with a language as baroque as C++.
The main use of raw pointers in practical standard C++ is that they still don't have an analogue of Option<&T> so raw pointers (which can be null) let you write analogous code albeit in a less friendly way.
But this isn't so much like C, where raw pointers often express ownership.
You aren't going to really learn "everything" in C++ anyway, regardless of how you approach it, the language is a vast sprawling mess, the fact somebody wrote a serious book just about initialization [https://leanpub.com/cppinitbook] in C++ gestures at the problem. Freeing themselves of the need to have a language which is well-defined, or which can be demonstrated to be sound, or really follow any principles whatsoever was doubtless briefly convenient but the result is unmaintainable nonsense.
The use of raw pointers in C++ which you deem analogous to a Rust feature is your view and not that of the vast majority of C++ programmers. Raw pointers in C++ are the same as in C and the usage techniques are up to the programmer.
As a diehard proponent of Rust your views on C++ are well known and there is nothing new here. But the fact of the matter is that the industry runs on C/C++ and the main reason is due to its baroque set of features whatever one may think of them.
By "negative" idioms I'm mostly referring to stdio, string.h (except for memcpy/memmove of course), goto-based cleanup, void* based generics, overuse of macros and a certain fondness for global mutable state in a lot of classic C codebases.
Disagree here. Given the language's limitations, everyone of the idioms you list has its place and uses. They are just a way of structuring code for different abstractions.
That's not what i was saying (it's a given). After all C++ was invented to provide programmers with a large number of features that would allow them to express abstractions naturally and directly rather than building them up with all the basic plumbing that you would need to do in C.
However there is a huge amount of C code and programmers who would like to move to C++ and it is for them that the techniques of C coexisting with C++ are very relevant. There can be no wholesale rewrite of the code into C++ but a gradual rewrite module by module and as needed. Using C++ as a "better C" is the path here.
Kate has a PluralSight course which I have watched (not really to learn C++ but to see her approach) and that seemed decent to me, although of course I can't vouch for it having taught what you'd need coming from Java and JS, not least because my background is far more polyglot including Scheme and the Standard ML for example.
I definitely think Bjarne Stroustrup's book about his own language isn't very good, even in later editions (which correspond to a more modern language) and so I would avoid buying that, I'm not sure it's a good defence of the language as an idea and I'm sure it isn't an effective tutorial, even if not for being out-of-date.
I agree with Kate Gregory that this is a bad way to teach C++ from scratch. That is, if you know only say, Python or Java (or nothing) and want to learn C++, you should not begin by learning C. Kate's approach skips many of the things you can do in C++ but you shouldn't, whereas if we try to start with C you're going to see that a lot, because "they were legal in C" is why they're allowed in C++ even though they're a bad idea and then you have to unlearn things. You're maybe expecting some of that if you've years of C programming experience, but there's no need to introduce an idea on Monday only to tell students on Tuesday that it's a bad idea and they must never do that.
The most insidious cases are where something is legal and correct in C but it's wrong in C++ yet it will compile and you maybe have broken software. There are some nasty type punning examples, where the pun was an idiomatic C expression which does exactly what you wanted, but in C++ that's Undefined Behaviour and all bets are off. You'd just never teach those type puns in a pure C++ course, they're never the Right Thing™.