來源：機器視覺算法與應(yīng)用

大多數(shù)HALCON解決方案都必須嵌入到PC端的應(yīng)用程序中（例如，提供圖形用戶界面），然后大多數(shù)機器視覺應(yīng)用程序使用C ++或C＃實現(xiàn)。這是我們的視角，對您的下一個HALCON項目應(yīng)使用哪種編程語言提供參考

不易的選擇選擇編程語言是并不容易，各有優(yōu)劣和學習成本。很難在單個博客文章中對其進行詳細說明。我們將盡力強調(diào)C ++和C＃之間的一些差異-評估和決定必須由公司或其HALCON開發(fā)人員來執(zhí)行。

有些文章說編程語言不重要，從原理上看，編程語言都類似，對一門編程語言掌握透徹后，其他編程語言可以觸類旁通。從另外一個角度，不同的編程語言應(yīng)用領(lǐng)域不同，編程語言相關(guān)的庫，框架，各種工具（編譯器，調(diào)試工具，測試工具等），易維護程度，招聘相關(guān)開發(fā)人員難易程度及質(zhì)量等等，導致在集成Halcon解決方案時，不同編程語言之間有些許差異

開發(fā)經(jīng)驗如果您或您的HALCON視覺應(yīng)用程序開發(fā)人員僅精通其中一種語言，則對于選擇該編程語言來說，這是非常重要的論據(jù)。您需要充分的理由（可能是以下原因之一）才能更改為另一種語言。

對HALCON的支持HALCON支持通過HALCON / C ++和HALCON / .NET接口集成到C ++和C＃的應(yīng)用程序中。在大多數(shù)情況下，HALCON腳本的性能將相似。

垃圾收集器/確定性銷毀（RAII）C++具有RAII模式和具有超出范圍的對象的確定行為 。因此，我們可以從C ++語言中保證，每個分配的HImage（例如在圖像采集循環(huán)中）之后都會自動釋放，并且不會發(fā)生內(nèi)存泄漏。在C＃中，通常很難實現(xiàn)這種可靠性，并且經(jīng)常需要手動處理和需要額外的處理出錯的工作，例如，手動調(diào)用內(nèi)存清理函數(shù)myImage.Destroy（）或GCHandle.Free（）。但是，如果出現(xiàn)異常或在循環(huán)或函數(shù)過程中（continue，return）起作用， C#中手動編寫的內(nèi)存清理函數(shù)調(diào)用時很容易被跳過。此外，通常不可能確保垃圾回收器不會在應(yīng)用程序的性能特別關(guān)鍵的部分運行。

托管與本地本機代碼是由C ++編譯器生成的目標CPU的機器代碼。它將進行高度優(yōu)化，但是在編譯過程中此優(yōu)化需要一些時間。因此，C ++程序往往會增加構(gòu)建時間，但最終應(yīng)用程序的啟動時間卻很快，尤其是處理速度更快。

相反，C＃程序僅編譯為中間字節(jié)碼。這可以在構(gòu)建過程中相對快速地完成，但是代碼的優(yōu)化不會像使用良好的C ++編譯器所能實現(xiàn)的那樣優(yōu)化。最終在運行時生成的機器代碼將取決于目標系統(tǒng)，因此無法在開發(fā)人員的機器上進行分析。

作為現(xiàn)代C++編譯器可以實現(xiàn)的 優(yōu)化功能 一個例子，使用下面的簡單C++片段計算整數(shù)中的已置位的位數(shù)：

int count_bits_1（int a） {

int count = 0;

while （a） {

count++;

a &= （a-1）;

}

return count;

}

此代碼編譯為

count_bits_1（int）： # @count_bits_1（int）

popcnt eax， edi

ret

使用Gcc編譯器，很容易看到生成的機器代碼/匯編代碼，例如使用編譯器資源管理器。C++編譯器的優(yōu)化步驟了解底層算法并將其轉(zhuǎn)換為英特爾x86/x64 CPU的一個優(yōu)化的POCPNT指令。

