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.
Related
I am wondering what is the best/most common way to create a C++ library that I could create a wrapper for in another language.For example I if I create a library in C++ I'd like to create a wrapper for it in C# and then later on create a wrapper for the C++ library in Python.
I also want to be able to give the library to another person easily almost like a one file thing if that is possible? Also should I use a Dynamic Link Library or a Static Link Library? Extremely new to this sort of thing thanks.
A very common way that people simplify linking C or C++ code to other languages is through the Simplified Wrapper and Interface Generator. For the language runtimes it supports, it's a much easier to understand interface than integrating closely with each different language you wish to ship your library for.
In general, this will mean creating a dynamic library. Loading a dynamic library is a simple task for any runtime, but loading a static module would require modifying the language runtime. For that reason, it simply doesn't make sense to build a static module for either of your cited use cases.
For Python, with your build properly configured, you can ship your library module as a single dynamic library (barring licensing problems with libraries you link to). However, users will typically expect your module to be packaged using the standard Python setup-tools, as a .egg file.
You should be prepared to learn how each respective language community expects third-party packages to be packaged, to make the introduction of your library to them as easy as possible. Conforming to their expectations makes your library appear more professional, better designed, and easier to consider for their projects.
I would recommend, however, spending some time learning more about the Foreign Function Interface of a few different languages, to familiarize yourself with some of the peculiarities that SWIG sometimes can't hide perfectly. For example, passing a value to the other language requires "boxing" the C++ value into a value type, and then incrementing its reference count. SWIG does this for you, but it's sometimes the case where you have no choice but to write or debug some of that code yourself. Being unfamiliar with how those FFI interfaces work will hinder you substantially.
I am learning C++ with the intention to make programs with zero dependencies.
I am noticing that throughout my code I later find out that a libary/dll/functions I have been using requires the machine running it to have .NET installed or some other package.
How can I detect this beforehand?
Are most things that are possible with these .NET libaries/dlls/functions possible with only Native C++ libaries/dlls/functions?
I assumed so.
How can I detect this beforehand?
Basically don't use anything beyond C++ standard library, which is described here or here.
A tool like Dependency Walker can be handy.
You can also use static libraries to make program less dependent on DLLs.
Are most things that are possible with these .NET
libaries/dlls/functions possible with only Native C++
libaries/dlls/functions?
The point is modern software must depend on some underlying framework and libraries, because it's pointless/impossible to write everything from scratch using only standard library. If you want to write rich application you need something like .NET. It can be cross-platform framework tho, like qt, which will give you more flexibility.
I have a C++ *.h file with three classes in it. The header file is for accessing a DLL. I have almost no C++ knowledge. However, I seem to recall from somewhere that you can't convert a *.h file to a Delphi unit that has classes in it. Is this true?
If it isn't true, and classes in header files aren't a problem, what is the general approach to converting the classes to Delphi?
C++ classes, just like Delphi classes, are not designed for binary interop.
A Delphi class can only be exported for consumption by other Delphi code, and then only in a package, and only when runtime packages are in use, and only when all modules use the same version of Delphi. In a similar vein, C++ classes can only be imported from a DLL by code compiled with the same tool chain that compiled the DLL.
So, it is not possible for your Delphi code to consume this DLL. As I see it you have the following options:
Persuade the supplier of the DLL to provide an interop friendly interface to the library. For instance, a plain functional C style interface, or a COM interface.
Write an adapter in C++, using the same compiler that was used to build the DLL. That would involve you importing the classes into your wrapper and exposing them to your Delphi code in an interop friendly manner. Again, plain C style interface or COM are the obvious choices.
In the sense of allowing you to use the DLL from Delphi code? Yeah, good luck with that. You know how you can't use Delphi classes in a DLL unless the client code is written in the same version of Delphi and even then it's usually a bad idea due to shared memory management gotchas? C++ poses exactly the same problem, only exponentially worse because there's no standardized ABI and there's all sorts of C++-language screwed-uppedness making problems for you.
The only real way to make it work reliably is with an interface that uses a standard ABI. If you have the source, try making a C interface that wraps the C++ interface. If not, ask the person who wrote the DLL to provide a C interface, and ask whoever made the decision to use this DLL why you're using a 3rd party library with no source available. :P
As commented in a previous answer the solution is using SWIG in order to generate the pascal binding. I started the development of the SWIG's pascal module but I had not time to complete it. Basically it works but it lacks all the test cases to be integrated into SWIG.
I used it in my personal projects and I was able to import complex library as GDAL.
I need to build a C++ library to distribute among our customers. The library must be able to be accessed from a wide range of languages including VB6, C++, VB.net and C#.
I've being using ActiveX controls (ocx files) until now. But I wonder if there is a better kind of library (dll, etc.) that I can build. What do you recommend?
I'm limited to C++ as the library language, but you can mention other languages for reference to other developers.
P.S. Sorry if the question was already asked. I had some trouble finding a suitable title. Feel free to correct my English.
Edit: Seems like the best choice is either DLLs or OCX (i.e., COM), but I'm still having some doubts on which one will I choose. Which one is more suitable to modern languages (.NET for instance)? Which one would be easier to use from an end developer perspective?
Almost every language has a way of loading dynamic libraries and accessing exported C functions from them.
There is nothing preventing you from using C++ inside the dll but for maximum portability, export only C functions.
I have some more about this in this post.
If you're looking at supporting both VB6 and .NET, you're pretty much stuck with exposing interfaces via COM, but at least that'll get you out of having to create more than one wrapper based on the language/runtime system you're trying to interact with.
If there is any chance this will need to be ported to non windows platforms then a DLL / Shared library is your best choice as a COM object really isn't at all portable.
In addition you can call a DLL from almost any platform even if it requires you to write a wrapper of some kind. It's pretty easy to wrap a dll in a com object but if you make a native com object it's a lot harder to add a C style DLL API. Plus you might want to call it from java for example and it's much easier to write a JNI wrapper to call your DLL than get it working with COM in any kind of cross platform way.
Really it depends on what platforms you really need to call it from and how certain you can be that you won't get something out of the ordinary in future.
To be callable from all those languages your only real option is going to be COM, without having to write wrappers where required (which would defeat the point)
Plug-in systems in C++ are hard because the ABI is not properly defined, and each compiler (or version thereof) follows its own rules. However, COM on Windows shows that it's possible to create a minimal plug-in system that allows programmers with different compilers to create plug-ins for a host application using a simple interface.
Let's be practical, and leave the C++ standard, which is not very helpful in this respect, aside for a minute. If I want to write an app for Windows and Mac (and optionally Linux) that supports C++ plug-ins, and if I want to give plug-in authors a reasonably large choice of compilers (say less than 2 year old versions of Visual C++, GCC or Intel's C++ compiler), what features of C++ could I count on?
Of course, I assume that plug-ins would be written for a specific platform.
Off the top of my head, here are some C++ features I can think of, with what I think is the answer:
vtable layout, to use objects through abstract classes? (yes)
built-in types, pointers? (yes)
structs, unions? (yes)
exceptions? (no)
extern "C" functions? (yes)
stdcall non-extern "C" functions with built-in parameter types? (yes)
non-stdcall non-extern "C" functions with user-defined parameter types? (no)
I would appreciate any experience you have in that area that you could share. If you know of any moderately successful app that has a C++ plug-in system, that's cool too.
Carl
Dr Dobb's Journal has an article Building Your Own Plugin Framework: Part 1 which is pretty good reading on the subject. It is the start of a series of articles which covers the architecture, development, and deployment of a C/C++ cross-platform plugin framework.
You might also want to consider replacing the conventional plugin interface by a scripting interface. There are some very good bindings for several scripting languages in C/C++ that have already solved your problem. It might not be a bad idea to build on top of them. For example, have a look at Boost.Python.
Qt has a very nice system for plugins that I've used in the past. It uses Qt's meta-object system to overcome many of the problems typically found when trying to develop C++ plugins.
One example is how Q_DECLARE_INTERFACE works, to prevent you from using an incompatible plugin. Another is the build key, to make sure you load the correct plugin for your architecture, OS, compiler. If you don't use Qt's plugin system, these are things you will have to worry about and invent solutions for on your own. It's not necessarily rocket science, and I'm not saying you'd fail at it, but the guys at Trolltech are pretty smart and have spent a while thinking about it, and I'd rather use what they created than reinvent the wheel myself.
Another example is that RTTI typically doesn't work across DLL boundaries, but when using Qt, things like qobject_cast which rely on the meta-object system do work across DLL boundaries.
I think you are safe creating a plugin system based on:
Packaging of plugin functionality into library (.dll, .so, etc.)
Requiring that the plugin expose key C-language exports.
Requiring that the plugin implement (and return a pointer/reference to) an abstract C++ interface.
Probably the most successful C++ plugin system: good old Adobe Photoshop. And if not that, one of the virtual synth formats such as VSTi etc.
The book Imperfect C++ by Matthew Wilson has a nice info about this.
The advice in the seems to be: as long as you use the same (or equivelant) compiler, you can use C++, otherwise you're better of using C as an interface on top of your C++ code.
I have my own game engine that has a C++ plug-in system.
I have some code in header files so it gets put into the plugin's compilation unit.
Larger functions that live in the main engine are called via an exported C function (plugin calls MyObject_somefunction(MyObject *obj) which in the engine just calls obj->somefunction()). If calling a C function is ugly for your taste, then with some header trickery, when the header is included in the plugin, have the member function #defined to call the C function:
#if defined(IN_THE_PLUGIN)
void MyObject::somefunction() { MyObject_somefunction(this); }
#endif
Virtual functions either have to be pure or the code lives in the header file. If I'm not inheriting from a class and merely just instancing one, virtual function code can live in the engine, but then the class must export some C functions for creating and destroying the object that is called from the plugin.
Basically, the tricks that I have used, with the goal being to maintain total platform independence, just amount to C exports and header file tricks.
ACE has a cross platform plug-in architecture.
Check out:
ACE DLL
ACE DLL Manager
I would suggest checking out the book
The ACE Programmer's Guide
Firefox runs on XPCOM (http://www.mozilla.org/projects/xpcom/). It's inspired by Microsoft COM but it's multiplatform.