Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

val::operator() with pointer as argument #7084

Closed
isc30 opened this issue Sep 1, 2018 · 4 comments
Closed

val::operator() with pointer as argument #7084

isc30 opened this issue Sep 1, 2018 · 4 comments
Labels

Comments

@isc30
Copy link

@isc30 isc30 commented Sep 1, 2018

I'm trying to avoid the need of JS users calling .delete() on the API by accepting lambdas as actions that work with the objects:

EMSCRIPTEN_BINDINGS()
{
    function("using_x", optional_override([](val action)
    {
        X x; // C++ constructs `x`
        action(x); // JS uses `x`
        // C++ destroys `x`
    }));
}

The idea is to use it like this:

Module.using_x(x => x.something()); // C++ destroys the object internally

I realized that embind is copying the object every time I pass it as a parameter, so I tried passing the ptr to x:

action(&x);

The compiler complains: "Implicitly binding raw pointers is illegal. Specify allow_raw_pointer<arg<?>>"

I see no way of specifying policy in this case.

Is it possible to pass pointers into val::operator()?
How can I achieve managing memory from C++ and calling JS actions like this in an easy way?
Am I wrong in my assumption that this design would help defining the proper ownership of those objects?

Thanks a lot

@isc30 isc30 changed the title val::operator() ptr as argument val::operator() with pointer as argument Sep 1, 2018
@isc30
Copy link
Author

@isc30 isc30 commented Sep 2, 2018

Okay, looks like I found a workaround:

passing an lvalue reference to the pointer instead of the pointer itself

X x;
X* ptr = &x;
action(ptr);

This works as expected, interesting...

@kripken kripken added the embind label Sep 4, 2018
@chadaustin
Copy link
Collaborator

@chadaustin chadaustin commented Nov 28, 2018

That's... scary. I feel like that shouldn't work. :D What happens when JavaScript grabs a long-lived reference to the value and tries to run it later?

This sounds related to #7292 to me. cc @mejedi

@isc30
Copy link
Author

@isc30 isc30 commented Nov 28, 2018

Well, that would be a bad practice from the JS side (same as storing a reference to a deleted value in C++).

I don't consider it a bug. Being able to do this opens many doors when talking about memory management from the C++ side when exposing objects to js.

I wrote a small article about this topic and how you can benefit from such constructions: https://blog.codeisc.com/2018/09/15/xlnt-wasm-bindings.html#avoiding-exposed-ownership

@stale
Copy link

@stale stale bot commented Jul 25, 2020

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.

@stale stale bot added the wontfix label Jul 25, 2020
@stale stale bot closed this Aug 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants