Sure, if you know C++ well, you'll be able to do C, but learning C++ is that much harder than C, that it's often not worth the effort. You'll be able to interface with most libraries once you know C, even if you use any other language as your primary tool. Learning C++ won't give you that much extra.

You seem to be locked down by a particular perspective on software development, and this is unfortunate.

That's utterly untrue. The low-level details of C++ are mostly the same as C's, unless you want to write a shared library in C++ and thus need to extern the C++ symbols, or need to worry about the details of the object-system implementation like vtables, or need to mess with streams and layer them over some communication medium.

What makes C++ fucking hard is the syntax explosion that feels like cleaning up a New Year's Eve confetti with your bare sweaty hands, the template voodoo, and the design patterns that they have tacked on the language to make it more palatable to Satan.

To make it worse, the language is both broad and deep. You can't learn C++ by reading the standard. You have to dip into the culture of one of the big vendors, or schools of programming, to find out what subset of the language is to your liking. Are you writing Bjarne's C++ or GoF's or Alexandrescu's? or perhaps you would prefer to old HP/STL/Meyer C++ to the new kitchen-sink BOOST C++?

Contrast this to Common Lisp, which is a very broad but relatively shallow language; you can read the first few sections of every chapter of the manual and come off a good Lisper, go back and dig deeper and you only get better. OO, functional and procedural Lisp looks relatively the same. If you don't understand a construct, you look up the documentation of the symbol, see its evaluation model and presto. C++? You don't see what's being implemented because higher-level designs are being kludged and modeled with dickish, brittle and contrived tools -- they have no way out of this, as the language insists on C pseudo-similarity and refuses to adopt any kind of clean macro system; they're running out of syntax and CPP is unforgiving. Understanding C++ code then becomes a matter of psychological profiling of the author and even scholarly exegesis and deconstruction ("What did he intend to say?", etc.) requiring a level of empathy hard to muster when you're, in fact, wishing ill and misfortune on the bastard who forced you to look at this mess.

I agree that C++ is very library oriented, and it changes your approach to the language, but this is not a fault of the language itself, this is a side-effect of its very wide popularity.

If you have a pattern used by a library, then that is the fault of the library, but not a fault of the language. The language does not come with any patterns.

Templates in C++ are not good, but they are not widely used in the real world. Most people ignore them, and that's good so.

Depends on where your "real world" is. C++ usages are vendor and library dependent. My C++ code looked different in MFC/COM/ATL than in FLTK and that too was different than Qt. Choosing the right C++ becomes a matter of choosing the right vendor, and if that choice isn't up to you, well, tough luck.

You can use Objective-C as a datapoint here. That's Smalltalk on top of C. You can use the same sort of trick (delimiting the dynamic sends) to recycle the C keywords in the dynamic context, and end up with a language with just a few more keywords than C.

The reason is simple: They are difficult to understand. Code is communication, and there are two listeners - and when you are pushing function pointers around using macros, the human is going to have huge problems understanding what you are trying to achieve.

So I don't think exploiting particular features of a language to extreme levels when it is unneccesary makes you a good programmer in that language - I actually think it makes you worse.

It's like writing a book - you have a certain vocabulary at your disposal, and you can say almost anything you want with that vocabulary. There are different levels of obscurity in the words you use you can reach - you gain in expressiveness, but you narrow your audience. When you write a book for molecular biologists, then the particular terms you use should not be the same as when you write a biology textbook.

That's why I think that one can be a good C programmer without going much deeper than the C subset commonly used in C++.

This is part of my general philosophy in programming - clarity, simplicity and structure first, efficiency second. The machines will catch sooner or later, anyways.

C++ has templates, so you don't need to do as much with macros. C++ has virtual functions and overloaded operators (allowing for functors), so you don't need to do as much with function pointers. Structures can have methods in C++, so the way that you'd set up an opaque type is quite different in C++.

C++ also has about 10000 other features as well though, which is what makes it unwieldy to learn. The patterns mentioned above aren't about efficiency; they're about encapsulation.

Just to give an example -- in C++ if you want to set up a callback, for example with an observer pattern, you'd use a pure virtual function (and then pass in a concrete instance of that class) or a functor. You can't do that in C, so you use a function pointer. You learn to work with function pointers more because they're a necessary part of designing C APIs, whereas they're not in C++.

(Note that it's the language I'm best at, followed by C, so this isn't random C++ hating.)

I'm not saying there are no good reasons to learn C++. Just don't think that you'll really appreciate C until you've actually used it all by itself (with maybe a few C++isms here and there like //comments).