[zt]def文件里面的private是什么意思？

EXPORTS 语句引入了一个由一个或多个 definitions（导出的函数或数据）组成的节。每个定义必须在单独一行上。EXPORTS 关键字可以在第一个定义所在的同一行上或在前一行上。.def 文件可以包含一个或多个 EXPORTS 语句。

导出definitions 的语法为：

entryname[=internalname] [@ordinal [NONAME]] [PRIVATE] [DATA]

entryname 是要导出的函数名或变量名。这是必选项。如果导出的名称与 DLL 中的名称不同，则通过 internalname 指定 DLL 中导出的名称。例如，如果 DLL 导出函数 func1()，要将它用作 func2()，则应指定：EXPORTSfunc2=func1

@ordinal 允许指定是序号而不是函数名将进入 DLL 的导出表。这有助于最小化 DLL 的大小。.LIB 文件将包含序号与函数之间的映射，这使您得以像通常在使用 DLL 的项目中那样使用函数名。

可选的 NONAME 关键字允许只按序号导出，并减小结果 DLL 中导出表的大小。但是，如果要在 DLL 上悄轮稿使用 GetProcAddress，则必须知道序号，因为名称将桐键无效。

可选的 PRIVATE 关键字禁止将 entryname 放到由 LINK 生成的导入库中。它对同样是由 LINK 生成的图像中的导出无效。

可选的 DATA 关键字指定导出的是数据，而不是代码。例如，可以导出数据变量，如下所示：EXPORTSi DATA当对同一导出使用 PRIVATE 和 DATA 时，PRIVATE 必须位于 DATA 的前面。

有三种导出定义的方法，按照建议的使用顺序依次为：

源代码中的 __declspec(dllexport) 关键字

.def 文件中的 EXPORTS 语句

LINK 命令中的 /EXPORT 规范

所有这三种方法可以用在同一个程序中。LINK 在生成包含导出的程序时还创建导入库，除非生启孝成中使用了 .exp 文件。

以下是 EXPORTS 节的示例：EXPORTSDllCanUnloadNow @1 PRIVATE DATA

DllWindowName = Name DATA

DllGetClassObject @4 NONAME PRIVATE

DllRegisterServer @7

注意，使用 .def 文件从 DLL 中导出变量时，不需要在变量上指定 __declspec(dllexport)。

1、定义函数

函数是可重用的程序。本书中已经使用了许多内建函数，如len()函数和range()函数，但是还没自定义过函数。定义函数的语法格式如下：

def 函数名(参数):

函数体

定义函数的规则如下：

①关键字def用来定义一个函数，它是define的缩写。

②函数名是函数的唯一标识，函数名的命名规则遵循标识符的命名规则。

③函数名后面一定要紧跟着一个括号，括号内的参数是可选的，括号圆悔早后面要有冒号。

④函数体(statement)为一个或一组Python语句，注意要有缩进。

⑤函数体的第一行可以有文档字符串，用于描述函数的功能，用三引号括起来。

按照定义规则，可以定义第一个函数了：

>>> def hello_world():

...     print('Hello,world!')   # 注意函数体要有缩进

...

>>> hello_world()

Hello,world!

这个函数不带任何参数，它的功能是打印出“Hello,world!”。最后一行代码hello_world()是调用函数，即让Python执行函数的代码。

2、全局变量和局部变量

全局变量是定义在所有函数外的变量。例如，定义一个全局变量a，分别在函数test1()和test2()使用变量a：

>>> a = 100   # 全局变量

>>> def test1():

...     print(a)

...

>>> def test2():

...     print(a)

...

>>> test1()

100

>>> test2()

100

定义了全局变量a之后，在函数test1()和test2()内都可以使用变量a，由此可知，全局变量的作用范围是全局。

局部变量是在函数内定义的变量，除了用关键字global修饰的变量以外。例如，在函数test1()内定义一个局部变量a，分别在函数外和另一个函数test2()内使用变量a：

