C is one of the oldest languages still around. Its ABI is simple, and virtually every operating system still in use today has been written in it. While some of those OS's may have added stuff e.g. in C#/.NET or whatever on-top, down below they're very much steeped in C.
That means that, in order to use the functionality provided by the OS, virtually every programming language out there needed a way to interface with C libraries anyway. Perl, Java, C++, they all natively provide ways to "talk C", because they had to if they didn't want to reinvent every single wheel there is.
This makes C the Latin of programming languages. (How many years of internet before that metaphor has to be "the English of progamming languages"?)
When you are writing your library in C, you get a C-compatible interface for free (obviously). If you are writing your library in C++, you can get C bindings, via
extern "C" declarations as you mentioned.
However, you can get those bindings only for functionality that can be expressed in C.
So your library API cannot make use of...
- any functions taking or returning objects.
One simple example, you would need to make your exported functions take and return arrays (
) instead of
std::string for that matter).
So, not only would you be unable to provide any of the good things C++ has to offer to your library's clients, you also would have to go to additional effort to "translate" your library API from C++ to "C compatible" (
That is why the point could be made that C is the better choice for implementing a library. Personally, I think the benefits of C++ still outweigh the necessary effort for a
extern "C" API, but that's just me.