Based on what I’ve read about exporting symbols from a DLL in Microsoft’s documentation, you can tell the linker to not include a symbol in the .lib import file by appending the PRIVATE keyword to the export. This, in effect, hides that symbol from application code that uses the library.
My question is, doesn’t the C++ keyword static already make variables/functions invisible to any external translation units?
>Solution :
static and PRIVATE (wrt. DLLs, similar to -fvisibility=hidden for Linux DSOs) are two different concepts.
The C++ standard as such is agnostic to DLLs and its implementations on different operating systems. static is applied on a translation unit (TU) level, i.e. it restricts the visibility of a symbol (function/variable) to the file is was defined in. So if you have two files a.cpp and b.cpp, neither can see the static symbols of the other. Say you define a function static void foo() in a.cpp. There is no way b.cpp (or any other TU) can see foo(), because you’ve restricted its visibility to the file it was defined in.
On the contrary, PRIVATE restricts visibility on the DLL level, i.e. what is accessible when using the DLL. Meaning that the function void bar() (note: non-static) defined in a.cpp can be used by b.cpp, either by an extern declaration or by including some header a.h. However if you declare bar() as PRIVATE in your .DEF file, users of your DLL won’t be able to call bar(), because the respective symbol won’t be exported.
In that respect, static is a bit more restrictive than PRIVATE, because it already restricts visibility on TU level.