Windows在開發(fā)C#代碼時，他將Windows作為唯一的操作系統(tǒng)，盡管通過使用Mono項目，其他目標系統(tǒng)也可能以有限的形式運行（例如沒有WPF）。C++代碼可以非常便攜，然后在許多不同的系統(tǒng)上運行，例如使用QT跨平臺應(yīng)用程序框架和WIDGET工具包。

HALCON擴展包，圖像采集接口，數(shù)字I / O接口如果HALCON / HDevelop中缺少某些功能（某些硬件接口，客戶特定的圖像采集等），則可以通過自定義擴展包，圖像獲取接口或數(shù)字I / O接口來提供。這些只能用C或C ++語言編寫。

外部庫/開源庫許多外部庫使用 C或C ++ 編程語言：可以為C / C ++庫編寫C＃封裝接口，但是為C＃庫編寫C ++封裝接口并不常見。這些用于C ++庫的C＃接口與C++最新版本有些延后：例如，OpenCV 4.5.2于2021年4月發(fā)布，但直到2021年7月，相應(yīng)的.NET-Wrapper Emgu.CV僅可用于OpenCV 4.5.2。

封裝接口通常使用起來更復雜，因為它們必須將C ++結(jié)構(gòu)映射到C＃上，但并不總是100％適合：例如，HALCON庫是用C開發(fā)的，并且具有C＃封裝器（HALCON / .NET）。在C＃中，訪問圖像矩陣很復雜：

GCHandle gch = GCHandle.Alloc（color_image）;

image.GetImagePointer3（out pr， out pg， out pb， out type， out width， out height）;

byte［］ red_managed= new byte［width*height］;

Marshal.Copy（pr， red_managed， 0， width*height）;

// 。。。

gch.Free（）;

大多數(shù)Windows內(nèi)部庫本身都是用C / C ++開發(fā)的，因此.NET框架只是這些庫的封裝。

硬件驅(qū)動某些開發(fā)僅在C或C ++中可行，例如硬件驅(qū)動程序。如果以后需要進行這類工作并且公司中僅熟悉C＃知識，則必須熟悉必要的C ++知識。

調(diào)試使用C＃，有時在Visual Studio中進行調(diào)試會更容易。

示例：HALCON異常

HImage color_image = color_image_small.ZoomImageSize（4000， 3000， “WRONG”）;

在C＃中拋出的異常信息更有有意義

HalconDotNet.HOperatorException： ‘HALCON error #3147： Wrong interpolation mode in operator zoom_image_size’

但是C ++異常是沒有意義的：

Unhandled exception at 0x00007FFB288F3FB8 in MyApp.exe： Microsoft C++ exception： HalconCpp：：HOperatorException at memory location 0x0000007469EFF718.

示例：查看HALCON元組

c#：

var t = new HTuple（）;

t［0］ = 42;

t［1］ = “string”;

Watch window： Name： t， Value： {［42， “string”］}

在C ++中，就不能直接查看

HTuple t = HTuple（42）.Append（“string”）;

Watch window： Name： t， Value： 《Information not available.。。

另一方面，兩種編程語言都可以使用HALCON變量檢查擴展。

低級代碼使用C ++開發(fā)時，低級代碼通常運行得更快。

示例：顏色轉(zhuǎn)換

有時，必須在GUI框架中使用HALCON彩色圖像。GUI框架通常使用交錯的顏色格式（RGB RGB RGB…），而HALCON則使用每個通道的灰度值塊（RRR…GGG…BBB…）。某些彩色圖像到交錯格式的轉(zhuǎn)換在C ++中花費25毫秒，而在C＃中花費60毫秒。另一方面，通常可以忽略從C ++調(diào)用的HALCON代碼或從C＃調(diào)用的HALCON代碼之間的性能差異。

集成開發(fā)環(huán)境有許多用于C ++的集成開發(fā)環(huán)境（IDE），但對于C＃IDE的選擇卻很少。

—版權(quán)聲明—

僅用于學術(shù)分享，版權(quán)屬于原作者。

若有侵權(quán)，請聯(lián)系微信號刪除或修改！

編輯：jq