I’m not a very experienced c++ programmer at all and am having problems getting a .dll dynamic library loaded in the correct way.
I am following this tutorial and just managed to get it to work.
The problem is that I have not managed to reference the proper/nice function names. I am using VS preset for compiling dll’s but the names keep coming out mangled so that in the UE4 code, to get it to work, I now have to do:
FString procName = "?SimpleTest@@YAHXZ"; // the exact name of our dll function to recover. HAVE NOT MANAGED TO DO NICE NAMES!
DLLgetValue = (_SimpleTest)FPlatformProcess::GetDllExport(DLLHandle, *procName); // get the dll function need
I have read up on this elsewhere and people are suggesting different methods but surely for a simple case of a single standalone function like ‘SimpleTest()’ in this case, the VS preset should work and not give me the mangled names?
And for you that have done this, should I also be able to export whole full classes for use?
EDIT: I just actually managed to export my simple test function by using my own macro: #define DllFuncExport extern “C” __declspec( dllexport )
(I thought I had tried that but must have made some other error then.)
The question then remains, should I be able to somehow export a full and complex class without getting names mangled?
As extern “C” seems to not work as it is meant for c code compatibility, that don’t have the concept of classes.
C++ compilers will always mangle names when exporting - it is how they cope with potential namespace conflicts. One option you can investigate is building your DLL with a .def definition file. This can eliminate name mangling.
You can export full C++ classes, and consume them with the exact same compiler. They names will always be mangled, there is no fine other way to do it. So no C++ export from Visual Studio 2013 to mingw’s gcc.
You can export functions using the C standard (like you found out) and consume those with anything that adheres to that standard, so even totally different languages, like C# or Java.
But whats your goal here? Want to import from a C++ library you have no sources for?
Might look into the .def file see if that would save me any work.
The driving force behind this is lazyness! (and also flexibility)
I am writing the dll myself too but it is depending on a lot of windows bits and has a lot of windows specific data types and ‘things’. I started with a much more straightforward windows function but that caused me some trouble to get to work in UE4-VS-c++ so I thought maybe it’s easier to just keep this new more complex one as a separate project and just import it as dll?
Also I(we) are just trying to figure out what engine will work out best for us so I thought I might be able to use the code I write in ‘the other’ engine too if I try to keep it more standalone.
If you want to be able to use it anywhere use a flattened C binding. And writing __declspec(export) to the exported functions is easier then def files, and I don’t think def files change the binding language standard. Just a change in name without a change of calling standard will cause chaos, not helping you.
You can have a whole code block to use C binding by writing extern “C” { [code in here] }. But remember, you don’t export C++ classes and objects, but C functions. You must program according to it.
So if you stay with UE4, and I can’t image why you wouldn’t, :D, just use C++ and don’t mind creating a C flattening of your API.
This text is good I think. The first part is about C. The Xyz Handle it talkes about would be your C++ object (pointer) that you pass around as opaque handle in the C api you create.
Thanks again for the advice and clear explanations!
I will do the c style functions then and the link seems good. I will try to understand the text there to keep some object oriented’ness in the process.
(and also flexibility)