The fact that C++ is almost a superset of C is commonly used as an argument for C++, and the accepted answer in the post is a common response - C++ is not quite a superset of C, you have to cast malloc, you lose out on C99 features, etc. But I think it misses the point: if you could really get the advantages of C++ by using its features in a few necessary places in your C code, I think it would be worth it to make your code slightly uglier to accommodate it.

You can't.

Generic containers are probably the C++ feature C is most sorely lacking. But as soon as you start using map<> in your code, you have to deal with slower compilation in all the files that use it (if a map is declared in a header file, e.g. as a struct member, that could be quite a lot), repetitive code generation the linker might or might not optimize, verbose syntax (std::map<struct foo *>::iterator, yay), and the requirement (more or less) to use new instead of malloc for any struct that contains a C++ object. And if you want your map's performance to not suck, you'll need to depend on either a nonstandard extension or C++11 to get hash_map/unordered_map.

Then there's writing templates - even in the context of C++, template code tends to be hideously ugly (template<typename T> everywhere, the aforementioned issues with code generation and sticking everything in header files, pages of confusing error messages when you mess up), and is hard to debug with a debugger. Trying to use them with C can only lead to pain - especially since they work best when you have actual objects to specialize on. Templates do allow certain C code to be written more nicely, such as binary formats where there are multiple versions of the same struct, but even then there are limitations to the magic - template-ness tends to spread to callers.

gcc apparently wanted to switch to C++ partly in order to use destructors: now you have spooky action at a distance, where the caller of your method is a closing brace, thanks to a declaration a page away somewhere up in the function.

Do you want to use a few classes to add some structure to your code? It will certainly start to seem a bit forced to declare struct foo and functions like foo_alloc and foo_get_bar once you're in C++, when declaring a class expresses the concept more elegantly. And then you're stuck with C++'s context sensitive nature (anyone who understands the code will know that it->getName() is a reference to Foo::getName, and fooCount used here is a member variable, so it's fine, right?) and poor separation of interface and implementation (it really doesn't make sense that you have to declare private fields in your header file, and it doesn't make compilation any better), and if you're not careful your code will start to feature a vector of objects where an array of ints is appropriate, or yet another method whose only purpose is to pass on slightly different arguments to a method of a member variable.

C++ programmers accept these issues in exchange for a high-level coding style (less security bugs!) and an easier time writing clean code than C programmers (although bad C++ code is a whole lot worse than bad C code). You will gain hardly any of that by sprinkling C++ into C. Solving these problems in C sometimes leads to more work and more verbose code, but the result is also often a better solution. If you absolutely must have code generation, use a macro, they're not as bad as C++ programmers make them out to be - or, at least, they're ugly enough that most programmers know to use them very sparingly. (I'm rather a fan of <sys/queue.h>, for example, although you do have to understand how it works to make sense of code that uses it.)