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.
Related
Suppose I have two projects that I would like to link together:
A C++ library compiled with Visual C++ to a DLL file.
A C++ executable compiled with C++ Builder that uses the classes in the library.
I realize that there is no standard C++ ABI and that any attempts to directly link these two C++ projects together will fail. What is a good, automated way of creating a compatibility layer that allows me to accomplish this?
For example, conceivably the C++ library could expose itself via a C interface. Then the executable would have some C++ classes that wrap the C interface exposed by the C++ library. Since there is a standard ABI for C, it would work.
The only question is how to automatically create the C interface and C++ wrapper classes - manually maintaining this would not be an option. The SWIG project looks promising, but unfortunately, C++ is not one of the exits of SWIG listed on their web site. Is there a way to do what I want with SWIG? Or is there another project other than SWIG that would help me with this task?
Or am I going about this the wrong way?
Edit: The core C++ library is intended to be cross-platform. The executable, obviously, is Windows-specific. I don't want to pollute the core library to the extent that it becomes impossible to compile it on other platforms.
If it only has to run on Windows, I would expose the classes as COM objects. They'll still be in a DLL and they can be used by any language which understands COM.
The "standard" way of doing this, in Windows, is to use COM objects. So, that is certainly a good option to look at. In Linux systems, the module interaction model (e.g., executable-DLL interaction) is very different, and ABIs exist for C++.
If you would want to do this manually (create your own COM-like library), it can be a lot of work with many little tricky issues to take seriously. You'll need a cross-module RTTI system, you'll need an interface query/definition protocol, some mechanism to manage memory across modules, etc. Beyond that, to "automate" it, you will probably need a combination of MACROs and template meta-functions.
One cross-platform option that I would highly recommend that you consider or at least look at is using Boost.Python and the Python language as the "glue" between your modules. The Boost.Python library basically does the whole "automated exporting / importing of classes", but it exports your C++ classes and functions as Python classes and functions. And, it is completely non-intrusive and cross-platform, so this is really an ideal example of automated exporting. So, you might consider using Python to write your high-level glue-code, or using Python as an intermediate between the C++ modules, or even reworking the Boost.Python library to use only the "automated exporting" mechanisms to export to whatever interface system you design or use.
I'm sure there a plenty other similar libraries out there. But the number one question is, of course, do you really need this? You might be using a bazooka to kill a fly.
Why not just compile the library with C++ builder as well?
Looking around at swig (I knew swig should be able to wrap C++ in C):
SWIG and C++
If core library is cross-platform why not also write the UI as a cross-platform Qt application and build everything in Visual C++ on Windows.
What does it offer to an object oriented language such as C++? or is it not possible to use GTK+ without it?
Is the GObject implementation of objects is of a similar quality to that of C++ in terms of the size and speed of an executable assuming both examples use the same compiler? Or are there some trade-offs where GObject would be slower on the account of additional capabilities it provides?
GObject (a bit like COM in the Windows world) is a C API designed with cross language interoperability in mind.
This means that you can use GObjects in any language which supports calling C functions, but this makes it very difficult to write GObjects in a non-C language which are truly reusable from any language (if you write a GObject derived class in say, Python, you'd have to embed a Python interpreter every time you wanted to use objects from this class in C).
It is possible to semi-automate the creation of bindings for many languages (eg. Python, Perl, JS etc), and here lies one of the strengths of GObject. This accounts for the somewhat opaque API that GObject provides, which is, I confess, quite difficult to understand thoroughly.
Unfortunately, it doesn't fit well within the C++ language either. GObjects have no trivial relationship with C++ classes, and even if bindings are available (Gtkmm) it is not possible to easily write a C++ class "inheriting from GObject" and expose it to the world. You have to write C for this.
[What the world would need would be some kind of extensions to the C++ language which would make it easy to interop with GObject, a little like C++Cx on Windows, but 1) it is a difficult task, perhaps achievable through a GCC plugin, and 2) there is no momentum towards C++ in the Gnome world, or generally in the Linux world (KDE being a notable exception). For now we are stuck with the Gtkmm bindings.]
The article on GObject from Wikipedia includes a comparison with C++. Some of the things they mention is the lack of multiple inheritance, and the presence of signals. Additionally, GObject benefits from the fact that the names of exported C functions do not, unlike C++, depend on your choice of compiler. So if you were to develop an object-oriented library using GObject, it would probably be easier to link with than a C++ one.
It would also be interesting to look at the Vala programming language, which targets GObject.
Just a little elaboration on something hinted by Vlad: A major point in favour of C is that it makes interoptability between compilers or languages 'possible' (guaranteed), in that it standardises an ABI. This (pardon me if I'm oversimplifying) enables guarantees about how callers from any C compiler or other language can use exported symbols. Hence why GTK+ has bindings to various other languages - including C++ in GTKmm. The latter is the best of both worlds IMHO: the well-established API of GTK+ but with the language features of C++.
C++ as yet does not have an official standard ABI, though all is not yet lost, as the A-Team are working on it: https://isocpp.org/files/papers/n4028.pdf
I am a student, and new to C++. I am searching for a standard C++ API that is as comprehensive as the Java API. So far I have been using cplusplus.com, and cppreference.com.
Please any help would be greatly appreciated.
C++ and Java have very different standard libraries because they make very different assumptions about what they are going to be used for.
Java assumes that applications or applets will be running on a host with a full featured OS, with a defined way of doing most normal things.
There's a lot of content in that, for instance, in java, the output will be an application or applet. C++ does not make that assumption, because C++ can be used for building OS Kernels and drivers for kernels, it can be used for programming full stack real time applications on microcontrollers, or processing blocks in supercomputers.
C++ can be used for implementing the very operating system on which it will run.
For these reasons, the standard library assumes almost nothing about what it will have available, and so the standard library doesn't make any dependencies on those features.
The only exception is with files and streaming, because almost any operating system like stack has something that looks like a file stream if it has anything like files at all.
If you want a richer set of OS Specific api's you need to look at something non-standard. A great choice is the Qt framework, which provides many tools similar to what is found in the Java libraries, is cross platform, and works well with native C++ idioms.
C++ has a standard library.
You can try reading the "The C++ Standard Library: A Tutorial and Reference". While I don't own it myself, it's on our book list (which I recommend you check out), so it shouldn't be bad.
Note C++ isn't Java, so the libraries don't necessarily have the same functionality. Another resource you'll want to look at is Boost, which serves as a source for well-written C++ libraries for things the standard library lacks.
GNU C++ Standard library documentation is the one I refer to most often.
Java is a virtual machine language and as such attempts to have a comprehensive api to provide a platform independent method of drawing/wrtinging to files / anything. IN the guts of JRE they are taking these generic inputs and using them to do platform specific things. In C++ you are the one that does that work. Many c++ libraries are platform specific see MFC, ATL or code that is written for XWindows it your job to decide how you want to implement a feature and see if that is a platform specific feature or can be done in a platform independent manner.
If you are writing on windows or unix I can assure that the OS API is very complete and will allow you to do what ever your trying to accomplish. Also take a look at cross platfom libraries like lib qt.
Java's standard library is aimed at providing ready-to-use functionality, while the C++ standard library is aimed at providing building blocks that aren't defined by the core language. The Boost library has mainly the same orientation as the standard library (with a few exceptions such as image processing). I think the closest you can get to something like Java's standard library is the Poco library.
However, when I tried on the Poco library I found that it was a bit too C-oriented for my taste.
That is, it's not "modern". You get that impression straight away without even looking at the APIs, because the online docs uses 1990's frames. :-) However, it may fill your needs.
If you mean the c++ standard library I'd look at www.cplusplus.com. It covers the current standards. After familiarizing yourself with that, you could try looking at boost.
There are a number of changes in the upcoming c++0x standard. Wikipedia has info on a number of these as does SO.
The number one book, IMO, for c++ is Effective C++ by Scott Meyers.
I want to write a library which will be dynamically linked from other programs running on modern operating systems like Windows, Linux and OS/X (i.e. it will be deployed as a .dll or .so module).
What is the most appropriate language in that case? Should I stick with plain C? Or is C++ also ok?
You can use either C or C++ for the implementation, but I would recommend to define the interface in pure C. It will be much easier to integrate.
The difficulty with creating a C++ library distributed in binary form is that your customers - the users of the library - are typically constrained to use the same C++ compiler as you created the library with. This can be problematic if you want to keep up to date and they don't, or if they want to keep up to date and you don't. If you deal in source, this is less of an issue, as long as your C++ is portable enough to allow it to be used by all the compilers your customers use.
If the code may be used from C, I'd probably code to a C interface. Alternative, provide two interfaces - the native C++ interface and a C interface. But that's more work than just a C interface. On the other hand, there may be benefits from a C++ interface (perhaps using STL iterators, etc) and that could sway your decision.
I would also say that C is the lowest common denominator. You always have the option of writing a C++ wrapper to the core library if this integrates better with the calling application.
I'd say C is the most predictably portable, but C++ is doable.
Consider the factor of lowest common denominator and making consumers of your libraries make the decisions that are best for them. The construct of extern c probably still confuses some people and you want your library to travel far and reach the widest audience. Definitely make the interfaces pure c. C++ is fine provided you avoid some of the darker corners (like STL). C is the most portable bar none. Creating libraries for all available platforms is no small feat so be sure to take a look here for some hints. You might also want to consider using autoconf and the like.
Are their any libraries which provide functionality similar to mono but for the c++ language? I know boost exists, but I like mono much more than boost.
I'm looking to do more than what's available in the base library set, like play sound more easily (crossplatform), GUI, load images, time, etc. I guess I am looking for what people might consider an engine or a large library.
Mono is a .NET implementation. Mono is NOT a library.
There is NO Mono for C++. At least, not yet.
I think you want a multi-platform framework, such as Qt
If you're wanting to work with Managed C++ a la .Net, then you would just use Mono. They have a page describing how to go about it. The only catch is that you have to compile on Windows, as there is not yet any flavor of GCC that outputs .Net CLI for C++.
To be honest, though, if you're going to use Mono, you might as well move into C#. It's a much cleaner language, IMO.
CLI is only able to host C++ compiled code on all supported platforms as long as the compiled code only contains CIL not native code.
for more detail visit
http://www.mono-project.com/CPlusPlus
I'm not sure about your precise requirements, but in terms of large multi-purpose packages: Qt has been mentioned by a few folks. wxWidgets (formerly wxWindows) is another option. GTK is multiplatform.
As you use the word "engine" (often a game-related term), you might be interested in SDL, which has been used by numerous games, professional and amateur alike. SFML is an option. ClanLib is another long-lived library I've heard of, though I'll admit to knowing little about it.
Try the STL collections...Has nothing to do with .NET, but they are a nice collection of collections (lol) and make C++ life easier.
It sounds like what you are really looking for is a C++ framework that offers the kinds of functionality found in the .NET/Mono framework. Qt is a popular choice.
On the topic of C++ interoperability, Mono has recently made some pretty big strides with CXXI.
(From this posting): The short story is that the new CXXI technology allows C#/.NET developers to:
Easily consume existing C++ classes from C# or any other .NET
language
Instantiate C++ objects from C#
Invoke C++ methods in C++ classes from C# code
Invoke C++ inline methods from C# code (provided your library is compiled with -fkeep-inline-functions or that you provide a surrogate
library)
Subclass C++ classes from C#
Override C++ methods with C# methods
Expose instances of C++ classes or mixed C++/C# classes to both C# code and C++ as if they were native code.
CXXI is the result of two summers of work from Google's Summer of Code towards improving the interoperability of Mono with the C++ language.