Late into this thread, and I haven't read it top to bottom, but there seems to be a slight conceptual gap developing regarding what C & C++ really are.
They are languages, not environments. The C language was originally designed for telephone exchange testing & control. Subsequently, it was used to implement the early UNIX kernels. There is a "C Standard Library", which is distinct from the language proper - this is where printf etc. come from.
The story is similar with C++ - the language is distinct from its support libraries, e.g. stdlib, STL, and the various boost libraries.
A huge amount of apocrypha and mis-information surrounds these languages and the pros and cons of their various implementations - most of the arguments are bogus and ill-informed. The truth is, IMHO, far more boring - that they each have pluses and minuses.
The main differences are that C++ is geared to a more object-orientated design methodology, and generally, the mindsets used are different, which is why some feel that teaching people C, then C++ is a bad plan.
When mis-used, C++ can be memory-hungry, which is one some decry its use for embedded work - I feel that this is a fallacy - C++ is absolutely fine for embedded work (I use it all the time), if you understand the consequences of your actions - C++ is a far more powerful & capable language than C, but with great power comes great responsibility (*) - blaming the language for your poor understanding of the consequences of your actions is not an excuse. C++ is easy to abuse, C can be plain dangerous...
An analogy I like to use is the difference between "mathematicians" and "people who do mathematics".
A mathematician has an intuitive grasp of numbers and mathematics - they can visualize the problem they are working on and come up with novel ways of solving it; further, when presented with a left-field/previously unseen problem, they will see ways of dealing with and solving that.
Someone who does maths, OTOH, knows how to follow rules and can solve problems that are related to problems that they have encountered before, but may have real issues dealing with a novel puzzle..
Same with programmers. There's a world of people who can do C or C++ and have used the support libraries - that does not make them good or even half-decent programmers.
In my career, I have found very very few genuinely good programmers - people who understand architectural issues, who can see solutions, who can visualise novel approaches and solutions, who understand and then, very importantly, can implement with excellence - it's the difference between a programmer (rare beast), and journeymen who know how to program (common as anything)..
Note: I was involved in the ANSI C process and have been an editor or cited as a contributor to various C++ related books, including Scott Meyers' "Effective STL" etc Spent 30 years in the City of London and elsewhere as a CTO, designing, developing and implementing some of the world's largest real-time equity, derivative & FX exchange trading systems, mostly in C & C++.
(*) Attributed to Ben Parker, Peter Parker's uncle...