То, как действительно кодирует записанный на одном языке, называют с другого языка

Обычно код C ++ вызывает интерпретатор для языка сценариев. Степень взаимодействия между скомпилированным кодом и кодом сценария зависит от интерпретатора, но всегда есть способ передать данные между ними. В зависимости от интерпретатора может быть возможно манипулировать объектами на одной стороне с другой стороны, например, функция C ++, вызывающая метод объекта Ruby. Может быть даже способ контролировать выполнение одного из другого.

Существует протокол, по которому модули взаимодействуют. Вот общий обзор того, как это работает:

1. Библиотека создается для кода, которым вы хотите «поделиться». Их обычно называют DLL или SO, в зависимости от вашей платформы.
2. Каждая функция, которую вы хотите предоставить (точка входа), будет доступна для привязки к внешнему миру. Существуют протоколы привязки, такие как соглашение о вызовах, в котором указывается порядок передачи параметров, кто очищает стек, сколько параметров сохраняется в регистрах и какие и т. Д. См. Cdecl, stdcall и т. Д. Для примеров вызова. соглашения здесь .
3. Вызывающий модуль будет статически или динамически связываться с разделяемой библиотекой.
4. После того, как ваша вызывающая библиотека привязана к общей библиотеке, она может указать, что она хочет привязаться к определенной точке входа. Обычно это делается по имени, однако большинство платформ также предлагают возможность привязки по индексу (быстрее, но более хрупко, если ваш модуль изменяется и точки входа переупорядочиваются).
5. Вы также обычно объявляете функцию, которую хотите вызвать, в где-то в вашем модуле, чтобы ваш язык мог выполнять статическую проверку типов, знал, что такое соглашение о вызовах и т. д.

Для вашего сценария вызова Scheme из C ++ интерпретатор Scheme, скорее всего, экспортирует функцию, которая динамически связывается с функцией / объектом Scheme и называет это. Если модуль Scheme скомпилирован, он, вероятно, имеет возможность экспортировать точку входа, чтобы ваш модуль C ++ мог привязаться к ней.

Вы также можете интегрировать две среды без необходимости компилировать библиотеку интерпретатора внутри исполняемого файла. Вы храните exe и Scheme exe как отдельные программы в вашей системе. Из основного исполняемого файла вы можете записать код схемы в файл, а затем использовать system () или exec () для запуска интерпретатора схемы. Затем вы анализируете вывод интерпретатора схемы.

Предложенный выше подход разделяет exes, и вам не нужно беспокоиться о зависимостях третьих сторон, они могут быть значительными. Также проблемы остаются в том или ином exe.

Если запуск отдельного exe не удовлетворяет ваши требования к производительности, вы можете разработать протокол, в котором интерпретатор схемы становится сервером. Вам нужно написать некоторые функции схемы, которые ждут ввода в сокет или файл, eval этот ввод затем выводит результат в тот же сокет или другой файл. Другая итерация этого - рассмотрение существующих серверов, на которых может уже быть запущен ваш интерпретатор, например, в apache есть модули, позволяющие писать код на многих языках.

Если вы действительно ищете инструменты для этого, а-ля Адам, см. swig .

Прошло около десяти лет, но я сделал именно это для своего старшего замкового камня (ну, я построил нейронную сеть с обратным распространением на C и использовал программу-схему для обучения этому). Версия Scheme, которую я использовал, имела компилятор, а также интерпретатор, и я смог создать ее как файл .o. Я не знаю, какую версию схемы я использовал, но похоже, что RScheme превратит код вашей схемы в C.

С теоретической точки зрения, когда программе A нужно использовать ресурсы (класс / функции / и т. Д.) Из программы B, речь идет о передаче некоторой информации от A к B и получении некоторой информации назад или какие-то действия выполнены. Таким образом, B должен быть способ, позволяющий A передавать информацию и получать результат.

На практике управление этим процессом обычно лежит на плечах языков: язык B (на котором написана программа B) сгенерирует протокол и сделает ресурсы в B доступными предопределенным способом, затем язык A (программа A написано в) предоставит некоторую утилиту / структуру, чтобы помочь вызвать открытые ресурсы и получить результаты в соответствии с протоколом B.

Чтобы быть более конкретным по вашему вопросу, для интерпретируемых языков процесс довольно универсален, протокол обычно находится среди строк параметра командной строки, HTTP-запроса и других способов передачи обычного текста. Возьмем первый пример, программа B получит вызов из HTTP-запроса в качестве входных данных, а затем обработает запрос оттуда. Фактический формат ввода полностью определяется программой B.

Такие вещи, как SOAP и т. Д., Являются всего лишь способом регулирования программ для ввода ввода в соответствии с общепринятым стандартом.