"You might think of the C subset of C++ as bona fide assembly language which you shouldn’t use it in day-to-day programming, except that it’s right there on the surface. If you reach blindly into your C++ toolbox, you’re likely to come up with naked pointers, for loops, and all this ugly stuff."
It's all rolled into one as far as the author is concerned.
The author definitely does not consider them all rolled into one; the author was a member of the C++ standards committee. That quote is discussing the C-backwards-compatibility baggage of C++ as a design flaw in C++. In the context of C itself, it might not be a design flaw, and the author appears less interested in that question (he's been writing about C++ since the '90s, and doesn't really write about C).
I don't know about you, but I read "which you shouldn’t use it in day-to-day programming" and "all that ugly stuff" to mean a complete and utter dismissal of C as a language even worthy of consideration. Are you somehow getting a message that the author is endorsing going back to the simple days of pure C?
You could believe C is an absolutely fantastic systems-programming language, but believe that in day to day applications programming, it is a poor choice. Actually, I think that belief is fairly common.
I don't think it would be going too far in the direction of looking for a charitable interpretation of the author's statements to consider this possibility.
I think not - C has extremely thin abstractions - it's basically a portable assembler, with all the trade-offs so implied. C++ is a beast of a language that includes everything and the kitchen sink (plus decent backward compatibility with C), and as such is hard to optimize for new contexts (like concurrency), because there are so many interlocking bits that all need to work (ever tried to write code combining templates with class inheritance? It's mind-boggling, and that's likely a simpler example than those the author cites).
Sorry but I have to call bullshit on this.
Even in addition to the passage I quoted which explicitly calls out compatibility with C as the biggest problem with C++, the bulk of the rest of that article is directed towards resource management, starting with dismissing malloc as the worst possible API for memory allocation and going on to bitterly complain about various problems with pointers, global memory, side effects, for loops and any and everything that C++ inherits from C.
The overwhelming thrust of the article is that C++ needs to stop looking like C and has to start looking like Haskell or whatever other functional cool-aid is being drunk these days. If you are interpreting this blog post to be a call to programmers to go back to C, you're not reading the same words that I am.
Call bullshit? Please. Just say you disagree or something. Bullshit implies that I'm intentionally trying to feed you false information. And you've misunderstood. The line of reasoning you quote is about how C++ introduced new and delete to circumvent the follies of malloc and free. But the upshot was that even new and delete had pitfalls that developers fell prey to, so then came tr1's shared_ptr, followed by unique_ptr, which then necessitated, make_shared, etc. Where did I say this is a call to go back to C? Where did you learn how to read?
I think the author is saying that for what C++ is used for, its backwards compatibility with C is an anti-feature, because it's too low-level. That doesn't mean C is a bad language if you want or need that low level of control, just that modern systems programming should be using a higher level of abstraction which can be more efficiently optimized.