>>> def test1():

...     a = 100   # 局部变量

...     print(a)

...

>>> def test2():

...     print(a)

...

>>> test1()

100

>>> print(a)

Traceback (most recent call last):

File "<stdin>", line 1, in <module>

NameError: name 'a' is not defined

>>> test2()

Traceback (most recent call last):

File "<stdin>", line 1, in <module>

File "<stdin>", line 2, in test2

NameError: name 'a' is not defined

Python解释器提示出错了。由于局部变量a定义在函数test1()内，因此，在函数test1()内可以使用变量a，但是在函数外或者另一个函数test2()内使用变量前纯a，都会报错，由此可见，局部变量的作用范围是定义它的函数内部。

一般情况下，在函数内声明的变量都是局部变量，但是采用关键字global修饰的变量却是全局变量：

>>> def test1():

...     global a   # 全局变量

...     a = 100

...     print(a)

...

>>> def test2():

...     print(a)

...

>>> test1()

100

>>> print(a)

100

>>> test2()

100

这个程序与上个程序相比，只是在函数test1()中多了一行代码“global a”，程序便可以正确运行了。在函数test1()中，采用关键字global修饰了变量a之后，变量a就变成了全局变量，不仅可以在该函数内使用，还可以在函数外或者其他函数内使用。

如果在某个函数内局部变量与全局变量同名，那么在该函数中局部变量会覆盖全局变量：

>>> a = 100   # 全局变量

>>> def test1():

...     a = 200   # 同名局部变量

...     print(a)

...

>>> def test2():

...     print(a)

...

>>> test1()

200

>>> test2()

100

由于在函数test1()中定义了一个与全局橘雀变量同名的局部变量a，因此，在函数test1()中全局变量a的值被局部变量覆盖了，但是在函数test2()中全局变量a的值没有被覆盖。

综上所述，在Python中，全局变量保存的数据供整个脚本文件使用而局部变量只用于临时保存数据，变量仅供局部代码块使用。

链接器工具错误 LNK2001

错误消息

无法解析的外部符号“symbol”

代码引用了链接器无法在库和对象文件中找到的内容（如函数、变量或标签）。

该错误信息之后为错误 LNK1120。

可能的原因

在将托管库或 Web 服务项目从 Visual C++ 2003 升级到 Visual C++ 2005 时，/Zl 编译器选项将添加到“命令行”属性页中。这将导致 LNK2001。请从“命令行”属性页中移除 /Zl，以解决此问题。有关更多信息，请参见 /Zl（省略默认库名） 和 如何：打开项目属性页。或者，将 msvcrt.lib 和 msvcmrt.lib 添加到链接器的“附加依赖项”属性中。

代码请求的内容不存在（例如，符号拼写错误或使用错误的大小写）。

代码请求的内容错误（使指唤用的是混合版本的库，一些库来自产品的一个版本，而其他则来自另一个版本）。

具体原因

代码问题

如果 LNK2001 诊断文本报告 __check_commonlanguageruntime_version 是无法解析的外部符号，则请参见 LNK2019 获得有关如何解决该问题的信息。

成员模板的定义超出了类的范围。Visual C++ 的一个限制是，成员模板的定义必须完全位于封闭类内。有关 LNK2001 和成员模板的更多信息，请参见知识库文章 Q239436。

代码或模块定义 (.def) 文件中的大小写不匹配会导致 LNK2001。例如，当在一个 C++ 源文件中将一个变量命名为 var1，并试图在另一个源文件中以 VAR1 访问该变量时。

如果项目使用函数内联，但在 .cpp 文件而非头文件中定义函数，则会导致 LNK2001。

从 C++ 程序调用 C 函数但不使用 extern "C"（这导致编译器使用 C 命名约定）会导致 LNK2001。编译器选项 /Tp 和 /Tc 使编译器将文件分别编译为 C++ 或 C，与文件扩展名无关。这些选项会导致函数名与您所期望的名称不同。

