Может конкретный пример поможет.Давайте возьмем язык хоста как Python и язык гостя как C. Это означает, что Python будет вызывать функции C.
Первый вариант - написать библиотеку C определенным образом.,В случае Python стандартным способом было бы написать функцию C с первым параметром Py_Object * среди других условий.Например ( отсюда ):
static PyObject *
spam_system(PyObject *self, PyObject *args)
{
const char *command;
int sts;
if (!PyArg_ParseTuple(args, "s", &command))
return NULL;
sts = system(command);
return Py_BuildValue("i", sts);
}
- это функция C, вызываемая из Python.Чтобы это работало, библиотека должна быть написана с учетом совместимости с Python.
Если вы хотите использовать уже существующую библиотеку C, вам нужен другой вариант.Одним из них является наличие инструмента, который генерирует обертки этой существующей библиотеки в формате, подходящем для использования языком хоста.Возьмите Swig , который можно использовать для связи многих языков.Имея существующую библиотеку C, вы можете использовать swig для эффективной генерации кода C, который вызывает вашу существующую библиотеку, в соответствии с соглашениями Python.См. пример для создания модуля Python.
Другой вариант для нас, уже существующей библиотеки C, состоит в том, чтобы вызывать ее из библиотеки Python, которая эффективно упаковывает вызовы ввремя выполнения, например ctypes .Хотя в варианте 2 компиляция была необходима, это не время.
Другое дело, что существует множество опций (которые перекрываются) для вызова функций на одном языке из другого языка,Существуют FFI (эквивалентные языковым привязкам, насколько мне известно), которые обычно относятся к вызовам между несколькими языками в одном и том же процессе (как часть одного и того же исполняемого файла, так сказать), и существует межпроцессное взаимодействиесредства (локальные и сетевые).Такие вещи, как CORBA и веб-службы (SOAP или REST), а также COM + и удаленные вызовы процедур в целом относятся ко второй категории и не рассматриваются как FFI.На самом деле, они в основном не предписывают какой-либо конкретный язык, который будет использоваться с обеих сторон общения.Я бы свободно назвал их опциями IPC (межпроцессное взаимодействие), хотя в случае сетевых APi, таких как CORBA и SOAP, это упрощение.
Имея возможность ознакомиться с вашим списком, я бы рискнул высказать следующие мнения:
- Архитектура брокера запросов общего объекта: IPC, а не FFI
- Вызов C в C ++ с помощью объявления
extern "C" в C ++ для отключения искажения имен.**** - Вызов C в Matlab через интерфейс MATLAB для общих библиотек Вариант 3 (в стиле ctypes)
- Вызов C в Matlab путем создания C / C ++Языковые MEX-файлы Вариант 2 (аналогично swig)
- Вызов Matlab в C, компилятором mcc Вариант 2 (аналогично swig)
- Вызов C ++ в Java с помощью JNI и Вызов Java в C ++ с помощью JNI Вариант 3 (в стиле ctypes)
- Вызов C / C ++ на других языках, Использование SWIG Вариант 2 (swig)
- Вызов C в Python, Ctypes Вариант 3 (ctypes)
- Cython Вариант 2 (swig-like)
- Вызов R в Python, RPy Вариант 3 (ctypes-подобный) частично и частично об обмене данными (не FFI)
Следующие дване интерфейсы сторонних функций вообще, как термин используется.FFi касается взаимодействия между языками программирования и должен быть способен сделать любую библиотеку (с подходящими ограничениями) из одного языка доступной для другого.Отдельная библиотека, доступная на одном языке, не делает FFI.
- Привязки к языку программирования для OpenGL из разных языков
- Привязки для библиотеки C из разных языков