Important: Please read the Qt Code of Conduct -

Q_DECL_EXPORT and function name for Windows DLLs

  • I have some code that I wrote in C++ in Qt that I want to wrap in a Windows 32-bit DLL for use in another language (Delphi).

    I struggled to get a simple procedure to export correctly, for example:

    @extern "C" MYDLLSHARED_EXPORT int __stdcall AddIntegers(int left, int right);@

    where MYDLLSHARED_EXPORT is the thing defined in MyDLL_global.h as Q_DECL_EXPORT (auto generated by Qt Creator when I selected to create a library).

    When I use a special tool to view the exported procedure names in the resulting DLL I see "AddIntegers@8" when I expect to see "AddIntegers" (as is the case with other DLLs I've written in other languages). It could be something to do with the tool I'm using (called DLL Export Viewer), but GetProcAddress on the Delphi side also fails to load AddIntegers (LoadLibrary was successful). Is there something I'm doing wrong?

  • If you only want to export function try "this standard type of dll exporting function":

    extern "C" __declspec(dllexport) int AddIntegers(int left, int right)
    return left + right;

  • Thanks, cincirin, your example worked - seems that the __stdcall is apparently responsible for the @8 being added to the name. Strangely I don't see this with functions in DLLs that I also know for a fact are standard calling convention but were not created with Qt.

    Could it be something that Qt does to indicate to itself the calling convention (assuming the DLLs will aso be used by Qt)? I guess this just forces me to use default calling convention.

  • From what I see "here": in "Name-decoration convention" section,

    bq. An underscore (_) is prefixed to the name. The name is followed by the at sign (@) followed by the number of bytes (in decimal) in the argument list. Therefore, the function declared as int func( int a, double b ) is decorated as follows: _func@12

  • Mixing: extern "C" and __stdcall is wrong as __stdcall is the standard ABI conventions for C++.

    There is a __cdecl which would be correct for C but will be implied by the: extern "C" part and so it no needed.

Log in to reply