我在 LabVIEW仪器驱动指南（第 6.2 节）中找到了这条评论：
如果您需要比推荐模式更多的终端，请重新考虑 VI 上的控件和显示控件的分组。除错误输入和错误输出外，避免使用集群以尽量减少终端数量。集群通常需要用户从集群中解绑和重新绑定数据。
如果 National Instruments 不鼓励集群，那么“重新考虑 VI 上的控件和指示器的分组”是什么意思？
我真的很喜欢使用集群，而且我认为它们改进了我的 VI。我错过了什么吗？
Don Kirkby
问问题
5141 次
4 回答
10
我认为这可能是 NI 文档中的措辞不佳。如果一次向仪器或其驱动程序写入或读取许多不同的值是有意义的，那么集群是合适的数据类型。您想尝试避免用户必须将集群中的数据读取出来，以便他们可以在更改一个值的情况下将其写回的情况。使用集群的其他好的一般原则，当然是在可分发/可重用的代码中，如仪器驱动程序，是：
- 将集群保存为严格的 typedef
- 始终按名称捆绑/取消捆绑集群元素。
这样您就可以在不破坏现有代码的情况下更改集群中的内容。
于 2009-02-17T17:41:44.880 回答
7
捆绑和拆分是相对微不足道的处理器和内存命中，因此除非您在紧密循环中工作，否则不必担心性能。
但是，当连线板开始看起来像杂色豪猪时，许多人会开始将所有内容放入“巨型集群”输入中。虽然这确实有效（有一段时间），但它最终会导致大量不必要的内存膨胀和调试痛苦，因为函数中不需要的东西仍然会在代码中复制。
更糟糕的是，最终可能会为不同的 VI 提供不同的巨型集群，然后需要在结构之间进行转换。
我通常觉得最好是，当输入和输出开始变得过多时，返回并将一个 VI 重构为多个，每个 VI 都有一个更小、定义更明确的函数。
于 2009-02-17T01:16:58.163 回答
4
集群作为一种数据类型很好。NI 不鼓励将数据捆绑到集群中，其唯一目的是将数据传递给 sub-vi。如果您有必须在众多 vis（或 sub-vis）之间共享的数据，那么您应该考虑使用功能全局，或更改您的架构以规范化您的数据。
于 2009-02-16T22:57:09.077 回答
1
正如错误输入和错误输出集群在逻辑上对数据进行分组并允许分层 VI 参数一样，我认为集群的使用也应该遵循这个模型。我同意，应该避免“大型集群”。就个人而言，作为一名前 C++ 开发人员，我不喜欢全局变量（尽管在某些情况下它们是不可避免的）。我写了很多显式的多线程LabVIEW代码，通过消息队列进行线程间通信。（我想这是我的 Windows 开发人员时代的遗产。）如果没有集群或类型定义，消息传递几乎是不可能的。当然，我肯定会使用集群来减少终端上的引脚数量。我认为这没有问题，只要它不过分并且合乎逻辑。
于 2015-11-24T17:34:49.010 回答