labview是编译型语言还是解释型语言.docxVIP

LabVIEW 是编译型语言还是解释型语言 LabVIEW 和常用的 VC++ 、VB 一样，是编译型语言。 LabVIEW 的语法定义比较严格，在程序运行 之前会检查所有语句的语法，一旦查出有差错，程序会报错，不能运行。 在 LabVIEW 是否是编译型语言的问题上容易引起混淆的原因，一是用户看不到编译时生成的目标文 件（在 LabVIEW 的环境中，可以直接运行一个 VI ，并不生成任何其他可执行文件 ）;二是 LabVIEW 没有 编译这个按钮。此外， VI 运行前似乎也没有占用编译时间。 我们可以把 LabVIEW 和 C 语言的存储与编译方法作一比较： C 语言的原文件存储在 .c 文件中。 需要编译时，要显式地告知编译器进行编译。在耗费一段编译时间后，可以看到编译后生成的含有可执行 二进制代码的 .obj 文件。而 LabVIEW 的原代码是存储在 .vi 文件中的。 一个 .c 文件中通常保存了多个函数，一个由几十个函数构成的 C 语言工程，也许只由两三个 .c 文 件组成。而通常情况下，一个 .vi 文件只存储一个 VI ，即相当于 C 语言中的一个函数。所以，一个小型 LabVIEW 工程也可能由几十个 .vi 文件组成。 但在某些情况下，一个 .vi文件也可能包含了某些子 VI（子函数），即这些子函数没有他们自己的 .vi 文件。这样的子 VI被称为实例 Vl（lnstance VI）。LabVIEW 7版本中出现的、目前很常用的 Express VI就 是这种Instance VI。他们都是被存储在调用他们的 VI中的。 .c 文件只保存程序的原代码 ;而 .vi 文件不仅保存了 LabVIEW 程序的原代码，也保存了程序编译之 后生成的目标代码。在 LabVIEW 的工程中看不到类似 .obj 这样的文件，就是因为编译后的代码也已经 被保存在了 .vi 中的缘故。 LabVIEW 在运行 VI 之前无需编译， 是因为 LabVIEW 在把 VI 装入内存的时候、 以及在编辑 VI 的 同时进行了编译。 当把一个 VI 装入内存时， LabVIEW 先要判断一下这个 VI 是否需要被编译。一般情况下，如果不 对 VI 的代码做改动， 是不需要重新编译的。 但是在两种情况下需要重新编译。 第一种，是在高版本 LabVIEW 中打开一个用低版本 LabVIEW 保存的 VI; 第二种，是在不同的操作系统下装入和打开了同一个 VI 。 比如，要在 LabVIEW 8.0 中打开一个原来用 LabVIEW 7.0 编写保存的 VI ，则被装入的 VI 需要被 重新编译，因为不同版本的 LabVIEW 生成的目标代码会稍有不同。如果你的工程包含有上百个 VI ，在 新版本的 LabVIEW 中打开顶层 VI ，就会明显地察觉到编译所占用的时间。 第二种情况的例子是， 在 Linux 中打开一个原来是在 Windows XP 下编写保存的 VI ， LabVIEW 也需要重新编译。 LabVIEW 为不同操作 系统生成的目标代码也是不同的。 在以上两种情况下，打开一个 VI 后，会发现 VI 窗口的标题栏中的标题后面出现一个星号，这表示 需要重新保存 VI 。此时， 虽然 VI 中的程序原代码没有改变，但是编译生成的目标代码已经变了，所以需 要重新保存。 在 LabVIEW 安装了升级补丁之后 （比如从 8.0升级到 8.01），程序会提示你是否需要把 LabVIEW 自带 的VI全部批量编译（mass compile）。如果你选择 是”则可能需要占用几个小时的时间才能完成编译。 LabVIEW 在你编辑程序原代码的同时，就会对它进行编译。 LabVIEW 只编译你当前正在编辑的这个 VI ，它的子 VI 已经保存有已编译好的目标代码，所以不需要重新编译了。因为每个 .vi 只相当于一个函 数，代码量不会很大，编译速度就相当快，用户基本上是察觉不到的。 你在编写一个 LabVIEW 程序时， 假如你把两个类型不同的接线端联在一起，会看到程序的运行按钮立即断裂，它表示程序已经编译了，并 且编译后的代码不可执行。程序编写完毕，所有 VI 也都已是被编译好了，程序直接运行即可。 有时会出现这种情况：打开一个 VI ， VI 左上方运行按钮上的箭头是断裂的，表示 VI 不能运行。但 是点击断裂的箭头，在错误列表里却没有列出任何错误信息。此时箭头断裂是由于 VI 保存的编译后的代 码不能执行引起的。例如在上一次打开这个 VI 时，有一个被此 VI 调用的 DLL 文件没有找到，编译后 的代码自然不能执行。而后关闭 VI 再把缺失的 DLL 文件放回去。下次打开始 VI 时，理论上 VI 应当 可以运行了，但是这时 LabVIE