語言在圖書館留下了什麼「標記」，我們需要語言綁定？

Question

如果我們從不同的語言調用它的函數，語言在編譯的庫上留下了什麼標記，我們需要語言綁定？

對象代碼對我來說看起來'沒有語言'。

在Linux環境中學習c語言中的OpenGL時，我有跨語言綁定。

Answer 1

遠低於標籤，所有你需要做的就是想調用C和C++約定的無數。爲了防止嚴重的意外事故，編譯器根據調用約定對函數名稱進行了修改，以便您不會意外地使用fastcall約定調用stdcall函數。每種語言都有自己的一套多餘的細節，像這樣一種獨立於語言的API應該永遠不會讓自己負擔得起。語言綁定作爲一種適配器/橋樑，將語言特定的東西與標準化的API分離開來，在必要時填補空白。

OpenGL API通常以單一語言（C）實現，用其他語言編寫的程序通過語言綁定與系統實現接口。 OpenGL爲GLSL使用以空字符結尾的ASCII字符串，並且具有許多使用指針的函數，這些函數對於設計爲用C實現的API來說非常合適。在Java中，字符串不是以null結尾的，並且它們是UTF-16編碼的;你可以看到爲什麼需要一座橋。 Java GL綁定負責字符串轉換，並改變類似於Java的條件來「指向」連續的內存塊。

Answer 2

綁定爲應用程序呈現和與數據交互提供了一種簡單而一致的方式。

來源：你的問題

Answer 3

我猜你是年輕人還是沒有編程超過十年左右。

對象代碼應該看起來沒有語言，但它不是由於歷史。早在20世紀70年代和80年代，在Intel 80x86和Motorola 680x0 CPU上，函數調用參數在堆棧上傳遞。在'Pascal'約定中，參數的數量是固定的，被調用的函數代碼在返回之前將它們從堆棧中移除。在'C'約定中，參數的個數是可變的（例如printf），因此當函數返回時，調用代碼必須將其刪除。這樣每個函數調用需要2個額外的字節，這在今天沒有任何意義，但是當PC僅帶有128K左右的RAM時顯着。因此，微軟選擇使用Windows API的Pascal調用約定，即使它是用C語言編寫的。如果您的目標代碼錯誤地使用C約定調用Windows函數kaboom。這就是爲什麼頭文件仍然與WINAPI和_stdcall以及_fastcall和什麼都混雜在一起的原因。

從20世紀90年代開始，操作系統的作者意識到這很愚蠢，並開始在每個人身上施加標準調用約定。 C公約可以處理這兩種情況，所以在任何地方都可以使用。隨着MacOS X，64位Windows和ARM的發展，我們終於得到了無語言的對象代碼。

現在，OpenGL被設計用於C和Fortran。 （這在20世紀90年代仍然是科學計算和可視化的重要語言。）這兩種語言都有整數，浮點數和各種大小的整數/浮點數組成的數組。 C有結構，但Fortran沒有，我懷疑這是OpenGL API從不使用任何結構的主要原因。 C和Fortran之間二維或更高維數組的內存佈局也有所不同，並且再次注意到OpenGL API從不指定二維數組，只有一維。

C API適用於大多數語言。這部分是因爲C是「便攜式彙編程序」，幾乎適用於任何CPU和操作系統。這也是因爲大多數常用的其他編程語言或者是C（C++，Objective-C）的超集，或者是用C本身（Python，Perl，Ruby）實現的，因此可以很容易地調用OpenGL C API。

Java和C＃有更多的問題，因爲它們定義了自己的目標代碼，可以這麼說，並且內存訪問受到更嚴格的控制。 '這裏的C/OpenGL概念是指向一塊內存的指針，按照你喜歡的方式'打破了JVM/CLR的安全模型。所以你最終不得不使用Java NIOByteBuffer而不是僅僅傳遞數組。

它的很多也歸結爲語言綁定設計師的技能。舉個例子，Mike Fletcher的Python-OpenGL是一個非常好的綁定。所有的函數和常量都有完全相同的名稱，所以很多代碼可以從C中複製並粘貼到Python中。 Python沒有直接使用C風格的數組，但是語言綁定會默默地將您以「數組」形式傳遞的任何Python序列/元組轉換爲底層的C語言格式。對於Python程序員來說感覺很自然，並且仍然暴露出OpenGL的全部功能。

對於一個不好的例子，JOGL是一個痛苦的屁股。 Java數組沒有自動轉換爲C，所以你必須自己與NIOByteBuffers混合在一起。這太令人討厭，它實際上更容易使用glBegin..glEnd塊。額外的數組偏移參數被添加到許多OpenGL函數中，所以你的代碼看起來不再像C/C++一樣，並且你在函數調用結束時浪費了大量時間。其中一些原因是由於之前提到的JVM，但其中很多隻是（我懷疑）某個從未真正寫過OpenGL的人的糟糕設計。

對模糊問題的漫長而漫長的回答。