How can I return a JavaScript string from a WebAssembly function?
Can the following module be written in C(++) ?
export function foo() {
return 'Hello World!';
}
Also: Can I pass this to the JS engine to be garbage collected?
How can I return a JavaScript string from a WebAssembly function?
Can the following module be written in C(++) ?
export function foo() {
return 'Hello World!';
}
Also: Can I pass this to the JS engine to be garbage collected?
Given:
mem
, the WebAssembly.Memory
object (from the module exports)p
, the address of the first character of the stringlen
, the length of the string (in bytes),you can read the string using:
let str = (new TextDecoder()).decode(new Uint8Array(mem.buffer, p, len));
This assumes the string is UTF-8 encoded.
I found a hack way just like what we do in the hybird appication way, and it's very easily.
Just inject window.alert
function, and then put it back:
let originAlert = window.alert;
window.alert = function(message) {
renderChart(JSON.parse(message))
};
get_data_from_alert();
window.alert = originAlert;
and the native side, just :
// Import the `window.alert` function from the Web.
#[wasm_bindgen]
extern "C" {
fn alert(s: &str);
}
...
pub fn get_data_from_alert() {
alert(CHART_DATA);
}
you can see in examples my GitHub: https://github.com/phodal/rust-wasm-d3js-sample
There's an easier way to do that. First, you need the instance of your binary:
const module = new WebAssembly.Module(bin);
const memory = new WebAssembly.Memory({ initial: 2 });
const instance = new WebAssembly.Instance(module, { imports: { memory: memory } });
Then, if you run console.log(instance)
, almost at the top of this object you will see function AsciiToString
. Pass your function from C++ that returns string and you will see the output. For this case, check out this library.
Things have changed since the other answers were posted.
Today I would bet on the WebAssembly Interface Types - see below.
Since you asked specifically about C++, see:
nbind - Magical headers that make your C++ library accessible from JavaScript
nbind is a set of headers that make your C++11 library accessible from JavaScript. With a single #include statement, your C++ compiler generates the necessary bindings without any additional tools. Your library is then usable as a Node.js addon or, if compiled to asm.js with Emscripten, directly in web pages without any plugins.
Embind is used to bind C++ functions and classes to JavaScript, so that the compiled code can be used in a natural way by “normal” JavaScript. Embind also supports calling JavaScript classes from C++.
See the following WebAssembly proposals:
The proposal adds a new set of interface types to WebAssembly that describe high-level values (like strings, sequences, records and variants) without committing to a single memory representation or sharing scheme. Interface types can only be used in the interfaces of modules and can only be produced or consumed by declarative interface adapters.
For more info and a great explanation, see:
You can already use it with some experimental features, see:
For a good real world example using yet another approach, see:
libsodium.js - The sodium crypto library compiled to WebAssembly and pure JavaScript using Emscripten, with automatically generated wrappers to make it easy to use in web applications.
See also:
Wasmer is an open-source runtime for executing WebAssembly on the Server. Our mission is make all software universally available. We support running Wasm modules standalone in our runtime, but also can be embedded in multiple languages using our language integrations.
and specifically Wasmer-JS:
Wasmer-JS enables the use of server-side compiled WebAssembly Modules in Node.js and the Browser. The project is set up as mono-repo of multiple JavaScript packages.
There's also some good info in this article on Hacker News.
WebAssembly doesn't natively support a string type, it rather supports
i32
/i64
/f32
/f64
value types as well asi8
/i16
for storage.You can interact with a WebAssembly instance using:
exports
, where from JavaScript you call into WebAssembly, and WebAssembly returns a single value type.imports
where WebAssembly calls into JavaScript, with as many value types as you want (note: the count must be known at Module compilation time, this isn't an array and isn't variadic).Memory.buffer
, which is anArrayBuffer
that can be indexed using (among others)Uint8Array
.It depends on what you want to do, but it seems like accessing the buffer directly is the easiest:
If your module had a
start
function then it got executed at instantiation time. Otherwise you'll likely have an export which you call, e.g.instance.exports.doIt()
.Once that's done, you need to get string size + index in memory, which you would also expose through an export:
You'd then read it out of the buffer:
Note that I'm reading 8-bit values from the buffer, I'm therefore assuming the strings were ASCII. That's what
std::string
would give you (index in memory would be what.c_str()
returns), but to expose something else such as UTF-8 you'd need to use a C++ library supporting UTF-8, and then read UTF-8 yourself from JavaScript, obtain the codepoints, and useString.fromCodePoint
.You could also rely on the string being null-terminated, which I didn't do here.
You could also use the
TextDecoder
API once it's available more widely in browsers by creating anArrayBufferView
into theWebAssembly.Memory
'sbuffer
(which is anArrayBuffer
).If, instead, you're doing something like logging from WebAssembly to JavaScript, then you can expose the
Memory
as above, and then from WebAssembly declare an import which calls JavaScript with size + position. You could instantiate your module as:This has the caveat that if you ever grow the memory (either through JavaScript using
Memory.prototype.grow
, or using thegrow_memory
opcode) then theArrayBuffer
gets neutered and you need to create it anew.On garbage collection:
WebAssembly.Module
/WebAssembly.Instance
/WebAssembly.Memory
are all garbage collected by the JavaScript engine, but that's a pretty big hammer. You likely want to GC strings, and that's currently not possible for objects which live inside aWebAssembly.Memory
. We've discussed adding GC support in the future.