试图引用没有外部链接的函数或数据会导致 LNK2001。在 C++ 中，内联函数和 const 数据具有内部链接，除非被显式指定为 extern。

缺少函数主体或变量会导致 LNK2001。如果只有函数原型或 extern 声明，编译器继续运行而不会出现任何错误，但由于没有保留函数代码或变量空间，链接器将无法解析地址调用或变量引用。

调用参数类型与函数声明中的参数类型不匹配的函数会导致 LNK2001。名称修饰将函数参数合并到最终修饰函数名中。

错误包含的原型导致编译器需要没有提供的函数体，这样会导致 LNK2001。如果同时具有函数 F 的类实现和非类实现，请注意 C++ 范围解析规则。

在使用 C++ 时，将函数原型包含在类定义中但未能包含实现（该类的此函数的实现）会导哪雹致 LNK2001。

试图从抽象基类的构造函数或析构函数调用纯虚函数会导致 LNK2001。纯虚函数没有基类实现。

试图在函数范围外使用用该函数声明的变量（局部变量）会导致 LNK2001。

在生成 ATL 项目的发布版本时，指示需要 CRT 启动代码。若要修复，请执行下列 *** 作之一：

将 _ATL_MIN_CRT 从预处理器定义的列表中移除，以允许包括 CRT 启动代码。有关更多信息，请参见常规配置设置属性页。

如果可能，移除对需要 CRT 启动代码的 CRT 函数的调用，而是使用它们的 Win32 等效函数。例如，使用 lstrcmp，而不要使用 strcmp。需要 CRT 启动代码的已知函数是一些字符串和浮点函数。

编译和链接问题

项目缺少对库 (.LIB) 或对象 (.OBJ) 文件的引用。有关更多信息，请参见用作链接器输唯缓凯入的 .lib 文件。

如果使用 /NODEFAULTLIB 或 /Zl，包含所需代码的库将不会链接到项目，除非已显式地包括了这些库。（在使用 /clr 或 /clr:pure 进行编译时，您将看到对 .cctor 的引用；有关更多信息，请参见 混合程序集的初始化。）

如果正在使用 Unicode 和 MFC，如果没有创建 wWinMainCRTStartup 的入口点，将在 _WinMain@16 上得到无法解析的外部对象；请使用 /ENTRY。请参见 Unicode 编程摘要。

有关更多信息，请参见下列位于 MSDN Library 中的知识库文章。在 MSDN Library 中，单击“搜索”选项卡，将文章编号或文章标题粘贴到文本框中，然后单击“列出主题”。如果按文章编号搜索，请确保清除“仅搜索标题”选项。

Q125750 “PRB: Error LNK2001: '_WinMain@16': Unresolved External Symbol”

Q131204 “PRB: Wrong Project Selection Causes LNK2001 on _WinMain@16”

Q100639 “Unicode Support in the Microsoft Foundation Class Library”

Q291952“PRB: Link Error LNK2001: Unresolved External Symbol _main”

将用 /MT 编译的代码与库 LIBC.lib 链接会在 _beginthread、_beginthreadex、_endthread 和 _endthreadex 上导致 LNK2001。

链接需要多线程库的代码（任何 MFC 代码或用 /MT 编译的代码）会在 _beginthread、_beginthreadex、_endthread 和 _endthreadex 上导致 LNK2001。有关更多信息，请参见下列知识库文章：

Q126646“PRB: Error Msg: LNK2001 on __beginthreadex and __endthreadex”

Q128641“INFO: /Mx Compiler Options and the LIBC, LIBCMT, MSVCRT Libs”

Q166504“PRB: MFC and CRT Must Match in debug/release and static/dynamic”

