语言在我们需要语言绑定的库中留下什么“标记”？

Question

如果我们从不同的语言调用其函数，那么语言会在编译的库中留下什么标记我们需要语言绑定？

对象代码看起来对我来说是“语言免费”。

在Linux环境中学习OpenGL时，我遇到了语言绑定。

Answer 1

  

Binding为应用程序提供了一种简单而一致的方式来呈现数据并与之交互。

来源：您提问的标签

Answer 2

那么，你要做的就是考虑C和C ++中无数的调用约定。为了防止严重的意外，编译器根据调用约定破坏函数名称，这样您就不会意外地使用stdcall约定调用fastcall函数。每种语言都有自己的一组多余的细节，这样一个独立于语言的API永远不会给自己带来负担。语言绑定用作适配器/桥接器，将特定于语言的内容与标准化API分开，在必要时填补空白。

OpenGL API通常用单一语言（C）实现，用其他语言编写的程序通过语言绑定与系统的实现接口。 OpenGL对GLSL使用以null结尾的ASCII字符串，并且有许多使用指针的函数，这些函数对于设计用C实现的API非常有意义。在Java中，字符串不是以null结尾的，它们是UTF-16编码的;你可以看到为什么需要一座桥梁。 Java GL绑定负责字符串转换并改变glVertexPointer (...) - 类似函数，以适应Java“指向”连续内存块的条件。

Answer 3

我猜你是年轻人还是已经十多年没有编程了。

对象代码应该看起来没有语言，但它不是由历史引起的。早在20世纪70年代和80年代，在Intel 80x86和Motorola 680x0 CPU上，函数调用参数就在堆栈上传递。在'Pascal'约定中，参数的数量是固定的，被调用的函数代码在返回之前将它们从堆栈中删除。在'C'约定中，参数的数量是可变的（例如printf），因此调用代码必须在函数返回时删除它们。每个函数调用需要2个额外的字节，这在今天什么都没有，但当PC只有大约128K的RAM时，这个数字很大。所以微软选择使用Pascal调用约定用于Windows API，即使它是用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之间的2D或更高维数组的内存布局也存在差异，并且再次注意OpenGL API从不指定2D数组，只有1D。

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的人。

对一个含糊的问题做出漫长而漫无边际的回答。