I have written a C++ library to do some numerical analysis. Is there a programmatic advantage to include a C API interface to the library in addition to the C++ API?
Is this isn't an appropriate question for stackoverflow I can delete it.
What has C over C++: a stable well-defined ABI.
There are multiple C++ ABIs (MSVC's and Itanium being the foremost) and each Standard Library implementation (Dirkumware, libstd++ or libc++ for examples) is incompatible with the others. Therefore, the only way for C++ code to correctly link with C++ code is to be compiled with the same compiler (or with compilers sharing the same ABI) and above the same Standard Library implementation.
C, however, is different. C compiled by gcc integrates smoothly with C compiled clang... but it goes well beyond. It integrates smoothly with C++, Python, Haskell, Java, Rust, Lua, Perl, ... most if not all "serious" languages can interact with C more or less smoothly.
So, what is the benefit of a C API over a C++ ? Smooth integration with virtually any programming language under the sun.
Yes, there is one: you need a C API if you would like to call your functions from C code. Unlike the C API, which can called also by your C++ code (extern "C" { ... }), this is not true for C++ API, which can't be call by your C code.
No there is no programmatic advantage to include a C API.
Guess it is down to marketing and what your customers want.
Related
What language, C or C++, is best suited for writing a native library once and using it in different languages with language bindings (for example, using JNI or Ruby's C extensions), and why?
C, because
a program written in C++ can use a C library, the other way around is a whole lot trickier - any construct available in C++ but not in C cannot be exported to a C program, which risks to make your export complicated.
A C library will have less dependencies. C++ libraries will quite often depend on libstdc++, which is that big that for example on embedded systems or more generally on systems low on resources it won't always be available.
You can write your library in C++ if you like as long as you provide extern "C" bindings/exports to it so the other runtimes can use it.
I'm in the process of writing a C interface to a C++ library, and I'm looking for some high-quality examples (or best practices).
So far this one seems pretty promising: http://czmq.zeromq.org/manual:czmq
Any other suggestions?
You could look into the Parma Polyhedra Library as an example of excellent C interface to a well written C++ library. PPL is a free GPL-ed software, notably used inside the GCC compiler.
Another high quality example is the Open Dynamics Engine. It has a C++ backend and a C frontend. Everything is C linkable.
C++ example
C example
If your C++ library is written as COM on Windows. There are tools to automatically generate the C interface for it.
I can suggest FTGL which is a C++ library providing a C interface. Here are two sample programs that achieve exactly the same thing:
C++ version
C version
Note also that FTGL uses the pImpl paradigm in order to achieve binary compatibility across versions. See here why it's good.
Disclaimer: I'm an FTGL contributor.
libGLU (OpenGL Utility Library) is partially written in C++: http://cgit.freedesktop.org/mesa/mesa/tree/src/glu
libzmq is a kind of weird case since the low-level C API was originally meant to look like POSIX sockets, and absolutely not object-oriented (we made it more consistent and organized over time). Meanwhile the actual library is in C++.
The C++-to-C interface is in libzmq/src/zmq.cpp, and consists of a bunch of simple C functions that call the 'real' C++ code.
CZMQ on the other hand aims for something more classy, providing a simple class model with constructors, destructors, containers, private properties, etc. Nothing radical but does turn C into a much more elegant language.
I'm not sure how well the CZMQ class approach would map to a C++ API unless that API was explicitly designed to be mapped.
Disclaimer: I'm the author of most of CZMQ.
I have cross compiled an open-source library (C++ based) using my G++ cross compiler. I am now trying to use the outputted .a files in my C based application that is built using my GCC compiler... Is that possible?
Yes. Ensure that all functions you want to use are extern "C" and that you only use basic types on the functions you want to use.
If you use the same version GCC as you use G++ it should definitely not be any problem. Cross-version should be ok, but may have very minor incompatibilities. New GCC (3.0+) conform to the Itanium ABI so they'll be fine; they have a binary agreement on how to exchange & format data.
You will need to ensure that the C++ functions called from the C code are declared extern "C" and that their interfaces use only types that can be handled by C (simple types, opaque pointers, etc).
You will probably also need to link the application with the C++ compiler, rather than the C compiler, to ensure that the correct initializations are done for the C++ library. The C++ compiler used for the linking must be 'the same' as the one used to generate the library. That means either the same version of the C++ compiler or a compatible version of it. It usually means that you cannot link with CompilerA (from Vendor A) if the library was produced by CompilerB (from Vendor B); the C++ runtime conventions are such that different compilers (deliberately) use different schemes for supporting different features of C++.
You can link a C application to a c++ library,
BUT you can only include header files containing valid C -- not C++ -- code,
AND any c++ functions you call must have been declared with the extern "C" declaration.
The answer to your question is "yes" but as others have pointed out, there are some considerations, hazards & limitations to what you can do & how you do it.
Just recently in the course of covering this same topic with a client, I came across an article with a pretty good treatment of the topic. The article discusses things like calling C code from C++ code, calling C++ code from C code, linker considerations, function wrappers, exceptions, linkage specifications, and accessing C++ classes from C, etc.
Article: Mixing C and C++ Code in the Same Program
If the C++ library has C++ interfaces you cannot use them directly, you will have to create wrappers that are compiled as C++ but which have extern "C" linkage. The complexity of such wrappers will depend on the natuire of the interfaces, use of C++-only features such as classes, and function/operator overloading will require work to map an OO interface to a procedural one.
The easiest, least-hassle method to do this, assuming your C code is reasonably sane, is to simply build your C application with g++.
Remember, good C code almost always builds in a C++ compiler. Then there are no special considerations, no extern "C" statements to add, no ABI issues, etc, and you can easily use the C++ library to its fullest, regardless of how its functions are declared.
Are there any high level language that don't support using C++ libraries?
Using C++ libraries from other high-level languages has a couple of major obstacles:
if the library is OO, you need to be able to create a C++ object in the calling language - this is not easy.
C++ implementations use a technique known as "name-mangling" to ensure type-safe linkage. Unfortunately, there is no standard for name mangling, so C++ code cannot even easily be called between different C++ implementations.
So the answer to your question is that most HLLs will have problems calling C++ code. They may also have problems calling any other language of course - there are actually no standardised binary interfaces between languages, except ad hoc, platform-specifc ones.
I can't think of any language that is able to use C++ libraries directly. Even getting C++ to do it can be tricky (if the library was compiled with a different compiler than you're using)
Of course, if you write a wrapper of some kind (either a wrapper for the specific library, or some kind of bindings library that lets you expose specific types), then any language can use C++ libraries. But directly, as-is, with no extra work? I don't think any language other than C++ can do it.
This is a bit of an anti-answer, but many popular high-level languages can have bindings to C++ library code created for them via swig (http://swig.org/).
Apart from C++, which non-toy languages have direct or easy-to-use compatibility to C? As in "I can take a C library out there, and compile my code against it without having to find, write, or configure some kind of wrapper."
I know that lots of languages have compatibility with C through some form of external call or binding (I've been using bindings in Java, Ruby, Python, etc., so I know it can be done). But you rely on someone (possibly you), to write and maintains a binding for all the libraries you want to use, and the binding has to works on all platforms, etc.
Do more expressive languages than C++ have this feature?
Thanks to all for the mentions of swig or related wrapper-generation tools.
I am aware that those exists, but I don't think they're really as easy as C->C++ integration... but then integrating with C might be the only thing that is easier in C++ ;) )
Objective-C, the bastard child of C and Smalltalk.
Objective-C is a direct superset of C (you can't get more compatible than that), but there are languages which compile to C. Some recent examples would be Vala and Lisaac.
Most statically compiled languages allow interfacing with C libraries. Examples of such languages are Ada, Fortran, Pascal and D. The details are platform and compiler specific; for x86, this basically means supporting the cdecl calling convention.
The D language is compatible with the C ABI. However, it's sometimes non-trivial to convert C header files into compatible D modules. See this page for more details.
Fortran can call C routines, or be called by C. This used to be "platform and compiler specific" as stated in another answer, but Fortran 2003 includes the "ISO C Binding", which makes this part of the language standard and therefore portable rather than platform and compiler specific. The ISO C Binding is supported by numerous Fortran compilers, including gfortran (>= 4.3), Intel ifort, Sun Fortran, etc.
You do have to write an "interface" description of a C routine being called, but it is compiler and platform independent.
For a lot of languages, wrapper code for C libraries are not hard to write - just use SWIG: http://www.swig.org/
While originally written as a quick wrapper generator for Tcl, it now supports:
Tcl, Python, Perl, Guile, Java, Ruby, Scheme, PHP, Ocaml, Pike, C#, Modula-3, Lua, Common Lisp, R and Octave.
If you use any of the language it supports, give it a try. For C functions that deals with strings, integers and floats it is very easy to use. For more complex C functions it obviously gets more complex.
With the right compilers/linkers, name mangling and function arguments, you can link C and Fortran modules. Details here.
Python has a dynamic wrapping module, ctypes, which, while it doesn't eliminate boilerplate binding code completely, does greatly reduce it.
G'day,
You can interface Perl onto C libraries by writing an XS interface between the two. Here's the perlXSTut over at CPAN.
This is how the XML::LibXML and XML::LibXSLT modules are implemented.
You can also interface Ada to C libraries buy means of pragma Import. This is also true for libraries written in C++. And COBOL and FORTRAN BTW.
HTH
cheers,