Как я могу включить модуль WebAssembly из файла C ++? - PullRequest
0 голосов
/ 14 ноября 2018

WebAssembly - это бинарный язык, который намерен, помимо прочих целей, разрушить барьеры между языками программирования.

В настоящее время достаточно просто скомпилировать код C ++ в WebAsm и включить его вКод JavaScriptЕсть даже предложение и Webpack polyfill , чтобы сделать его так же просто, как import { foo } from 'bar.wasm'.

Более того, WebAssembly поддерживает файлы wasm, которые перечисляют свои собственные зависимости, вформа деклараций импорта.

Существует ли какой-либо инструмент для сборки polyfill, который позволяет пользователям включать модуль webasm в модуль компиляции C ++ в процессе его компиляции в wasm?Например, допустим, у меня есть модуль Rust, который я хочу использовать внутри модуля C ++, оба из которых я компилирую в wasm.Есть ли способ написать код, эквивалентный этому:

#include "node_modules/some_rust_utility/index.wasm"

int someCppFunction(const std::string& data) {
  return some_rust_utility::foobar(data.c_str());
}

и скомпилировать его или нет, в зависимости от того, определен ли foobar с совпадающим типом в some_rust_utility?


Примечание: я ожидаю, что ответ на этот вопрос может со временем измениться, когда появится поддержка WebAssembly.Если вы видите этот вопрос спустя годы и ответ изменился, не стесняйтесь добавлять обновление.

1 Ответ

0 голосов
/ 22 апреля 2019

В настоящее время это невозможно.

Ситуация может измениться в какой-то момент (именно поэтому я не отмечаю этот вопрос как решенный), но до сих пор стандарт не поддерживает совместимость типа «сделай, чтобы есть»:

Поскольку спецификация WebAssembly не определяет способ интерпретации имен импорта [...], среда хоста может интерпретировать имя модуля как путь к файлу, URL, ключ в фиксированном наборе встроенных модулей или среда хоста могут вызовите пользовательский хук, чтобы разрешить имя модуля одному из них;

(например, это определяется реализацией)

Насколько я знаю, в настоящее время модуль wasm не может напрямую импортировать из другого модуля wasm, вместо этого он должен использовать JavaScript в качестве посредника.

Да, модуль переносит это на устройство для внедрения (обычно JS). Что касается модуля, он просто знает, что что-то обеспечивает импорт, но не знает, откуда он пришел.

Для Wasm не стоит задача гарантировать бесперебойное взаимодействие между несколькими языками или даже несколькими компиляторами одного языка (будь то с памятью или GC). Это соответствует его низкоуровневому подходу и очень осознанному решению: такое универсальное взаимодействие часто обещалось, но никогда не получалось хорошо на практике. Языки слишком разные.

Если несколько компиляторов или языков хотят иметь возможность взаимодействия, то они, конечно, могут свободно определять общий ABI поверх Wasm. Это было бы прекрасно! Но самому Wasm его не нужно прописывать, не больше, чем архитектуре ЦП.

Учитывая приведенный выше комментарий, представляется вероятным, что совместимость языков останется низким приоритетом для участников wasm в ближайшем будущем.

...