Precisely! It always is a red flag when new graduates have "proficient in C/C++ " in their resumes. I've found that these people tend to write code in a combination dialect of C and C++ that I call C+.
There was old adage that people who say they code in "C/C++" don't really know either one. This was about a decade ago, I can't recall where I saw it, and don't know if it still a widely held view.
I said I would consider it a burden to write in pure C, not that I would not be able to do it. I would not need any documentation, but I would scratch my head figuring out how to organize a large program. I would need to write a lot of comments to replace things that do not exist in the language: const-correctness, memory management conventions, type-safe containers, etc.
"How to organize a large program" is a large part of what learning to program in a language means.
BTW, const correctness is in C99, and memory management is usually done by writing constructors and destructors like C++ (except that they're real functions, often named stuff like <prefix>_init and _destroy or <prefix>_new and _free) and calling them manually. It's not as elegant as RAII, but if you write short functions with clear logic, you can usually ensure you cover all code paths. Remember that you don't have exceptions to screw up control flow in C.
For type-safe containers, I just use void* containers with a comment indicating the intended type, but perhaps more experienced C programmers have a better system. Remember that Java didn't have type-safe containers until Java5, and honestly ClassCastException was a fairly rare error.
Const correctness has existed in C since 1999. Again, knowing C++, and even being able to constrain yourself to some C-like subset of it, is not the same as knowing C.
Naive C++ programmers tend to use pointers as if they were references. They do not seem to understand pointer arithmetic, pointers to functions, etc. They also do not seem to have a deep understanding of memory models, and tend not to understand memory alignment. They do not use bit-wise operators much, though it's more of a cultural thing than skills issue.
I have never met a competent C++ programmer that does not have at least some exposure to C as well. But I'd dare to guess, that such character would not understand the C preprocessor in any but the most trivial level.
[edit]
I originally used the phrase "C with classes" crowd, in a rather derogatory way, to describe the people who never get to learn any of the languages well, and end up writing some sort of sanitized, structured-programming, algol derivative in (a subset of) C++ syntax.
While reading the rest of the comments, I remembered that "C, with classes" can also apply to C hackers that just use C++ to structure their C-styled code, and may take advantage of a few features of the language. I have edited the comment to clarify what I meant.
> I have made the experience that a good C++ developer also automatically knows everything about C.
Not even close in my experience. In college, we used C++ in our intro course. The addition of pass by reference, classes (with constructors and destructors), and the standard library (e.g. std:string) hides a lot of the common paradigms of C, and that's not even mentioning boost.
In my experience, people coming from C++ tend to write really bad C. Many of them have a poor understanding of the concept of pointers.
Once you get familiar with some good C design patterns, it's pretty easy to write clear, modular C. Knowing C++ is not a very effective measure of ability to use C.
Au contraire, a modern C++ developer probably knows nothing about C. Good C is like good assembly language: dense and performance-obsessed. No objects, no exceptions, no STL, bare bones and riddled with pointer manipulation and macros.
Well, function pointers exist in C, though they are certainly a clumsy replacement for having methods (or first-class functions / closures / currying) built into the language.
That said, answer #3 or #4 makes sense.