1. 到底哪個更好：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 64/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語言好，您就回答一切皆有可能。 這也許是將問題朝著正確的方向引導的唯一途徑了。