embind and raw pointers to primitive types

[Tyler Daniel]

Hi all,

So for my first adventure with emscripten I thought I'd start simple -- modify an existing bit of JS to call a c++ function to process an ArrayBuffer.

Oops.

Many hours later I think I understand the options with ccall/cwrap and embind.  I have a working bit of code now which looks something like:

typedef int intPtr_t;

val processData(intPtr_t sourceBytes_, int byteLength)
{
 const uint8_t *sourceBytes = reinterpret_cast<const uint8_t*>(sourceBytes_);
 ...
}

It's hacky, but it works, but .. it's hacky.

The "intPtr_t" typedef is there to get around embind's inability to handle raw pointers to primitives.

Is this seriously recommended practice?  We have memory_view's to represent blocks of heap memory that can be returned to JS, but there seems to be no good solution going the other way from JS to c++.  Am I totally missing something?  

Maybe supporting std::array<> would make sense, like the existing support for std::string?

Our goal is to write a small library in c++ that can be compiled for both browsers/JS and native code.  The above solution works, but it's embind-specific and implies wrapping certain APIs specifically for embind, which is of course error-prone and generally not fun.

Any suggestions would be most appreciated!

[Floh]

I haven't used embind yet, but if you just want to pass a typed array as C array you don't actually need embind, just an 'exported' C function.

On the C/C++ side it's a normal C function (inside an extern "C" { } block so that the function name isn't mangled) taking pointer arguments, 

https://github.com/floooh/yakc/blob/6258e809c9f90cfa6e96bd57ad0a16eb0915e1d1/src/yakcapp/Main.cc#L480

...and on the JS side the usual Module.ccall with an 'array' typehint:

https://github.com/floooh/yakc/blob/6258e809c9f90cfa6e96bd57ad0a16eb0915e1d1/web/emsc.js#L141

For general interaction I'm planning to use this extern "C" { } with a small set of C interface functions instead of trying to move C++ data types back and forth (which IMHO just makes things more complicated).

Cheers,

-Floh.

[Tyler Daniel]

Hi, thanks for your reply.

Yes, that's the ccall API.  I would prefer to avoid ccall because specifying function names on the command line is cumbersome and error prone.  The need to declare functions with C linkage is also limiting and just doesn't integrate well with c++ code.

I assumed that embind was created to solve these problems, but providing no way to handle my [common] example seems like a major oversight.

 

[Floh]

I agree that the need to list exported functions on the linker command line is a bit cumbersome since the problem leaks into the build system, I would prefer something like a EM_EXPORT macro which could be put in front of C functions.

Other then that I'm basically fine with the ability to define a C function interface, it's quite common for FFI's in other languages also only support C and not C++ for the simpler linking model.

Btw, did you see the documentation section about raw pointers (https://kripken.github.io/emscripten-site/docs/porting/connecting_cpp_and_javascript/embind.html#raw-pointers)? Not sure if this would fix your problem though.

-Floh.

[Alon Zakai]

> I agree that the need to list exported functions on the linker command line is a bit cumbersome since the problem leaks into the build system, I would prefer something like a EM_EXPORT macro which could be put in front of C functions.

The EMSCRIPTEN_KEEPALIVE macro in emscripten.h does that, it both keeps the function from being eliminated as dead code, and exports it. Perhaps the name could be better, we could add an EMSCRIPTEN_EXPORT alias?

https://kripken.github.io/emscripten-site/docs/api_reference/emscripten.h.html#c.EMSCRIPTEN_KEEPALIVE

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Floh]

Oh nice, I wasn't aware of that. If it is a simple fix, adding an EMSCRIPTEN_EXPORT alias might help to raise awareness IMHO :)

And looking at the docs, maybe a mention near the EXPORTED_FUNCTIONS section would be good (here: https://kripken.github.io/emscripten-site/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html?highlight=exported_functions#calling-compiled-c-functions-from-javascript-using-ccall-cwrap), there is a small code sample right below that section which has 2x EMSCRIPTEN_KEEPALIVE, but without explaining anywhere else on that page what it does, and it's easy to miss.

Cheers,

-Floh.

[Alon Zakai]

Makes sense, here's a PR with that: https://github.com/kripken/emscripten/pull/4977