This part isn't quite true. All that's needed is to be able to define an exported function with a specific name and calling convention. Libraries can be written in any language that supports these features.

Even C++ is a pain in the behind, because everything that doesn't translate needs to be encapsulated.

As a result, it's very rare to find code written in different languages with exported C APIs from my experience.

Add name mangling, ABI issues and crazy compile times to that.

It was potentially safer until they added Exceptions, which tipped the scales so far the other way I can't believe we're still having this discussion.

But you won't when writing C++ unless you absolutely have to, because it's a major pita to encapsulate everything.

Entire books [0] have been written about exception safety in C++. Getting it right in combination with RAII, (copy)-constructors and assignment operators is very tricky. Which touches the main issue with C++ from my experience, mixing foot guns with higher level convenience.

Embedded linked lists [1] is a good example.

Seriously, live and let live. I'm fine with you enjoying and preferring C++, go for it. But consider taking a good look in the mirror and asking yourself why you feel the need to spread FUD about C to feel good about your choice.

[0] http://www.gotw.ca/publications/xc++.htm [1] https://github.com/codr7/libceque/blob/master/source/libcequ...

The key is to make sure all your cleanup code is in destructors where it will be exercised frequently as part of the normal operation of your program. In the event an exception is thrown, a bunch of destructors run, as usual, and your program ends up in a known clean state, with no extra effort.