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.
Related
Ethovision is an old computer vision software writen in c++ used mainly for tracking mice. It has the possibility to Real Time Export this data and i have been given the task to establish a program that use this data. i am quite confused on how as i am a beginer programmer and have only done web design so far.
I have been provided with some IDL files but i have no clue what im supposed to do with them and im just really confused in general. Does any one have any general idea on what i should do/read to extract this data.
Sorry if this sounds dumb, im new at this.
Q. If its a typelib does it mean the functions are defined within that file? or are they somewhere else? If theyre defined in c++ how would i import them in another language?
No. The interface is only described in that file. But in the case of COM "type libraries", there will be GUID identifiers for
the type library
classes (co-classes)
interfaces (IUnknown/IDispatch derived)
search the registry (regedit.exe, regedt32.exe) for the typelibrary GUID to find what registered COM component implements it.
If it's a wellknown component, dropping the GUID in Google could reveal some useful documentation
You can import these in many languages that have COM interop, like VB6, C#, VB.Net, and yes even C++ provided that you either use MSVC's builtin extensions or external libraries to make it workable.
I'm going to give some pointers here assuming that you want the MSVC (Visual Studio's C++ compiler) route on windows:
Use oleview.exe to view typelibraries. You can also view dlls that have their typelibraries as embedded resources. You can then save the TLB file separately, or view the IDL
Use MIDL.EXE (The MIDL Compiler), specifically for COM https://learn.microsoft.com/en-us/windows/win32/midl/midl-and-com
I recommand #import directive which basically does the same as generating the header/implementation files and including them in one line
TL;DR Summary
If you can, don't do this from C++. The reason is that COM interfaces speak "high level" types that just require tedious, error prone handling in C or C++ (using wrappers like CComBSTR or bstr_t).
In a language like C# you get all the marshalling and threading ("apartments") guarantees for free.
I need to use a 3rd party code/dll in my .Net service. I did some research. But I can't find any direct answer for this. Mostly are recommending to port the code into VS C++ .net using a wrapper class. At the same time since there are VCL-headers used which has no replacements in VS C++. Can someone guide me on this please?
The VCL files in use are : Classes.hpp, Sockets.hpp and, ExtCtrls.hpp
Thanks in advance.
A DLL written in C++Builder works just fine in C# provided that the DLL exports flat C-style functions that use basic interop-safe data types and calling conventions that are portable across multiple compilers. Or the DLL implements a COM object (since COM has a standardized ABI). This is no different than writing any DLL that can be used in multiple languages including Delphi, VB, Java, Perl, PHP, etc.
You can't use VCL headers directly in the DLL's public interface, since VCL is not portable to non-Delphi/C++Builder compilers. But you can hide the VCL code behind an abstraction layer that is portable.
I have a C/C++ .dll containing core functionality of my program, and a Delphi project for the graphical user interface.
Is there any way I can export something like a std::vector or std::map to Delphi and use it in C++?
Thanks in advance
C++ classes can only be directly consumed by C++ code. Similarly, Delphi classes can only be directly consumed by Delphi code.
An exception to these rules is that Embarcadero's compilers have interop support and it is possible to consume some Delphi classes from C++ code, so long as the C++ code is compiled using an Embarcadero compiler.
Assuming that you are not using an Embarcadero C++ compiler you will need to wrap any classes that you wish to export in an interop friendly manner. The obvious choice for this is COM which was designed to solve this very problem.
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.
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.