“為什么LabVIEW優于C語言？” 作為LabVIEW產品經理，我被很多次問到這個問題。

老實說，這么提問實際上是錯誤的。必須要有具體的應用環境，這么提問才有意義（例如，“在這些限制條件下，哪一種語言更適合這個任務？”） 若沒有這些細節，這個問題就像為什么面包比面粉好一般無意義。

如果您想創建一個測控系統，不同于C語言等低級語言，使用NI LabVIEW系統設計軟件能夠幫助您降低風險、節省開支并免除不必要的麻煩。在這里我并非暗示LabVIEW是比C語言“更好”的編程語言——特別是考慮到LabVIEW大部分內容不僅僅由G語言編寫，還由C和C++語言組成。 恰恰相反，這兩種語言各自具有不同的優勢，程序員應合理擇取才能達到自己的目的。

為什么要把LabVIEW比作面包？ 請繼續閱讀

LabVIEW和C語言相比起來就好比面包和面粉的關系。 如果您想做一個三明治，就必須先選用面包。 如果您想做一個蛋糕，先用的自然是面粉。 如果用面粉從頭烘烤面包，即昂貴又費時（尤其是當你只想吃些小點心時），但若做的是蛋糕，面粉就必不可少了。 同樣的，你會發現，要選擇最適合的編程語言并非易事，它歸結為使用正確的工具來完成適合的工作。

C語言提供了低級別的控制

當應用資源有限，必須嚴格管理時，C語言的使用效果更好。 由于C語言是相對低級別的語言，因此，即便是最細微的細節，如內存分配和線程，都必須考慮周全。優秀的程序員能夠使用低級別的控制，省去大部分高級別應用帶來的間接開銷。此外，還能充分利用目標體系構架或主機操作系統屬性，實現更高的性能。

正是由于上述原因，NI程序員使用C或C++編寫了LabVIEW庫中的大部分內容。LabVIEW與C語言在文件I/O和分析等操作的運行速度上旗鼓相當，因為這些操作都是基于低級語言編寫的，并對LabVIEW支持的不同平臺和操作系統進行了優化。

效率Vs控制

有時，若開發人員的效率足夠高的話，就無需手動優化代碼了。 減少一點控制，借鑒類似問題的解決方案，可極大地促進項目的高質量開發。 編程語言不斷朝更高級抽象方向發展，讓您更專注于手頭的問題，而不是被計算細節所困擾。         

LabVIEW: 并行執行和真實I/O

無論使用何種語言，高級系統設計與低級執行都是獨立的。

在測控應用中，編程只是系統設計者的任務之一。 工程師很少有時間為了計算和測量硬件，或是操作系統上的改進，去更新或重寫舊版本軟件。 他們通過獲取、處理和呈現真實數據進行改進——而不是去挖掘新方法處理內存分配和線程池。 使用LabVIEW，您可以使用經測試、支持、維護的NI底層代碼庫來創建應用。 而選擇C語言意味著您需要實現、支持和維護自己的底層庫，或從供應商處購買（NI提供NI LabWindows ™/CVI 軟件與NI Measurement Studio）

從語法角度來說，C語言指令連續執行的能力非常強，CPU能以最快的速度處理它們。 對于純粹的數據計算，在執行單一任務且指令相對基本的情況下，C語言非常適用。 而LabVIEW采用的是圖形化語法，更適用于有真實時間約束的并行執行任務。

使用LabVIEW，您可以跳過基礎構建的步驟，直接進行自定制。

LabVIEW不僅僅是一種編程語言及相關的代碼庫。 結合使用LabVIEW集成開發環境（IDE）與NI硬件，由此所帶來的開發體驗是各個部分的總和無法企及的。LabVIEW可以準確識別可用的硬件資源，并以下拉菜單和項目名稱顯示可用的I/O通道與執行目標。 在編輯過程中，您可以防止或察覺錯誤的配置，以避免代價高昂、又難以調試的運行時錯誤。 新一代測量硬件（如NI PXIe-5644R矢量信號收發器）甚至可以允許LabVIEW對其固件進行重新定義，達到傳統、不同的編程語言和儀器無法實現的性能水平。

有很多項目都會延期或超預算完成，主要是因為工程師低估了聚集所有資源所需的開銷。 若您使用LabVIEW，硬件驅動程序會以與數據分析庫相同的格式返回數據，UI小部件則以相同的格式顯示技術數據，無需再拼湊不同組件。

到底哪個更好: LabVIEW還是C語言？  

這個問題的最佳答案是：“一切皆有可能。” 正如《銀河系漫游指南》中所說的， 除非您明確自己的問題或了解正試圖解決的問題，否則得到的答案也是無意義的。 對于熟練的用戶來說，LabVIEW和C都是非常有用的工具，幾乎可以解決任何問題：LabVIEW適用于高級測試、測量和控制應用，而C更容易實現低級計算密集型任務。

若再有人問起LabVIEW好還是C語言好，您就回答一切皆有可能。 這也許是將問題朝著正確的方向引導的唯一途徑了。

進一步了解LabVIEW與NI集成開發環境，請訪問ni.com/labview/zhs。