问题描述
我在linux中做了很多编程，我使用visibility属性来定义符号在共享对象中是可见还是隐藏。只是为了使事情更清晰：如果一个符号是可见的，它将被外部访问（有人链接到共享对象），如果它被隐藏，它应该只在内部使用。
在windows上它似乎工作有点不同，它与导出（符号在共享对象中定义，并且可以由与此链接的人访问）和导入（这里我链接到共享对象并且符号导出到那里）符号。但我找不到一个方法告诉编译器不导出一个符号，因为它必须只在这里使用，即如果有人链接到它一个链接器错误预期。
此外，在windows主题中的所有可见性对我来说有点模糊，我正在寻找一些进一步的阅读链接，以更好地了解一切的工作原理。
David Rodriguez是正确的，在MSVC环境中，程序员通常通过特定于MSVC的修饰符。未显式导出的符号不应显示在已编译DLL的符号表中（您可以使用，一个Visual Studio命令行工具，要验证，使用/ EXPORTS选项）。当导入该符号时使用dllimport是惯例，但我相信这是可选的。这种方式通常是定义一个DLL的公共接口的头文件有一个宏，默认扩展为__declspec（dllimport），但是在构建该库时设置为扩展为__declspec（dllexport）。
请注意，GCC和MSVC如何处理dllexport可能不同;也许GCC不尊重dllexport隐藏未导出的符号的意义？我将首先尝试编译与MSVC和测试这些结果与dumpbin之前尝试与GCC相同。如果你没有Visual Studio，你仍然可以通过下载VS Express下载某个MSVC编译器，或者通过下载某些带有命令行MSVC（这两个选项都是自由和合法的）的可再发行组件。 VS Express可能是更好的选择，所以你可以得到dumpbin。
I do a lot of programming in linux and I use the visibility attribute to define if a symbol is visible or hidden in the Shared Object. Just to make the things clearer possible: If a symbol is visible it will be accessible externally (someone linking with the shared object), if it is hidden it is supposed to be used only internally.
On windows it seems to work a bit different, it works with exporting (the symbol is defined here in the shared object and will be accessible by someone linking with this) and importing (here I am linking with a shared object and the symbol is exported there) symbols. But I couldn't find a way to tell the compiler to not export a symbol because it must be used only here, i.e. if someone link with it a linker error is expected.
My question is if I can define a symbol as "hidden" (like in linux's gcc) and how.Also, all this visibility in windows topic is a bit fuzzy for me and I was looking for some further reading links to understand better how everything works.
David Rodriguez is correct, in the MSVC environment the programmer typically explicitly exports function/class symbols via the MSVC-specific __declspec(dllexport) modifier. Symbols that aren't explicitly exported shouldn't show up in the symbol table for the compiled DLL (you can use dumpbin, one of the Visual Studio command line utils, to verify, using the /EXPORTS option). It is convention to use dllimport when you import that symbol, although I believe this is optional. How this typically plays out is that header files defining the public interface of a DLL will have some macro that expands to __declspec(dllimport) by default, but is set to expand to __declspec(dllexport) while that library is being built.
Note that how GCC and MSVC treat dllexport may be different; perhaps GCC doesn't 'respect' dllexport in the sense of hiding unexported symbols? I would first try compiling with MSVC and test those results with dumpbin before trying the same with GCC. If you don't have Visual Studio, you can still get a MSVC compiler by either downloading VS Express, or (less known) by downloading certain .NET redistributables which ship with command line MSVC (both these options are free and legit). VS Express may be the better choice here so you can get dumpbin.
这篇关于在Windows中的符号可见性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！