[butlerm]

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.

[rramadass]

> 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.

[gpderetta]

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.

[rramadass]

> is less important if not downright negative

"Less important" maybe but not "negative".

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++.

[tialaramex]

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.

[rramadass]

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.

[gpderetta]

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.

[rramadass]

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.

[gpderetta]

In C maybe, but not C++.