[webkit-dev] Using either a block or C++ lambda for a JSC C function pointer API

Edgar A edgar.factorial at gmail.com
Mon Jun 27 14:00:25 PDT 2016


Copying over my question from stack overflow: (http://stackoverflow.com/questions/38062386/using-either-a-block-or-c-lambda-for-a-c-function-pointer-api <http://stackoverflow.com/questions/38062386/using-either-a-block-or-c-lambda-for-a-c-function-pointer-api>)


up vote
 <>1
down vote
 <>favorite
 <http://stackoverflow.com/questions/38062386/using-either-a-block-or-c-lambda-for-a-c-function-pointer-api#>	
Working with JavaScriptCore's C API and I have this C function pointer signature:

typedef void
(*JSObjectInitializeCallback) (JSContextRef ctx, JSObjectRef object);
And here is a problematic usage:

JSClassDefinition def = kJSClassDefinitionEmpty;
// This is that previously typed out signature being used
def.initialize = [](JSContextRef ctx, JSObjectRef obj){
  CAMLlocal2(init_context, init_obj);

  init_context = caml_alloc(sizeof(JSContextRef), Abstract_tag);
  init_obj = caml_alloc(sizeof(JSObjectRef), Abstract_tag);
  Store_field(init_context, 0, (value)ctx);
  Store_field(init_obj, 0, (value)obj);
  // Need to call this but can't because class_def is 
  // from the outside and can't be put in the capture list
  //caml_callback2(Field(class_def, 5), init_context, init_obj);
};
So I'm not sure what's the right way to get around this. I don't want to start defining C functions all over the place because I need to create these callbacks dynamically and I'm not sure how to do the global state solution correctly because that will introduce more issues of locking correctly, etc. I'm also open to using objective-C blocks, just the blocks, no objective-C. Saw some mentions of std::function but I don't understand C++ well enough to use that API.

Looking through the Apple Objective-C layer on top of JSC to see how they did it....


Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20160627/16949b37/attachment.html>


More information about the webkit-dev mailing list