Announcement

Collapse
No announcement yet.

DLL Function Names keep getting Mangled!

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    DLL Function Names keep getting Mangled!

    Hi All,

    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:

    Code:
    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.






    Cheers
    Last edited by Fredrum; 11-13-2014, 08:45 PM.

    #2
    The question then remains, should I be able to somehow export a full and complex class without getting names mangled?
    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.

    Comment


      #3
      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?

      Comment


        #4
        Thanks a lot for the replies!

        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.
        Last edited by Fredrum; 11-13-2014, 09:31 PM.

        Comment


          #5
          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, , just use C++ and don't mind creating a C flattening of your API.

          Comment


            #6
            http://www.codeproject.com/Articles/...ses-from-a-DLL

            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.

            Comment


              #7
              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.

              Cheers!

              Comment

              Working...
              X