Things about C++ that make C programmers nervous
There's a lot of magic happening under the hood; constructors, destructors, virtual methods, templates, etc., can make C++ code a lot easier and faster to write than the equivalent C code, but harder to understand and reason through (depending on how well you know C++ and its associated conventions). Something as simple as Foo newFoo; may invoke a lot of code, depending on how the constructor for class Foo (and any classes it depends on) has been defined. This is also why the convention is to write ++it instead of it++ when iterating through a container, since postfix ++ often involves an expensive copy operation.
Depending on what you're doing, there can be some non-trivial overhead, especially for simple tasks. Take the following two programs, the first in C, the second in C++:
/* C version */
#include <stdio.h>
int main(void)
{
char greeting[] = "Hello, world";
printf("%s\n", greeting);
return 0;
}
/* end C version */
/* C++ version */
#include <iostream>
#include <string>
int main(void)
{
std::string greeting("Hello, world");
std::cout << greeting << std::endl;
return 0;
}
/* end C++ version */
Identical behavior, not a whole lot of difference in terms of source, but on the SLES 10 box I work on with gcc 4.1.2, the former generates an executable of ~9kb in size, whereas the second takes over 12.5kb (no optimization), almost 28% larger. The C++ string type is a lot easier to work with IMO than the C string library, and C++ streams are a lot more flexible and customizable than C streams, but for really brain-dead code like this, they may not be worth the overhead.
C++ is a huge language compared to C, with some extremely complex semantics. It takes a lot longer to get proficient with C++ than C, meaning a lot of people who claim to know C++ don't know it as well as they think they do.
Things about C that make C++ programmers nervous
C is not a secure programming language by any stretch of the imagination; no bounds checking on arrays leads to lots of exploitable behavior (be it through the now-dead gets function, or through scanf with the %s and %[ conversion specifiers). C++ at least gives you containers that throw exceptions if you try to access outside their currently defined range; all C gives you is (if you're lucky) a segmentation violation.
Memory management in C is very labor-intensive and error prone, compared to the tools C++ provides you. If you're building your own container, you're responsible for matching up all the malloc and free calls, making sure allocations are successful, backing out any partial allocations in the event of an error, etc. In C++, you just add items to or remove items from the container. If there's a problem, an exception will be thrown.
Similarly, error handling in C is a pain in the ass compared to the tools C++ provides (namely, exceptions). What's really fun is when you've allocated a bunch of memory and then hit a wall in your processing; as you have to back out, you have to release that memory in the right order. With C++ and RAII principles, this is (relatively) easy to do.
So when do I use one over the other?
If what you're writing is a bog simple, read it / muck with it / get rid of it application, whose behavior can be described cleanly in terms of inputs and outputs, and performance matters, then prefer C over C++. Otherwise, prefer C++
virtualand a few other features which prevent optimizations, but e.g. non-virtualclasses aren't inherently inefficient, and templates are a powerful abstraction tool that can actually lead to more efficient - e.g.qsortvsstd::sort). (2) High importance of correctness is a reason to use C++ (typesafety,constness,private, RAII to make resource management manageable, etc.) over C. Or for that matter, use Ada or something in the first place.void*to another pointer type in C code, it's very distracting and typical of people who don't know C.