I often hear people say that C++ programmers should expose their library's/product's public API as a C API.

What does that mean and what are the advantages of that?


It does mean that the part of your library that is exposed as an interface only uses the C "part" of the language, so you're not exporting classes or similar, only functions, PODs and structs containing PODs. Plus, you have to disable the C++ name mangling, usually achieved by marking functions as extern "C". A typical example would be:

extern "C" void foo(int bar);

The big advantage of exposing your libraries in this fashion is that pretty much every programming language out there has a mechanism to directly interface with a C library, but only very few can also interface directly with a C++ library. So in that sense, you go for the lowest common denominator to make it easy for other people to use your library.

However keep in mind that this is really only a useful strategy if you are producing a library for other people to consume. If you are building a piece of C++-only software and the libraries only need to interface with each other, you are (IMHO) better off exposing proper C++ APIs so you can make use of the full power of the language.

  • 14
    You must be careful to not export thrown exceptions either! – James Jan 4 '13 at 20:08
  • That's a great answer. Can you give me an example of the extern "C" stuff, that I didn't get? – Daniel Ribeiro Jan 4 '13 at 20:37
  • 1
    @DanielRibeiro: just google for "extern C". You will find links like this one: stackoverflow.com/questions/1041866/… – Doc Brown Jan 4 '13 at 21:26
  • 1
    @DanielRibeiro, very simple example added. – Timo Geusch Jan 4 '13 at 21:39
  • 1
    @DanielRibeiro It's technically possible to still use .hpp, but this extension means "C++ header file", so it should be .h, which is used for both C and C++. – leemes Jan 5 '13 at 3:33

In addition to Timo's answer - there is no standarised C++ ABI for some platforms (for example Windows - some like Linux of Mac OS X widely adopted) so it is not only matter of missing feature but impossibility of implementing such feature.

For example IIRC MSVC have different ABI in each version and it might change depending whether it is debug or release build - and it is not published so 3rd party compilers are usually not compatible (I read some information that some version of icc is compatible with MSVC 2005 but it might be information disclosed under NDA - not necessary available to creators of say Python) and use their own ABI. So in practice language environment would limit not only the compiler version but also flags.

Finally C++ have much more compile-time features. For example generics usually don't exists in the dynamically typed languages etc.

  • 2
    @DanielRibeiro: Welcome to wonderful hell of C++ ABI ( en.wikipedia.org/wiki/Application_binary_interface ). Short version is that it is very hard to make C++ components compiled separately (compiled with different compilers/flags) to work together instead of silently failing/crashing. – Maciej Piechotka Jan 5 '13 at 10:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.