Dart/C++ bindings library

[Ian Mackenzie]

Has anyone looked at creating a Dart/C++ bindings library along the lines of Boost.Python? I couldn't find anything general-purpose after a bit of searching. There's https://github.com/StevenChristy/SFML2-Dart-Binding and https://github.com/donny-dont/DartEmbeddingDemo as examples of how to use the Dart native API, but nothing that I could find that attempts to provide a general solution.

How much interest would there be in something like this? I will likely end up writing something fairly simple for my own use, but I could also see creating/contributing to a standalone library. One option would be to add Dart support to SWIG, but I'd love to include good support for both synchronous and asynchronous calls and I'm not sure how well that would fit with the SWIG model.

[Rico Wind]

I guess you already looked at the existing native extensions support in the vm:

https://www.dartlang.org/articles/native-extensions-for-standalone-dart-vm/

I am currently experimenting with the FFI library [1] in fletch (which is quite different from the natives extenstions support in the vm), and will be looking into the feasibility of  generating a SWIG module for generating dart interfaces. Nothing much to share at this point though, but stay tuned.

Cheers,

Rico

[1] https://github.com/dart-lang/fletch/blob/master/lib/ffi/ffi.dart

On Mon, Aug 3, 2015 at 2:55 AM, Ian Mackenzie <ian.e.m...@gmail.com> wrote:

Has anyone looked at creating a Dart/C++ bindings library along the lines of Boost.Python? I couldn't find anything general-purpose after a bit of searching. There's https://github.com/StevenChristy/SFML2-Dart-Binding and https://github.com/donny-dont/DartEmbeddingDemo as examples of how to use the Dart native API, but nothing that I could find that attempts to provide a general solution.

How much interest would there be in something like this? I will likely end up writing something fairly simple for my own use, but I could also see creating/contributing to a standalone library. One option would be to add Dart support to SWIG, but I'd love to include good support for both synchronous and asynchronous calls and I'm not sure how well that would fit with the SWIG model.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[Ian Mackenzie]

Hi Rico,

Yes, a while ago I did get some simple bindings working based on the existing native extensions support as described in that article - the sort of bindings library I imagined would build on top of the existing functionality to make it easier to expose a large set of C++ classes to Dart.

Your FFI stuff looks cool - can you comment at all on what sort of use cases you're considering as you design it? I can imagine that a binding layer aimed at (for instance) high-performance C function calls could look rather different than one aimed at exposing complex C++ classes and objects (where ownership/lifetime management can get more tricky).

Look forward to hearing more about it!

-Ian

[Rico Wind]

On Mon, Aug 3, 2015 at 8:14 AM, Ian Mackenzie <ian.e.m...@gmail.com> wrote:

Hi Rico,

Yes, a while ago I did get some simple bindings working based on the existing native extensions support as described in that article - the sort of bindings library I imagined would build on top of the existing functionality to make it easier to expose a large set of C++ classes to Dart.

Your FFI stuff looks cool - can you comment at all on what sort of use cases you're considering as you design it? I can imagine that a binding layer aimed at (for instance) high-performance C function calls could look rather different than one aimed at exposing complex C++ classes and objects (where ownership/lifetime management can get more tricky).

The short answer is: we don't completely know yet :-)

You are completely right that the overhead that you are willing to take are quite different. We have been discussing several things, but the basic idea is to that all of the lower level functionality we would use to call something like more complex c++ stuff is available generally (i.e., you as a programmer have access to if if you want)

As an example, the overhead of calling a c function in the current interface is pretty low (we use it internally in fletch as well). You can optimize this by having handwritten platform specific natives for pushing arguments to the stack (or into registers depending on ABI). We are considering exposing natives that allow you to do this manually, for more efficient/elegant handling of structs/classes. There is absolutely no reason to make the simple c call slower to allow for more complex stuff.

But again, the above will be driven by the use cases and issues we see moving forward

Cheers,

Rico

[Ian Mackenzie]

As an example, the overhead of calling a c function in the current interface is pretty low (we use it internally in fletch as well). You can optimize this by having handwritten platform specific natives for pushing arguments to the stack (or into registers depending on ABI). We are considering exposing natives that allow you to do this manually, for more efficient/elegant handling of structs/classes. There is absolutely no reason to make the simple c call slower to allow for more complex stuff.

But again, the above will be driven by the use cases and issues we see moving forward

Sounds great - I seem to remember reading that the existing Dart VM native API has non-trivial overhead, so I'm glad a low-overhead FFI seems to be a priority for Fletch. Getting into the weeds a bit, do you have plans for (or is there already) a mechanism similar to the current Dart_WeakPersistentHandleFinalizer stuff that would allow native resources to be freed when a Dart object is garbage collected? That's the sort of thing that cannot easily be built on top of a lower-level FFI since it requires tying into the VM, and as I understand it can be tricky to support without impacting performance when it's not needed.

[Rico Wind]

Somewhat yes, but not full yet, e.g., you can do:

var mem = ForeignMemory.allocatedFinalize(42);

This will allocate 42 bytes of c memory, and it will be freed when mem is garbage collected.

Cheers,

Rico

[Ian Mackenzie]

Thanks for all the detailed answers Rico! Something like allocatedFinalize() could work for a lot of cases. I'm also assuming that even if full finalization support is added later, allocatedFinalize() might still be faster for the cases where it's sufficient on its own, so it's nice to have that option.

[Don Olmstead]

I thought about making something similar to luabind to accomplish it. I didn't really get around to it cause its still not possible to have a native extension in pub.

--