I'm trying to import some functions created in a C++ library, to be used in delphi. Here is the library i'm trying to use: https://github.com/NGSolve/netgen/blob/master/nglib/nglib.h
I've looked around on google, and found that i've to create a .dll file out of this header file and then, somehow, import hese functions in delphi. The problem is i don't know how i can do any of this!
Can you guys help me out? Thanks in advance!!
There are two main ways to do this. Both require you to generate a DLL out of the code. I can't give a detailed explanation on how to do this. But on my website I do give you the details and some sample code. See links below.
The two main ways are
Flatten the object. Wrap each method of the object into a plain function and export that from the DLL. The object is simply passed along as some kind of handle or untyped pointer. You can't use the object directly, so no need to type the pointer or handle. This is the easiest solution, but not as convenient for the user of the DLL as the next one:
Turn your object into a COM interface and write a function to instantiate that. This is far from easy, but makes the DLL much easier to use.
Both ways are described in my article Using C++ objects in Delphi.
You can find some more info in other articles of mine:
Pitfalls of converting
DLL dos and don'ts
Using C object files in Delphi.
If these are not compiled with C++Builder, you may be lucky that you can do without the DLL and link to object files directly, using the flattening method. But I never tried that.
You can only use plain C API interfaces in Delphi so far. So maybe try to wrap the C++ API with plain C function calls first.
Related
How can I find a class to call it's methods by knowing class name and method names?
Details:
I'm trying to write library to replace some functions from another program which is also written using C++ by LD_PRELOAD functionality.
I need to have an ability to call functions from program in which this library gonna be integrated.
C++ loses all class naming information during the compile process!
You can`t do something like:
Class.forName("MyClass");
Like you know it from Java.
http://en.cppreference.com/w/cpp/language/class
This technique is called reflection and its not suported by C++
You can use a Framework (e.g. Boost) to help you out there, but the methods you want to call have to be declared and defined with this Framework.
C++ does not support reflection so you cannot search for functions/classes by name after compile time.
It sounds like if possible the design needs to be reworked. Ideally you should update the library to include what it needs from the programs. Either pull out the common logic from the programs into a third library - or put the functions that needs to be called by the programs into the current library and just pass the relevant data that will be manipulated into the library.
If this is not possible you can pass a function pointer from your programs into your library - this allows the library to have access to the functions it needs without any real knowledge of where it is coming from.
ie
void library_function1(std::function<void(int)> func)
{
func(1);
}
As per my understanding #import is taking the required headers/dependencies in compilation time.
Load library takes its dependencies in run-time from running pc. If it is wrong please correct me.
Whether LoadLibrary exactly what #import does?
The #import directive is a code generator. It takes the path to a type library, a language-independent way to describe types exposed by code written in an arbitrary language. Equivalent to an .h file in C or C++. Could be a .tlb file, most commonly type libraries are embedded as a resource in an executable file. The compiler de-compiles the type library content into equivalent C and C++ declarations.
The directive produces two files, you can find them back in your build directory. The .tlh file is a header file that a C or C++ compiler can use. The .tli file contains C++ wrapper functions that makes calling the interface methods much less error-prone. Based on the _com_ptr_t smart pointer class that takes care of the required reference counting, the wrapper functions turn error codes into C++ exceptions.
No LoadLibrary at all, that's taken care of by the COM infrastructure. Automatically invoked when you create an object of the exposed type. CoCreateInstance() is the factory function that takes care of it. The registry contains the required information to locate the matching executable file.
There is a learning curve, avoid cutting corners. Lots and lots of books about it, although many are out-of-print today, the MSDN landing page for the C++ wrapper classes is here.
For some test needs I need some third-party dll to be replaced with own stubbed version: the actual methods should return some hard-coded data with some specific delays and delays' effect on the system that uses the original dll are actually the under the test.
So, for this purpose I need some how to create a *.cpp file with the same structs and signatures from the dll. What is the best approach to do it programmatically?
1) decompilers? but actually I don't need the code itself, just class definitions and signatures only.
2) do it programmatically with c++ code
3) do it programmatically with java code through JNI, for example.
Any ideas and directions are welcome. Unfortunately, googling doesn't give the straighforward answer, at least for c++ newbies as me.
If this DLL is loaded from Java and called via JNI, then you can launch javah to produce the relevant headers; use -stubs option to prepare the C files with dummy implementations of all native methods.
Update: -stubs does not work correctly, see Unable to generate JNI .c file using javah -stubs
I've been developing for some time. And these beasts appear from time to time in MFC, wxWidgets code, and yet I can't find any info on what they do exactly.
As I understand, they appeared before dynamic_cast was integrated into core C++. And the purpose, is to allow for object creation on the fly, and runtime dynamic casts.
But this is where all the information I found, ends.
I've run into some sample code that uses DECLARE_DYNAMIC_CLASS and IMPLEMENT_DYNAMIC_CLASS within a DLL, and that is used for exported classes. And this structure confuses me.
Why is it done this way? Is that a plugin based approach, where you call LoadLibrary and then call the CreateDynamicClass to get a pointer which can be casted to the needed type?
Does the DECLARE/IMPLEMENT_DYNAMIC work over DLL boundaries? Since even class is not so safe to DLLEXPORT, and here we have a custom RTTI table in addition to existing problems.
Is it possible to derive my class from a DYNAMIC_CLASS from another DLL, how would it work?
Can anyone please explain me what these things are for, or where I can find more than a two sentences on a topic?
This stuff appends addional type information to your class, which allows to RTTI in runtime-independent manner, possibility of having factories to create your classes and many other things. You can find similar approach at COM, QMetaObject, etc
Have you looked at the definitions of DECLARE/IMPLEMENT_DYNAMIC?
In the MS world, all uppercase usually denotes a macro, so you can just look up the definition and try to work out what it's doing from there. If you're in Visual Studio, there's a key you can hit to jump to the definition - see what it says, and look that up and try to work from there.
I have a dll, which I want to use in my java code.
I declare a function as native and the return type is bool (c).
As I saw in JNI documentation, java 'boolean' should be mapped as 'jboolean' in c code. But the problem is that i don't have the c code, only dll.
My actually problem is UnsatisfiedLinkError, but I have no idea what else can be wrong.
If it is the problem, should i write another c-wrapper?
(I know that this exception was already discussed a lot of times, but I didn't find some useful information according my case)
UPD:
Maybe there are anothere way to use dll?
You can't use an arbitrary DLL directly from Java. You have to declare a native Java method, write the JNI for it, and call the DLL method(s) from the JNI code.