what does __declspec(dllimport) really mean?

Question

I saw the Qt source code like this:

class Q_CORE_EXPORT QBasicAtomicInt
{
public:
...
};

Which Q_CORE_EXPORT macro defines like below:

define Q_DECL_IMPORT __declspec(dllimport)

So what does __declspec(dllimport) really mean?

Solution 1

__declspec is a Microsoft-specific attribute that allows you to specify storage-class information.
_{(Nitpicker's Corner: However, a number of other compiler vendors—e.g. GCC—now support this language extension for compatibility with the installed base of code that was written targeting Microsoft's compilers. Some even provide additional storage-class attributes.)}

Two of those storage-class attributes that can be specified are dllimport and dllexport. These indicate to the compiler that a function or object is imported or exported (respectively) from a DLL.

More specifically, they define the DLL's interface to the client without requiring a module-definition (.DEF) file. Most people find it much easier to use these language extensions than to create DEF files.

For obvious reasons, __declspec(dllimport) and __declspec(dllexport) are generally paired with one another. You use dllexport to mark a symbol as exported from a DLL, and you use dllimport to import that exported symbol in another file.

Because of this, and because the same header file is generally used both when compiling the DLL and in client code that consumes the DLL's interface, it is a common pattern to define a macro that automatically resolves to the appropriate attribute specifier at compile-time. For example:

#if COMPILING_DLL
    #define DLLEXPORT __declspec(dllexport)
#else
    #define DLLEXPORT __declspec(dllimport)
#endif

And then marking all of the symbols that should be exported with DLLEXPORT.

Presumably, that is what the Q_CORE_EXPORT macro does, resolving to either Q_DECL_IMPORT or Q_DECL_EXPORT.

Solution 2

__declspec(dllimport) is a storage-class specifier that tells the compiler that a function or object or data type is defined in an external DLL.

The function or object or data type is exported from a DLL with a corresponding __declspec(dllexport).

Solution 3

__declspec(dllexport) tells the compiler to inform the linker that these symbols need to be placed in the export table (when compiling the .dll), and to put those symbols in the import library .lib. When compiling the program that links with the .dll, __declspec(dllimport) tells the compiler to produce a rip-relative memory-indirect call (which the linker will fill resolve to point to the import table) rather than the usual relative direct instruction to the undefined function (which, as it can't modify the instruction, the linker inserts the relative address of a thunk and then creates the thunk, inside which it places the rip-relative memory-indirect jump to the function pointer in the import table). This is a code size and speed optimisation. It is the import library .lib that tells the linker which symbols are exported by the .dll and is used as a guide to create the import table based on the intersection of those with the matching extern symbol table entries and create any necessary thunks in the .text segment.

https://docs.microsoft.com/en-us/cpp/build/importing-function-calls-using-declspec-dllimport?view=vs-2019 https://docs.microsoft.com/en-us/cpp/build/importing-data-using-declspec-dllimport?view=vs-2019 https://stackoverflow.com/a/4490536/7194773

Comments

[user1703401]

possible duplicate of Why/when is __declspec( dllimport ) not needed?

[Emilio Garavaglia]

__declspec is not properly "MS-specific" (it's much more "compiler specific) and some compilers use this declaration for multiple platform as well. Some of the attributes values are (dllexport / dllimports are MS specific, in fact, since DLL is MS lexicon).

[Cody Gray]

@Emilio: As far as I'm aware, Microsoft invented the __declspec notation as an extension to the C++ language. I believe that GCC now supports it, but that's primarily for compatibility reasons with Microsoft's compilers. And I don't understand how "MS-specific" is any different from "compiler specific". Microsoft wrote a C++ compiler and lots of people use it. It comes with Visual Studio.

[Emilio Garavaglia]

MS-specific means "specific to MS environment", while "compiler specific" means "specific to a given compiler, not to all". Now, since there are non-MS compiler using __declspec, it cannot be said -stricly speacking- MS specific. (note: there are some __declspec for GCC that realtes to Linux as well, so it's even not just a Windows issue...). What you say is historically true, but not "semantically".

[Remy Lebeau]

Neither __declspec() nor dllimport/dllexport are specific to Microsoft compilers. __declspec is used by a range of different vendor compilers for supporting compiler-specific extensions to the C++ language itself. Just about all C++ compilers that support Microsoft platforms support the dllimport/dllexport extension, but they are certainly not the only extensions available.

[Cody Gray]

Microsoft makes a compiler. It's called the "Microsoft C/C++ Optimizing Compiler", cl.exe. Lots of people erroneously refer to Visual Studio as if it is a compiler, but it's an IDE. I don't know why people are nit-picking about what "Microsoft-specific" means. It doesn't mean an "MS environment" (whatever that is), and it certainly doesn't mean "Windows". Yes, other compiler vendors now support the extension for compatibility with the installed base of code written targeting Microsoft compilers. As I said before, as far as I'm aware, Microsoft invented the syntax. That's the point made here.

[celtschk]

@CodyGray: Microsoft having invented it alone would not suffice. However Microsoft having invented it, no standard containing it, others only implementing it for compatibility and it being used primarily (if not exclusively) for programs targeting Microsoft Windows together make a very strong point for calling it "Microsoft specific"

[Emilio Garavaglia]

@CodeGray: So, to stay with yoyr assumpion C++ is "Stroustroup specific" ?!? __declspec is not present only in Microsoft compiler, hence isn'nt ANYMORE microsoft specific. At least for what the English dictinary tells about the word "specific".

[Cody Gray]

Stroustroup released C++ as an open standard.

[Ela782]

This is an awesome answer, especially the part about "because the same header file is generally used both when compiling the DLL and in client code"! Makes every aspect of the import/export-stuff crystal clear.

[el psy Congroo]

Ok. Finally, after 2 hours of reading, i found the most satisfying, most concise, accurate to the point statement of what I want.

[Alejandro Nagy]

+1 to @Ela782, I couldn't get my head around it until I read that line. You use export when the "owner" of the header builds the lib/dll and import when the "client/consumer" uses it as interface to that lib.