Design: когда нам понадобится клеевой код?

Какой клей код? Вы, кажется, скопировали сюда две функции ( addThree() и adder() ) из каких-то руководств по Wasm? Они кажутся просто примерами функций, которые на самом деле мало что делают, а просто служат для демонстрации простого учебника по Wasm. Ни одна из этих функций не имеет сложной подписи и должна быть вызвана без какого-либо связующего кода.

Но это не моя точка зрения. В некоторых документах это объясняется следующим образом:

В долгосрочной перспективе wasm с типизированными объектами и сборщик мусора могут помочь. Это то, что здесь имеется в виду?
В противном случае я не уверен, как можно удалить этот клейкий код в краткосрочной или среднесрочной перспективе. Чтобы сформировать оболочку вокруг вещей C / C ++, которые сделают их похожими на JS, нужно потрудиться. Например, связующий код должен содержать методы для преобразования строки C в строку JS и наоборот. На уровне C ++ поддержка расширения класса C ++ в JS и реализация виртуальных методов в JS требует значительных усилий. И вообще, для доступа к веб-API из wasm через JS потребуется много клея.

и другие:

Emscripten требует большого разнообразия «связующего» кода JavaScript для обработки выделения памяти, утечек памяти и множества других проблем, которые уже включены в предоставленный шаблон. Это проще использовать, чем писать все самостоятельно.

Когда я встречаю простой код C / C ++, я легко могу использовать wasm, скомпилировав его, и export.xxxFn() .

int adder (int a, int b) {
    return a + b;
}

и когда я использую код, который использует Buffer, я предпочитаю использовать клей-код.

# C/C++
int addThree(uint8_t *buf, int len) {
  uint8_t *item;
  uint8_t *end = buf + len;

  for (item = buf; item<end; item++) {
    *item += 3;
  }

  return 0;
}

# deal with buffer in JS
...
let dataHeap = new Uint8Array(Module.HEAPU8.buffer, dataPtr, nDataBytes);
dataHeap.set(new Uint8Array(buffer_pcm.buffer));
...

Итак, я могу сделать вывод, что когда я передаю буфер в WASM, мне нужен связующий код для обработки выделения памяти, утечек памяти и множества других проблем?

Клей-код, описанный в комментарии выше, является загрузчиком JavaScript, который генерирует Emscripten. Он делает именно то, что говорится в комментарии: преобразует между представлениями данных JS и C ++ (например, строками) и между различными представлениями объектов (т.е. создает объекты прокси JS для объектов C ++). Он также создает необходимые типизированные массивы.

Как вы заметили, вы можете обойтись без загрузчика Emscripten для простых случаев, таких как две функции, которые вы использовали в качестве примеров. Ни один из них не требует сложного связующего кода: каждому просто нужен JS-файл для загрузки Wasm-файла (а во втором примере для wasm-файла addThree также потребуется создать Uint8Array).

Наконец, выделение памяти обрабатывается кодом Wasm, который должен включать копию malloc из musl (хотя Emscripten по-прежнему включает его malloc, а не использует musl). Утечки памяти можно избежать стандартным способом, просто освободив память в вашем коде C / C ++ после того, как вы закончите с ним, ничего особенного, что требуется Wasm здесь.

В конечном итоге вам понадобится только связующий код, который вы действительно будете использовать, в зависимости от того, какие трансграничные вызовы делает ваш код (из JS в C ++ и из C ++ в JS).

Эту проблему можно было бы закрыть, это вопрос Emscripten, а не ошибка в самом дизайне WebAssembly.

Спасибо большое