Design: ¿Cuándo deberíamos necesitar un código de pegamento?

¿Qué código de pegamento? Parece que ha copiado aquí dos funciones ( addThree() y adder() ) de algunos tutoriales de Wasm, ¿tal vez? Parecen ser simplemente funciones de ejemplo que realmente no hacen mucho, y simplemente sirven para demostrar un tutorial sencillo de Wasm. Ninguna de estas funciones tiene una firma compleja y debería poder llamarse sin ningún código de pegamento.

Pero ese no es mi punto. De algunos documentos, se explica así:

A largo plazo, wasm con objetos escritos y GC podría ayudar. ¿Es eso lo que se quiere decir aquí?
De lo contrario, no estoy seguro de cómo se puede eliminar ese código de pegamento a corto o medio plazo. Se necesita mucho trabajo para formar un shell alrededor de las cosas C / C ++ que las hacen parecer una cosa JS. Por ejemplo, el código de pegamento debe contener métodos para convertir una cadena C en una cadena JS y viceversa. A nivel C ++, admitir la extensión de una clase C ++ en JS e implementar métodos virtuales en JS requiere bastante piratería. Y, en general, se necesitará mucho pegamento para acceder a las API web desde wasm a través de JS.

y otros:

Emscripten requiere una gran variedad de código JavaScript "pegamento" para manejar la asignación de memoria, las pérdidas de memoria y una serie de otros problemas, que ya están incluidos en la plantilla proporcionada. Es más fácil usar eso que tener que escribirlo todo tú mismo.

Cuando me encuentro con un código simplemente C / C ++, puedo usar wasm fácilmente compilándolo y export.xxxFn() .

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

y cuando uso código que usa Buffer, prefiero usar código de pegamento.

# 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));
...

Entonces, ¿podría concluir que cuando transfiero Buffer a WASM, necesito un código adhesivo para manejar la asignación de memoria, las pérdidas de memoria y una serie de otros problemas?

El código de pegamento descrito en el comentario anterior es el cargador de JavaScript que genera Emscripten. Hace exactamente lo que dice el comentario: convierte entre representaciones de datos JS y C ++ (por ejemplo, cadenas) y entre diferentes representaciones de objetos (es decir, crea objetos proxy JS para objetos C ++). También crea las matrices escritas que se necesitan.

Como habrá notado, puede prescindir del cargador Emscripten para casos simples como las dos funciones que ha utilizado como ejemplos. Ninguno de ellos requiere ningún código de pegamento complejo: cada uno simplemente necesita un archivo JS para cargar el archivo Wasm (y en el segundo ejemplo, el archivo wasm de addThree también necesitará que se cree Uint8Array).

Finalmente, la asignación de memoria es manejada por el código Wasm, que debería incluir una copia de malloc de musl (aunque Emscripten todavía incluye su malloc en realidad, en lugar de usar el de musl). Las pérdidas de memoria se evitan de la manera estándar simplemente liberando memoria en su código C / C ++ una vez que haya terminado con él, no hay nada especial que Wasm requiera aquí.

En última instancia, solo necesita el código de pegamento que realmente usará, en función de las llamadas transfronterizas que realiza su código (de JS a C ++ y de C ++ a JS).

Este problema podría resolverse, es una pregunta sobre Emscripten en lugar de un error en el diseño de WebAssembly en sí.

muchas gracias