在用 /MD 进行编译时，因为所有的运行时现在都存放在一个 DLL 中，所以源中的“func”引用在对象中变为“__imp__func”引用。如果试图与 LIBC.lib 或 LIBCMT.lib 静态库链接，则将在 __imp__func 上得到 LNK2001。当不用 /MD 进行编译时，如果试图与 MSVCxx.lib 链接，则并非总是得到 LNK2001，但可能会有其他问题。

在生成应用程序的调试版本时与发布模式库链接会导致 LNK2001。同样，使用 /Mxd 选项（/MTd 或 /MDd）和/或定义 _DEBUG，然后再与版本库链接，将可能会产生无法解析的外部对象（同时还会出现其他问题）。将发布模式生成与调试库链接同样会导致类似问题。

将 Microsoft 库版本和编译器产品版本混合可能会有问题。新编译器版本的库可能包含早期版本的库中没有的新符号。可能需要更改搜索路径中的目录顺序，或将它们更改为指向当前版本。

使用库文件选择下的“工具”|“选项”|“项目”|“VC++ 目录”对话框，可以更改搜索顺序。项目的“属性页”对话框中的“链接器”文件夹可能也包含可能已过期的路径。

当安装了新的 SDK（可能在不同的位置），但没有将搜索顺序更新为指向新位置时，可能会出现此问题。通常情况下，应将新 SDK 的 include 目录和 lib 目录的路径放在默认 Visual C++ 位置的前面。另外，包含嵌入路径的项目可能仍然指向旧路径，这些路径是有效的，但对于安装到不同位置的新版本所添加的新功能已过期。

编译器供应商之间、甚至同一编译器的不同版本之间当前没有 C++ 命名标准。因此，链接用其他编译器编译的对象文件可能无法生成相同的命名方案，从而导致错误 LNK2001。

在不同模块上混合内联和非内联编译选项会导致 LNK2001。如果创建 C++ 库时打开了函数内联（/Ob1 或 /Ob2），但描述函数的相应头文件的内联是关闭的（没有 inline 关键字），则将发生此错误。若要防止此问题，请在要包含到其他文件中的头文件中用 inline 定义内联函数。

如果使用 #pragma inline_depth 编译器指令，请确保具有 设置为 2 或更大的值，并确保使用 /Ob1 或 /Ob2 编译器选项。

在创建纯资源 DLL 时省略 LINK 选项 /NOENTRY 将导致 LNK2001。

使用不正确的 /SUBSYSTEM 或 /ENTRY 设置会导致 LNK2001。例如，如果编写基于字符的应用程序（控制台应用程序）并指定 /SUBSYSTEM:WINDOWS，您将得到无法解析的 WinMain 外部对象。有关这些选项和入口点的更多信息，请参见 /SUBSYSTEM 和 /ENTRY 链接器选项。

导出问题

当将应用程序从 16 位移植到 32 位或 64 位时，会发生 LNK2001。当前的模块定义 (.def) 文件语法要求 __cdecl、__stdcall 和 __fastcall 函数列在 EXPORTS 节中，并且不带下划线（不修饰）。这不同于 16 位语法，这些函数在 16 位语法中列出时必须带下划线（修饰）。有关更多信息，请参见模块定义文件 EXPORTS 节的说明。

在 .def 文件中列出但未找到的任何导出将导致 LNK2001。这可能是因为导出不存在、拼写错误或使用了 C++ 修饰名（.def 文件不采用修饰名）。

解释输出

如果符号无法解析，通过下列指南可获得有关函数的信息：

在 x86 平台上，用 C 编译的名称或 C++ 中的 extern "C" 名称的调用约定修饰是：

__cdecl

函数具有下划线 (_) 前缀。

__stdcall

函数具有下划线 (_) 前缀和 @ 后缀，后跟堆栈上参数的双倍字长对齐大小。

__fastcall

函数具有 @ 前缀和 @ 后缀，后跟堆栈上参数的双倍字长对齐大小。

使用 undname.exe 获取修饰名的未修饰格式。

有关上面列出的某些原因的更多信息，请参见名称修饰。

---