Flutter: Support integrating with C/C++ in plugin framework

@jason-simmons knows the most about Gradle. Once we have an .so, I can definitely help getting it loaded.

I did find that under buildSrc there is another property for setting the gradle build version. After updating to 2.2.2 I've progressed, and was able to verify the .so loads, and is callable from Java.

Presumably we would also need to add a C API for sending HostMessages from C/C++ code to Dart.

Yes please. I have a suspicion that the C->Java callback may not be cheap.

Any update on this? Considering Flutter for building a cross platform app that calls C++ code compiled into a shared library, and this is the only major stopping point.

This is possible today (and @jtrunick did so in his shipping app), but you have to bounce through Java or Obj-C first.

i.e. you can use https://flutter.io/platform-channels/ to talk from Dart to Obj-C/Java and then from Obj-C/Java call into your C++ code. This bug covers adding more direct support for this, and potentially avoiding the Obj-C/Java passthrough.

Since Dart VM is implemented in C++ shouldn't there be an easier (if less safe) way to call C shared libraries directly (say via dlopen) ? How much change would be required for basic (unsafe/experimental) support?

Is something like this: https://www.dartlang.org/articles/dart-vm/native-extensions available on android or ios?

We have heard this requirement from a couple of Google apps:

• One such app wrote their own C++ libraries for operating the camera to reduce latency. These libraries are platform specific and optimized to work as quickly as possible. Invoking these libraries with the lowest possible latency is critical for such apps. Forcing them to go through PlatformChannel + JNI will not achieve that on Android.

• There are advanced mobile teams out there who write business logic components in C++ to be able to share it between their Android and iOS implementations. Flutter supporting direct integration with those libraries would further cement its position of being the best cross-platform framework out there.

I don't think this is a _must have_. However, this is one area that Flutter can further differentiate itself from other cross-platform solutions.

One such app wrote their own C++ libraries for operating the camera to reduce latency. [...] Forcing them to go through PlatformChannel + JNI will not achieve that on Android.

What was their solution on Android for getting from C++ to Java and back?

If it is really necessary, we can allow Dart native extensions on the mobile platforms. Right now, we don't expose the symbols in dart_api.h. We will need to decide on the following before we can flip the switch:

• Figure out how to make the AOT compiler aware of Dart code whose sole entry point is from a method that may not be in the main Flutter engine dynamic library. Otherwise, the tree shaking pass may get rid of the code.
• Provide guidance on building and packaging native extensions (Gradle & Xcode for Android & iOS respectively).
• Provide some ABI stability guarantees for the routines in dart_api.h. Though it is mostly stable, I believe it is still evolving to account for the various modes.

So far, the platforms channels mechanism seems to have been adequate for the simpler use cases.

What was their solution on Android for getting from C++ to Java and back?

I have not looked deeply into their use case. It seemed that they have written all the bits that need very low-latency communication in C++. I will ask whether they use any JNI for performance-critical use cases (my gut feeling is no).

It really depends on what we can do on Flutter side. If we can supply an interop that's significantly faster than JNI, it would be a big win for these teams. They can shrink their C++ codebase and shift more to the app side. If our interop performance is comparable to JNI then I don't see a big win here. They could probably continue what they are doing now and use PlatformChannel.

This is about giving such teams an extra reason to switch to Flutter. I have not heard of this being a blocker, so prioritize accordingly.

If I understand what you're saying correctly, you're saying current solutions are to have all the logic (camera+UI) in C++ with minimal logic in Java, and the desire is to move the UI part of this logic to Dart, without losing the low-latency UI<->camera interactivity.

Can you talk about what their threading situation is like? Do they just have the one thread for camera+UI?

@chinmaygarde might move us closer to solving this with his current work on the embedder API.

+1

Any progress with this issue?

We've already been using djinni to share logics across different platforms. It would be great if we can have interop between Dart and C++, rather than having to go back and forth through Java/Objc-C.

If Dart can integrate with C/C++ I think it's a great idea for mobile to re-use a ton of native library and no need binding to a specific platform using JNI or Objective C++.

Have you considered https://github.com/mono/CppSharp? They already have the parsing and AST in place for c++, as well as support for multiple target languages. Perhaps you could create a Dart generator for CppSharp?

Integrating a C++ based database like Realm directly in C++ would achieve significant performance and developer productivity boost :-) Going up/down through JNI would be such a waste.

I am considering Flutter for an AR app doing computer vision (probably using OpenCV), and an efficient and direct Dart-C++ interop would be a major positive point. I imagine many other people doing challenging apps in term of computation might share this need.

Can you someone confirm that C++ interop is still not available? Can it be done using packages?

@tofutim Direct c/c++ interop is still not available hence why this issue is still open. However, you can use platform channels and then use Obj-C/Java to interact with your C++ code. Its not great but its all we have at the moment.

Can you someone confirm that C++ interop is still not available? Can it be done using packages?

To interoperate with platform libraries, the platform channels mechanism is still the current recommendation.

A more performant mechanism described in the native extensions document can be added trivially. However, I am not aware of any ABI stability guarantees for the symbols exposed from dart_api.h. If @a-siva and @eseidelGoogle can confirm that such guarantees exist, I can start exposing those symbols ASAP. Optionally, we can then carve out a subset of Tonic as convenient wrappers around the C API for ease of use from C++.

My understanding is that this bug is about providing a C-API and tooling hooks to make it easy to have a wholly C/C++ plugin (no Obj-C/Java shimming required, but still async through platform_channels).

I don't think we should consider synchronous methods like native extensions at this time. (But honestly I defer that to @Hixie or @cbracken).

@eseidel

I don't think we should consider synchronous methods like native extensions at this time

why is that?

Current approach to call C code is Dart->Java->C
We cross JNI twice, right?
first time: dart to Java via platform channels (under the hood JNI call used, right?)
second time: Java -> C via JNI

As an example, from the point of view of my project's needs, having access to dart_api.h even without stability guarantee (as an experimental feature for example) would already be good enough. My main concern is to move large blobs of binary data (images) from the Dart side to the C side and back without marshalling and ideally copying. Unity/Mono achieves that.

From dart-sdk issue 31960 I understand that the current implementation of isolates might not allow to pass data without copying (although in theory it should be possible to detect that the buffer created in isolate A is not used any more after being passed to isolate B and therefore its ownership can be transferred, without copying.. any plan on that front?), but if at least within an isolate there is no marshalling to/from C it would be good.

Marshalling could be avoided with flatbuffers which looks to be landing soon: https://github.com/google/flatbuffers/pull/4676
Or with protobuf messages using a single bytes only field.

Of course, this entails large amounts of byte copying so not great for all use cases.

I'm hearing at least three different desires presented here:

1. Would like a way to easily write a plugin for Flutter using only C/C++ code without having to add a bunch of Java/Obj-C glue (that was my original understanding of this bug and something I definitely think we could/should do).
2. Would like a way to move large volume of data in/out of Dart quickly/with low latency/etc. (Presumably from a variety of languages, including C++. This sounds like a very valid case! I'd strongly recommend filing a separate bug including an example.)
3. Would like a way to extend Dart with synchronous calls/objects? (e.g. native extensions or other methods? This is also totally doable. There are potential difficulties around API stability, and I think we'd want to learn more about the specific use case before taking action.)

My feedback from reading the above is that we should consider splitting out some additional bugs. We definitely need to invest some around C++ inter-op, but it's difficult to determine from this long thread as to which exact use cases we should address and in what order?

Would interested parties be willing/able to file new bugs with their desired use cases and link them back here? Happy to leave this issue open to track the general interest in this problem space.

With regards to performance and 2. above: Although I'm certain that the performance of Flutter's platform_channels could be improved (and that we'll likely need other plugin/inter-op methods to cover all use cases), we will want some concrete use cases (maybe they exist and I haven't seen them?) where the performance of Flutter's platform_channels is a bottleneck before we take action. My experience with optimizing performance of systems is that my gut instincts are often wrong. Even though things like JNI or platform_channels feel like potential bottlenecks, we won't actually know until we measure.

Thank you again all for your help and feedback!

Would like a way to easily write a plugin for Flutter using only C/C++ code without having to add a bunch of Java/Obj-C glue (that was my original understanding of this bug and something I definitely think we could/should do).

that would also give better sqlite integration for flutter + there are tons of C / Rust libraries for crypto, ssh and other stuff. It would be cool to being able to use that easily.

@eseidel

I'm hearing at least three different desires presented

My vote for 1.)

From reading the Flutter docs it should be fairly "simple" to extend the Platform Channels to support C.
The only novel thing would probably be a way of loading _dynamic shared object_(s) into the current process.

I would imagine _Android-C_-usage to look something like:

#include <ndk-version.h>
#include "methodchannel.h"
#include "methodchannels.h"

MethodChannel* flutter_channels;

__attribute__((constructor))
void
on_library_load() {
    flutter_channels = NULL;
}

__attribute__((destructor))
void
on_library_unload() {
    while (MethodChannel* channel = MethodChannels_pop(flutter_channels)) {
        MethodChannel_delete(channel);
    }
}

#define str(a) #a

void
{{pluginClass}}_on_method_call(MethodCall* call, Result* result) {
    if (strcmp("getPlatformVersion", call.method) == 0) {
        Result_success(result, "Android " str(__NDK_BUILD__));
    } else {
        Result_not_implemented();
    }
}

void
{{pluginClass}}_register_with(Registrar* registrar) {
    MethodChannel* channel = MethodChannel_new(Registrar_messenger(registrar), "{{projectName}}");
    flutter_channels = MethodChannels_push(flutter_channels, channel);
    MethodChannel_set_call_handler({{pluginClass}}_on_method_call)
}

Conceptually, at least for _Android-C_, you would have to decide how to handle the combination of Java and C.

@eseidelGoogle
We currently expose golang code via the Java and swift wrappers and the latency is an appreciable issue we are hitting.
why ?

• We need to share business logic between many platforms.
• For video and image functionality like screen sharing.
• For DB.

If your able to add golang support at the direct level that would make a hug difference !
Compiling golang code for mobile is also very easy without any LDFLags magic, so i think it would be popular. I know of a few other golang coders that are currently using the Method Channels also.
As far as serialisation we currently use Protobufs and flatbuffers.

Example:
https://github.com/dnfield/flatbuffers/blob/master/samples/sample_binary.go

In fuchsia this is done with FIDL and it has bindings to c, rust and golang.
Its pretty awesome to use and I have been enjoying trying out rust and golang on a embedded board.

It should be possible to expose the fidl stuff through iOS and java too.
That would give a nice onramp between fuchsia and flutter on mobiles and desktop.
Just an idea that I am playing with

@eseidelGoogle
Hiixe told me that FIDL cant be done at Flutter level because FIDL relies on kernel code from zircon in Fuchsia. So the only way to replicate the FIDL IPC style functionality within Flutter would be to write a FIDL version into the Flutter engine. But then i was playing aroudn with it and noticed that its quite similar to Flatbuffers. SO why not just use FlatBuffers for the serialisation layer between the Flutter and the cpp or golang or rust layer on Flutter. ?

Just +1 on this, we have a flutter app using a library called Superpowered. Superpowered is written in C++, we then use java and JNI type stuff to interact with it, which we in turn use platform channels to talk w/ the Java code. It would certainly be nice if we could skip the middle man.

This is additionally with this holding up popular mobile libraries like Realm from making flutter versions because their core is written in C/C++ and they also don't want to deal with a java/objc/swift middleman.

For those reasons, aside from general stability I think this issue is one of the most needed changes in flutter at the moment. (More specifically #1 on @eseidelGoogle's list.)

If you want to hear an argument for bypassing Java/JNI in platform extensions (ie, not just hiding/automating the Java glue layer for the developer), Superpowered has a lot to say on that topic: https://www.youtube.com/watch?v=LzIuir3r6Co

@pnico Can you explain how this is arguing that Java/JNI should be bipassed? It seems to be saying little more than your audio processing code should be written in C++. (Which doesn't mean you can't call it through the JNI or by any other means)

@csga5000 you're totally right, that made no sense :D JNI probably isn't going to affect performance really unless you're trying to do more esoteric stuff. I guess it really does come down to convenience/maintainability, and I guess maybe the ability to move more app-specific code out of Java/C++ and into Dart

I think @pnico is saying that he CAN call it through JINI, but that the JINI adds too much latency.
So the perf is the problem.
yes / no ??

This one might make a huge difference mostly for crypto related work.

Also I assume for Android Things, though I haven't seen or made experiments
and benchmarks for timing sensitive gpio in neither c nor dart for over a
year.

On Sat., 9 Jun. 2018, 10:52 Eddy WM, notifications@github.com wrote:

This one might make a huge difference mostly for crypto related work.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/7053#issuecomment-395927258,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFHMcSI2JDHbgv3iYrStDN5mlzkQ8XEkks5t6xxMgaJpZM4K-PLw
.

Any progress since then?

Until this get's resolved, is there a recommendation for an example flutter plugin thats shows how to integrate a c/c++ lib? Is djinni a good way to go?

Until it's resolved, the only way to integrate c/c++ writing native android & ios code, then interfacing to the dart code using platform channels

I've implemented plugins that use platform channels (to jar files and CocoaPods). I'm looking for an example plugin that shows how to integrate to the same c/c++ lib (for both android and ios). Any recommendations?

@mmcc007 It's how you do it in java or swift.

Java: https://www.google.com/search?client=opera&q=android+java+use+C%2B%2B&sourceid=opera&ie=UTF-8&oe=UTF-8

Swift: https://www.google.com/search?client=opera&q=swift+use+C%2B%2B&sourceid=opera&ie=UTF-8&oe=UTF-8

You can see how superpowered recommends you do it if you really want an example (it's just one I know of): https://github.com/superpoweredSDK/Low-Latency-Android-iOS-Linux-Windows-tvOS-macOS-Interactive-Audio-Platform
See the examples folders. Ex, within https://github.com/superpoweredSDK/Low-Latency-Android-iOS-Linux-Windows-tvOS-macOS-Interactive-Audio-Platform/tree/master/Examples_Android/SuperpoweredRecorder/app/src/main there is java/com/superpowered/recorder/MainActivity.java which references code in cpp/RecorderExample.cpp

@csga5000 It looks as though it would reasonably straight forward.. on first review. Still would be nice to look thru a working flutter plugin. Thanks.

+1 for this. Any working examples of a flutter app using c++ would be well received

There is a project that does this for golang and I think the same approach
can be used for c++ too.

The golang program uses jsonrpc.
Then all you need to do is front your own golang code with jsonrpc.

Then everything is very easy.

I think platform channels ONLY supports JSON as the agnostic serialisation
format ?

On Wed, 18 Jul 2018, 16:50 Jefferson Bledsoe, notifications@github.com
wrote:

+1 for this. Any working examples of a flutter app using c++ would be
well received

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/7053#issuecomment-405958345,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATuCwkPbb9vLdoaEwM-bLhYPZxtyQ5Vjks5uH0sqgaJpZM4K-PLw
.

Hi, any news?

Just want to know if anyone in this thread has managed to integrate Superpowered library directly into a flutter app?

Yes @skills-up we have done it. Just not in an open source project so I can't show. But if you see my tips earlier, that's how you do it. You may need to build your flutter app for each CPU architecture though

I understand you have done via JNI/Java and not directly from dart. I was wondering if it's possible to avoid platform specific code altogether.

You may need to build your flutter app for each CPU architecture though

You mean a separate app for each architecture, or just specifying all the supported architectures?

BTW, we already have a working app written natively in Java. However, now that we have to create an iOS app too, I was wondering if creating one in flutter (instead of expending efforts on Swift/XCode) would make more sense from future maintainability perspective, with the benefit of a single code base.

Well. Realm is waiting for you guys to provide a way: https://github.com/realm/realm-object-server/issues/55

lukaspili : I guess everyone is still waiting on: flutter/flutter#7053
bmunkholm: @lukaspili Yes that's a prerequisite for sure.

For what it is worth, I'm waiting for this as well. Can't really look into replacing XF apps with flutter ditto until you guys get the proper plumbing. As it currently stands, Xamarin blows flutter out of the water in this department.

Late to this party but a big +1 for this thread.

I develop desktop apps, my view as a line of code (for desktop):

Flutter - Dart + C++ > Qt ? partyTime() : makeDoWithElectronOrQt()

If Flutter can offer first class support for C++, I think it's general approach could be an absolute winner for cross platform application development, not just a "mobile first" but a world first. Qt is pricey for small devs, is opinionated and doesn't embrace modern C++ and nothing really competes, could Flutter eat at least some of it's UI pie?

P.S: I'm not anti-Dart, it's another new C#/Go/Rust/etc. competing language that may be super productive for a new platform but the world of high performance desktop (my interest here) applications is firmly C++, with extensive OS and library support, a language that is moving forward at a rate of knots itself (it's not C), and I think Flutter deserves it!

I don't think flutter will support C++ at any point in the near future, and it's certainly not possible now. And I for one tremendously prefer Dart - writing apps in C++ even w/ flutter would take a lot more effort. And I don't think C++ directly translates to desktop support, they'd still have to write quite a bit of code, and the dart VM should work for desktop anyway. I think the performance is negligible for most applications.

I think in the end google wants to support interoperability so you can write flutter apps for any and all platforms using any supported languages or even a combination of said languages. But I wouldn't expect that until well when or after Fuchsia is released. For now their goal is to make it easy to write code once. Dart matches that goal as it's easy to use/learn, efficient, and one of google's languages anyway. I really see almost no practical advantage for the average user of having first class C++ support. The performance is negligible in a mobile app, and using platform channels w/ C++ would be convenient for the purpose of interacting w/ existing C++ libraries. On the bright side, you can be certain they eventually intend for flutter to support desktop (well at the very least Fuchsia's capybara, but I doubt they'd stop there).

This thread is about supporting direct integration w/ C++ from dart/flutter, which hopefully could be coming in the near future.

I don't think flutter will support C++
I really see almost no practical advantage for the average user of having first-class C++ support.

It's not about how awesome Flutter/Dart is vs C++, it's more about the point/ease of integrations you need in order to fit in the current ecosystem. A long list of libraries exist as shared object (OpenCV to name one) that are the industry standard, you can't expect people to rewrite them in Dart?

The performance is negligible in a mobile app, and using platform channels w/ C++ would be convenient for the purpose of interacting w/ existing C++ libraries.

Quite the opposite, using channels is suboptimal in this context, think about use cases where you need to work with a large binary object on memory (images), you would need either to :
1- Copy these binaries from/to C++ memory
2- Work with JNI to interface with the library (and handle pointers allocated dynamically to these binaries)
not mentioning the overhead of serialising/deserialising values/parameters cost that you incur by using the channels.

A good framework is a balance between the new features/paradigms it introduces vs how easy to integrate with the current ecosystem/legacy, which we can't deny C++ is part of.

@nhachicha @csga5000 wasn't disagreeing that directly integrating C++ was important; he was replying to a previous comment asking if Flutter could directly be used from C++, as in, without needing any Dart code.

The performance is negligible in a mobile app, and using platform channels w/ C++ would be convenient for the purpose of interacting w/ existing C++ libraries.
@nhachicha I couldn't agree more.

Truth is for applications that don't need tooth biting performance (which is many) then why not swap the hard to master C++ for something more productive, in fact why stop at Dart alone, why not slot in any of these super popular, (many more popular/established than Dart) languages:

• C#/.Net Core runtime
• Javascript/Typescript V8 runtime (you'd almost have a browser at that point but so what)
• Rust (also fast!)
• GoLang
• Python
• [Insert your favourite here]...

And as much as I personally love and use some of those languages everyday, C and C++ are at the core of Linux therefore Android, iOS, and desktop platforms such as Windows, MacOS and other desktops. Half of the above languages (including Dart) are written in C++. Cutting edge technologies time and again require tuned native performance, such as AI (Tensorflow is C++, Caffe C++, Pytorch is C under Python, etc.), Augmented Reality libraries, AAA game engines and anything that needs to go near a GPU (CUDA, called from C/C++).

For the same reason that the Flutter rendering engine is itself written in C++ (native, high performance, battery/memory/cpu efficient), I think it would be super to unlock the best possible performance, when needed, without going near a managed runtime and simply supporting C++. This would set Flutter apart from other frameworks such as Xamarin and Nativescript, which honestly offer a similar development experience (having used both) just with different languages, why not make flutter special rather than just "the Dart one"?

_As a side note, I'm totally at home with writing everything in C/C++, from form validation through to pixel shaders but I'm not pretending that's the view of many people looking at this repo - and that's because I find C++ a highly productive language - totally a personal choice however._

This is one of the main reasons that we need C++ Integration

https://github.com/realm/realm-object-server/issues/55

There are two straightforward ways to go about C/C++ integration:

• Provide method channel implementation in C++
• Provide Dart VM native extension support

Unfortunately both of these have major drawbacks that prevent us from pursuing them:

• Method channels are high overhead abstraction - while C/C++ integration is requested when low overhead interactions are desirable. Meaning that method channels would not actually solve the problem.
• Dart VM native extensions require people to use Dart VM C API - it might not be desirable to introduce too much external dependencies on that, especially given the fact that API did not age well and requires some serious refactoring.

It seems that a more desirable alternative is an introduction of dart:ffi - a core component of Dart VM that would allow to bind directly to native code enable people to write something like:

import 'dart:ffi' as ffi;

// Bind foo to symbol _foo from library libxyz.so with signature
// int32_t (int32_t, double, char*).
@ffi.import("libxyz.so", name: '_foo',
            signature: ffi.Signature(ffi.Int32, [ffi.Int32, ffi.Double, ffi.PChar]))
extern int foo(int foo, double x, String foo);

We had certain amount of interest in implementing an FFI like this for a long time - I would expect us to experiment with it some time in the near future, but I would not commit to any concrete timelines.

@kirbyfan64 Is exactly right, @nailgilaziev, @bytesoftly I'm not trying to say C++ integration isn't needed, I was just saying I don't think there's that much reason/demand to make flutter support C++ INPLACE of dart - but I'm not saying that integration isn't needed. What @mraleph is saying sounds smart to me.

@mraleph The Dartino had a similar implementation for FFI. How difficult it is to resurrect?

@listepo parts of it. Dartino's implementation of FFI was very dynamic - this is not something we want for Dart 2 which is considerably more static than Dart 1.

Late to the game, but here is another use case: We would like to include c files and methods in dart for cryptographic purposes.

What we would hope for are the following:
1) Identical code for iOS and Android, i.e. no going through ObjC or JNI layers.
2) Hopefully a more efficient implementation than when going through e.g. JNI twice.
3) Possibility to reuse the dart model code in a follow-up Web app e.g. in AngularDart, or follow-up desktop apps using this project: https://github.com/google/flutter-desktop-embedding

I believe what we want is closest to point 2 @eseidelGoogle mentioned above. As for synchronous support, I consider it a "nice to have", since asynchronous functions cannot be used in a constructor, where one might want to perform e.g. a quick hash calculation. But getting used to Darts async way, synchronous support appears less important than the general possibility to achieve points 1)-3) above.

Using FFI as suggested by @mraleph, would this allow for 1)-3) as in my previous comment, or would it mean that different code is needed on different platforms (Android, iOS, ...)?

@CryptUser if your C/C++ code is the same on all platforms the Dart code for calling it via FFI would also be the same on all platforms.

@mraleph Sounds great! Given that the original issue has over 200 thumbs up, is there any chance to increase priority on this?

@mraleph is there an open issue for FFI in Dart somewhere?

@dnfield I have filed one just now https://github.com/dart-lang/sdk/issues/34452

I would love to be able to write C/C++/Rust code and be able to use it over ffi

Example:

I test flutter on android tablet (Android 4.4).
flutter run quickly.
But when i try read 1000 row with sqflite who use platform channel, it's ridiculous slow.
the reason : i can't use sqlite cursor reader.

but if i could use directly the sqlite library, the same query is instant. (tested with xamarin and native android project).

We're discussing right now how best to approach this. As noted above in https://github.com/flutter/flutter/issues/7053#issuecomment-377711814 this issue has many parts and probably needs to be split. :)

But we have found some engineers interested in exploring an FFI (as noted in https://github.com/flutter/flutter/issues/7053#issuecomment-415161464). Our focus right now is on getting 1.0 out the door, but once that's done this will be high on the list. Thanks again for all your continued feedback. We'll update this issue when we have more progress to share.

I am also Matlab/Simulink user. I can generate highly optimized cpu specific c/cpp code. I want to integrate my algorithm into flutter. I have lots of image processing algorithm. I need a binding generator for native codes. Otherwise i will forget all my dart-flutter experiences and I will start to learn xamarin or something that fits me.

Can we speed up the progress?

It's just such a huge pain to interoperate between Dart and C.

Rushing the process isn't likely to result in a good quality product. It'll be ready when it's ready. :-)

Rushing the process isn't likely to result in a good quality product. It'll be ready when it's ready. :-)

Well, what I tried to say was that we might want to increase the priority so that we could put more resource and effort on resolving this. You know that there are 1386 open issues as of now targeting "Goal" which will be "fixing in the coming years".

After reading the thread once again, I noticed that @eseidelGoogle said that this will get higher priority after Flutter 1.0 is ready. I think that it has addressed my concern well.

"Goal" may be the wrong bucket. :) @mraleph has someone exploring https://github.com/dart-lang/sdk/issues/34452 as we speak. That's a part of a solution at least.

Here is the vision doc for the FFI we are currently prototyping on the Dart side.

Please take a look and let us know what you think.

I can't say much about the FFI part because I never used something like that,
but I'm wondering how pub integration will look like.

How would publishing packages be handled that make use of FFI?
How would consuming packages that use FFI be handled?

@zoechi we have not discussed pub integration yet.

They should be able to work similarly to Flutter plugins today - include platform/architecture appropriate sources and/or binaries that can be compiled/linked into the consuming application.

From a pub perspective, it shouldn't be a big deal - except that there might be larger binary files included in the package.

There'd need to be some work done though around the Flutter tooling end of things to integrate them into Flutter projects - they wouldn't really work quite the same as Android/iOS plugins do today.

Should the pub-integration be moved to a dart-lang/pub issue to keep this issue more focused?

I have read 'vision doc' and I at last see shapes through the fog.

In meantime I was pondering on something much different.

Namely of (re)using Flatbuffers to make something like NativeChannels. At executing (AOT) time it would boil down to pointer passing, while at dev time it would let me leverage existing tools for the "native" side written not only in C/C++ but also written in Go or Rust.

Message passing approach is also more in line with current stream based architectures (Bloc, Rx). It voids any concern about memory mangement, too, as the compiler might generate suitable ring buffers where appropriate or assume simple 'callee frees' where a callee needs to hold on data longer.

But to be honest I'll applaud any form of ffi if it will be seamlessly integrated into Flutter (Fuchsia) ecosystem and let me use cpu optimized native code from within Dart app.

@ohir what you had envisioned would be another solution for some of the problems presented bug. This bug evolved into a general purpose catch-all for anything C++ related. :/ I suspect (as I've noted in previous comments) we need to break this bug into smaller ones. The FFI work may not be the only solution we build in this space.

@eseidelGoogle any progress on this ? right now we have a project needs to implement heavy video processing tasks which might be done via ffmpeg， since the current dart package can not provide a viable solution，we are eagerly waiting for flutter to call ffmpeg lib directly.

For those page-to-page UI based apps, now flutter I think is really a good choice than turning to double coding work on both android and ios， if we were at 5 years ago with such a lovely equipment， the whole Apps industry might be changed. However, the advantages of flutter right now is not that breathtaking for companies migrating to it，cause they already had done good enough with the old way，but for some non-UI task， dart is way behind the top requirement.

it does't mean that dart is not good nor viable for those tasks one day, but in a view of a normal IT company which might be included into the flutter eco-system, what they need is reducing the cost by using a cross-platform coding method only if the most top cool features could be achieved, such as client-side data processing, video/audio, AR staff etc as long as some algorithm they already done via c/c++. it is really hard for them to re-implement or re-invent it using dart lang.

and the key solution is introducing the direct and efficient way for flutter to communicate with c++, I even think this is of the first priority of a "cross-platform" thing, dart for UI staff is perfect, some normal data logic can also be done in dart, but it is much better for flutter to merge into the long but still active and efficient c++ eco-system rather than rebuild a holy new one !

the dream of a real "cross-platform" coding experience is dart UI staff with c++ behind the hood, no java code at all, no oc code at all. wahaha, I can't wait to see it happen!

@smellbee Can't you use the ffmpeg command line?

@smellbee I featr I'm not the right one to answer this. @eseidelGoogle any news on this?

@smellbee Can't you use the ffmpeg command line?

it's a client side work, using ffmpeg lib to render video frames to produce instant feed back stream, is it possible to use command line?

@smellbee I featr I'm not the right one to answer this. @eseidelGoogle any news on this?

sorry for that, I typed "es" , and it auto completed, I didn't notice it.... hope @eseidelGoogle can see it

The work is in progress on the Dart side - we hope to have something ready Q1 2019.

It is a big feature and we would like to get it right: as we want to get it working great across different execution modes for Dart, so please bear with us as we work out the details.

You can follow dart-lang/sdk#34452 which tracks the work on the Dart side.

Dart FFI will allow to call C functions from Dart.
But what about the C++ features - classes, std containers, smart pointers, exceptions?
Can we expect the possibility to export C++ classes to Dart with minimum boilerplate?

Another quite important feature is asynchronous support - the ability to run C++ code on a separate thread and return Future/Stream from methods.

@t-artikov There are no current plans to support C++ interoperability directly. This is too complicated. The only thing that can ergonomically interop with C++ is C++.

If you are interested in high-level interop with C++ then you will need to build your own interop layer that exposes your C++ API through C like API.

Another quite important feature is asynchronous support - the ability to run C++ code on a separate thread and return Future/Stream from methods.

I think this can be built as a package. We should just ensure that we provide right primitives so that this could be built.

Dart FFI will allow to call C functions from Dart.
But what about the C++ features - classes, std containers, smart pointers, exceptions?
Can we expect the possibility to export C++ classes to Dart with minimum boilerplate?

So long as if there is a way for C++ to call dart， I think those things are possible， C++ takes care of what C++ worrying about，and communicates with dart by being called or calling, no need to expose any low-level manipulation to dart which will destroy the ease of use of dart.

Another quite important feature is asynchronous support - the ability to run C++ code on a separate thread and return Future/Stream from methods.

And dart already has its asynchronous mechanism， so， whether a thread is C++ oriented or not makes no difference，as long as the C++ part can call dart whenever needed, and an "Isolate" can do the job.

That's what I think @mraleph , correct me if I am wrong ;)

@mraleph
In fact, there are examples of great C++ interop with other languages.
https://github.com/boostorg/python
https://github.com/ThePhD/sol2
https://github.com/dropbox/djinni
I hope Dart/Flutter will provide a similar mechanism out of the box.

If you are interested in high-level interop with C++ then you will need to build your own interop layer that exposes your C++ API through C like API.

To make it clear how this approach is applicable, could you please demonstrate it using the following С++ classes as an example:

struct MyObject
{
    std::string name;
    std::vector<int> data;
};

class MyService
{
    // Can throw std::exception
    std::shared_ptr<MyObject> createObject(std::string name, std::vector<int> data);
};

So that it can be used from Dart

var service = MyService();
var object = service.createObject("foo", [1, 2, 3]);
assert(object.name == "foo");
assert(object.data[0] == 1);

@t-artikov both boostorg::python and sol2 actually illustrate my point very well. Notice that this is C++ libraries for interoperating with other languages, not the other way around. Dart FFI is a Dart centric way of calling C APIs, not a C++ centric way of calling Dart.

To make it clear how this approach is applicable, could you please demonstrate it using the following С++ classes as an example:

You would have to write (or generate by some tool) something like this.

// To be compiled together with your code.
typedef std::shared_ptr<MyObject>* MyObjectPtr;

MyService* MyService_create() {
  return new MyService();
}

void MyService_destroy(MyService* ptr) {
  delete ptr;
}

MyObjectPtr MyService_createObject(MyService* ptr, const char* name, int* data, size_t size) {
  try {
    return new std::shared_ptr<MyObject>(createObject());
  } catch (...) {
    return nullptr;
  }
}

const char* MyObject_getName(MyObjectPtr obj) {
  return (*obj)->name.c_str();
}

int* MyObject_data(MyObjectPtr obj) {
  return (*obj)->data.data();
} 

void MyObject_destroy(MyObjectPtr obj) {
  delete obj;
}

// To be included on the Dart side.
@ffi.External()
external Pointer<Void> MyService_create();
@ffi.External()
external void MyService_destroy(Pointer<Void> ptr);
@ffi.External<Pointer<Void> Function(Pointer<Void>, Pointer<Void>, Pointer<Void>, Int32)>()
external Pointer<Void> MyService_createObject(Pointer<Void> service, String name, Int32List data, int size);
@ffi.External()
external String MyObject_getName(Pointer<Void> obj);
@ffi.External()
external Pointer<Int32> MyObject_data(Pointer<Void> obj);
@ffi.External()
external void MyObject_destroy(Pointer<Void> ptr);

class MyService {
  final Pointer<Void> _impl;
  MyService() : _impl = ffi.anchor(MyService_create(), MyService_destroy);

  MyObject create(String name, List<int> values) {
    final Int32List data = Int32List.fromList(values);
    return MyObject._(MyService_createObject(_impl, name, data, data.length));
  }

  static _destroy(Pointer<Void> ptr) {
    return MyService_destroy(ptr);
  }
}

class MyObject {
  final Pointer<Void> _impl;

  MyObject._(Pointer<Void> impl) : _impl = anchor(impl, MyObject.destroy);

  String get name => MyObject_getName(_impl);
  Int32List data => MyObject_data(_impl).as<Int32List>();

  static void destroy(Pointer<Void> ptr) { MyObject_destroy(ptr); }
}

Notice that this is C++ libraries for interoperating with other languages, not the other way around.

You are mistaken, they allow to expose C++ classes to other languages.
https://www.boost.org/doc/libs/1_68_0/libs/python/doc/html/tutorial/tutorial/exposing.html

Thanks for your Dart FFI example.
There are some flaws: the C++ exception should be passed to the Dart side; and the MyObject.data will not work this way (it gets only the pointer, but not the data size).
But the idea is clear.

In my opinion, such code is too verbose to write it manually.
I look forward to see whether this process will be automated for the new Dart FFI Flutter Engine bindings.

Run-time binding for C++ interoperability is nearly impossible (how do you deal with generics, multiple inheritance, operator overloads, mangled names, etc...). There had been many tough attempts (BridJ, CppSharp, etc), and to my understanding people find C interop as the most viable option.

There is unlikely very generic solution that official interoperability developer people can achieve for C++. Kotlin/Native does not offer that. scala-native iether. .NET either (Microsoft C++ interop is always either weird or static). JNI supports C++ interop only where static compilation is involved. Something like python boost glue needs to be written manually. Any third party group can develop things like JNAerator (i.e. YOU can do it, no need to expect Dart/Flutter teams to achieve that).

Following this conversation with no real answer I think I will stick to Qt which is Cross-Plattform and has full C++ Support. I was just thinking to give Flutter a try for my next project but now I wont, thanks a lot !

It could have been better if flutter would have been written in C++, with which interop with any other language would have been easily possible. Is there any attempt to rewrite flutter in C++?

I think the discussion is getting unnecessarily stretched now.

We know what is (or is not) on the development roadmap of flutter.
Accordingly, we can decide to use (or not use) it for specifics use cases.

I don't see any utility in trying to change the development agenda, or
demanding specific architectural implementation, beyond this point.

Thanks,
Gaurav

On Mon 25 Feb, 2019, 10:51 PM bhauj, notifications@github.com wrote:

It could have been better if flutter would have been written in C++, with
which interop with any other language would have been easily possible. Is
there any attempt to rewrite flutter in C++?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/7053#issuecomment-467098455,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AZ86acDpZgNeyezx40uxe_c5E2xZHWxaks5vRBumgaJpZM4K-PLw
.

Actually Flutter is as I know written in C++ but for programming in Flutter can only be done with the interpreter Language Dart which runs in a VM. But you dont have any chance yet to get from Dart to the C++ Part of Flutter...

So whoever reads this and has the common use case in Appdevelopment of good Cross-Platform Development, Flutter wont allow direct use of C++ if you need it then use another Cross-Platform Framework like Qt C++.

For me C++ is essential for Cross-Plattform-Development because its the lowest common denominator in almost every tech.

@aqmappdesigners

interpreter Language Dart which runs in a VM

That's not accurate.

Flutter uses the Dart VM in debug mode, which also makes hot-reload possible.
In release builds Dart is compiled to binary code like C++.

@zoechi Thank you, I did not know this. Thats sounds good for the performance

Thats sounds good for the performance

and is a requirement for Apples App Store.

The dart:ffi prototype has progressed to the point where we are deciding on API decisions. (Some design decisions are discussed here.)

To make informed design decisions, we would like more examples on what C APIs you would like to bind. So far this issue mentions SQLite, Realm, OpenCV, Superpowered, and ffmpeg. Any other APIs we should consider?

@dcharkes I don't know if it helps, but Telegram in Android does networking in C++ via JNI:
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/TgNetWrapper.cpp
It also handles GIF playback with ffmpeg, directly writing on Android Bitmaps:
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/gifvideo.cpp

It could be interesting to have a way to parse phones and adresses through libphonenumber and libpostal for registration forms. Also glfw + flutter-embedder and maybe one day we'll see a desktop app entirely written in dart.

+1 for SQLite and Realm. Please also look at Couchbase, they have a common C++ core with a C SDK.

Would the Firebase C++ apis be interesting? https://firebase.google.com/docs/reference/cpp/

Not looked into it much, but was thinking that might be able to replace the iOS and Android plugins with a single plugin that talks to C++ directly.

Some crypto libraries should get some love like ring from rust - https://github.com/briansmith/ring

+1 for OpenCV, Realm, SqlCipher (https://github.com/sqlcipher/sqlcipher)

cryptography libraries. Particularly libsodium or tink.

https://github.com/google/tink

https://libsodium.gitbook.io/doc/

There's a flutter-sodium library already, it talks through platform channels to libsodium wrappers on each platform, then to native.

Custom mapping libraries such as mapbox-gl https://github.com/mapbox/mapbox-gl-native

SMTP / IMAP handling (for chat-over-email) for Flutter via https://github.com/deltachat/deltachat-core is something I would love to use directly.

If I may be so bold as to paraphrase, common use cases are as below:

1. Low latency audio/video hardware access (such as, Superpowered)
2. Hardware assisted a/v processing (such as, ffmpeg)
3. TCP based socket access, for XMPP/other network oriented protocols
   (for chat, push notifications)
4. Process level upgrades (root access) / spawning threads in
   cross-platform compatible manner (for system apps, multitasking, emulators)

There may be more use cases, but these are the primary ones that come to my
mind.

Thank you everybody for providing examples! This is very helpful.

@skills-up note that we are much more interested in concrete examples, rather than abstract classification. That's because we want to assess the ergonomics of FFI on concrete examples.

Strangely enough, one of the languages which offers the best interface from/to C++ is Rust, via its powerfull macro + build system, despites having a completly different approach to OO.

I would say OpenSSL, since we need to digitaly sign soap requests and xml files (XMLDSig, Xades l) using client certificates.
Dart itself has BoringSSL, but only part of it is exposed trough Dart. So next best thing is calling native openssl libs from flutter

Hope I'm not spamming, but I would also like to have better integration with tensorflow lite, not going through JNI, that would be great for video operations

Not looked into it much, but was thinking that might be able to replace the iOS and Android plugins > with a single plugin that talks to C++ directly.

Apart from supporting C++, it will be awesome if there is a plugin which can talk to Go directly. Right now we are talking to Go through gomobile & flutter platform channels which slows down UI responsiveness. Having native support of Go and C++ in Flutter will also help us to maintain uniform code-base (business-logic/algorithm) for multiple platforms.

+1 for native library access.

I'd like to access Vulkan/MoltenVK without having to create platform channels for Android/iOS and maintain two plugins (which would be huge as well). That would allow building 3D applications and render into a Texture widget, whilst only developing in Dart. The platform channels just seem like a hacky workaround. I'd rather like to access native libraries without having to write a wrapper for each platform and maintain them whenever there is a new version for that library.
I think this feature would attract a lot more developers.

Yes, plz direct native library access from flutter.
I would like to use some c++ library at flutter.

Yes, plz direct native library access from flutter.
I would like to use some c++ library at flutter.

We are now at a point where we would like to offer an early preview to get some feedback.

For details, please see the update in the Dart tracking bug.

@mit-mit Will this help with this issue: can I call or use python library with flutter?

Late to the party, but +1 for SQLCipher @dcharkes @mraleph

@doc-rj we are now at the stage where you should be able to experiment with binding SQLCipher and give us feedback on your experience. See this comment.

I would like to stress that we are not really aiming to provide any specific library bindings ourselves - because requests are extremely diverse, but we aim to make it possible for everybody and anybody to bind to any library with a C API.

I guess the need for this increases now that multi-platform has been announced.

Is this part of any roadmap?

@felemedeiros the work is in progress - if you have a library you want to bind to using FFI I strongly suggest to start working on the bindings to provide us feedback. See this comment for for info.

Not looked into it much, but was thinking that might be able to replace the iOS and Android plugins > with a single plugin that talks to C++ directly.

Apart from supporting C++, it will be awesome if there is a plugin which can talk to Go directly. Right now we are talking to Go through gomobile & flutter platform channels which slows down UI responsiveness. Having native support of Go and C++ in Flutter will also help us to maintain uniform code-base (business-logic/algorithm) for multiple platforms.

I wrote an article on how we are currently calling Go library API from Flutter. It might be useful for someone interested. https://medium.com/@archan.paul/using-go-library-in-flutter-a04e3496aa05

How can I add c++ code on Flutter app?

How can I add c++ code on Flutter app?

I guess right now only option is to take C++ -> JNI (for Android) -> PlatformChannel way till we have more elegant way to do the same!!

I created a project called ezored (http://ezored.com). Will be nice if i can pass complex objects to Flutter without need convert to other thing, since it is already in java and objc. Anyone can use ezored to generate the SDK (or download prebuilt) to test Flutter integration between native and Dart. It has requests, parsing, crud using database and lot of things in demo SDK already implemented.

I search in flutter groups but don't have any way to pass the objects and list of objects to Flutter direct.

Thanks in any help.

Any new progress? It seems that more than 2.5 years have passed...

@fzyzcjy we're working on it. We've released an early preview. See https://github.com/dart-lang/sdk/issues/34452#issuecomment-482136759 on how to get involved.

Since this early preview we've added support for Intel 32, Arm 64, and Arm 32. These platforms are not yet released on stable or dev, they are only available on the master branch of the Dart sdk. Progress is being tracked here.

@dcharkes So happy to hear that! Thanks for your great work!

Any Progress?

For status updates and additional information, please see https://github.com/dart-lang/sdk/issues/34452. The top-most comment there has the most recent update.

When using flutter to create a web app, will using ffi with a c library be possible?

When using flutter to create a web app, will using ffi with a c library be possible?

That is not likely. Theoretically longer-term it could be supported using WebAssembly, but that is not something we are currently working on.

@mit-mit really ？

When using flutter to create a web app, will using ffi with a c library be possible?

That is not likely. Theoretically longer-term it could be supported using WebAssembly, but that is not something we are currently working on.

Why would it require WebAssembly? If you can ask people to rebuild to WebAssembly in the future, you can ask them to rebuild to ASM.js now.

@nic-hartley It's good idea, but the challenge is not how to compile the native code, it's in creating the bridge between Dart (compiled as JS) and the native code, whatever form it takes.

The native FFI is very low-level for performance reasons and cannot easily be translated into asm.js or WebAssembly.

To clarify, I mean that our implementation is very low-level -- it's certainly an interesting feature, but it would take considerable work to deliver.

flutter is only a toy until it supports c++

I've come here to echo the same points by others, that until Flutter can easily interop with C++ (with no bridge library, and no performance penalty) it will never be adopted by large scale applications with investments in existing native libraries, or applications where performance is the highest priority.

I'll note that even React Native uses a bridge currently, so it appears that Flutter is actually ahead-of-the-curve in terms of trying to implement a FFI.

Integration with C++ is trivial on iOS with AppKit. That's what we should be comparing against, not React Native.

UWP & C++ is trivial too.

I'm in general for "support Dart FFI effort" party too, though...

Xamarin might be a more appropriate comparison than UWP, but Xamarin's cross platform views weren't nearly as customizable as Flutter's and often required a lot of native code to get looking decent.

This is not true. Unlike Flutter, Xamarin has platform bindings to native API (i.e. Xamarin.iOS and Xamarin.Android), and it's easy for app developers to write platform-specific implementation in its own language (C#/.NET). This issue is about language feature and should not be mixed with UI widget API design.

There is a lot of native API uses, but no native code invocation, where Flutter would be on the same boat (although Xamarin does not require writing Java or ObjC there, with no reflection hack in app code). For native code, even at Xamarin.Android itself (one of the backend platform backends) the use of native code is very little, and app developers write no native code.

And unlike React Native or Xamarin, Flutter is to provide its complete framework, so it is entirely fair point of view that we compare the entire Flutter framework with things like AppKit.

its weird that noone even mention Qt framework which is far ahead everything else regarding C++ integration

QT is C++. And has an unfavorable license to begin with.

On Mon, 12 Aug 2019, 06:41 Vladyslav Stelmakhovskyi, <
[email protected]> wrote:

its weird that noone even mention Qt framework which is far ahead
everything else regarding C++ integration

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/7053?email_source=notifications&email_token=AGDYMWXHTJUBUW64LEOO27TQEDSWNA5CNFSM4CXY6LYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4BRVYA#issuecomment-520297184,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGDYMWTNMTM7QUOY2BEIPM3QEDSWNANCNFSM4CXY6LYA
.

Qt is C++ and QML (JS engine)
What license? LGPL? GPL? what is wrong with it?

First off IANAL, but as I understand it most of Qt is LGPL (the IDE etc are GPL), which means that it has language that while not expressly forbidding static linking, makes it difficult to do while still adhering to the licence if your application is closed-source.

Technically, if you use only LGPL and provide your object files (and probably instructions) so that users could potentially re-link against a different version of the library, you're satisfying the requirements of the LGPL. But I'm pretty sure the Qt Company doesn't advertise that fact, so the common conception is that you can't deploy static libraries which means you can't get your app released on the app store without paying their extortionate licensing fees. And I may be wrong about providing object files, that's just my understanding of it, and I don't know if any companies are doing that.

Android is easier because it does allow dynamically loaded libraries which are more explicitly allowed under the LGPL, but in all honestly static linking would probably be preferable there too to keep the app size down which means running into the same issue.

Hi @cpboyd , I think I'm looking at this from the opposite direction. We already have apps built on platform specific UI frameworks, where each platform allows us to utilise our vast collection of existing C++ libraries. I understand Flutter is cross-platform, which is great, but unless I can actually use it (with my existing code), then I'm better off just sticking with non-cross-platform UI. The only sticking point comes when a future OS (e.g. Fuchsia) requires the use of Flutter & Dart, but doesn't allow for this use-case. In that case it's likely to be ignored by anyone with large existing codebases.

I guess I'm not sure whether Flutter / Dart are being designed with "web" apps (i.e. where backends are on the web) in mind, or serious consideration is being given to the needs of professional desktop application developers. Ultimately decisions like this can affect the number of, and quality of, many applications on an app store. If I can write a high quality professional app for iOS using UIKit, utilising millions of lines of existing code, but I can't (with near-zero performance cost) if I'm developing for Fuchsia / Flutter / Dart, then that would be an OS & platform that I wouldn't develop for.

The aim of my posts is not to compare Flutter to other cross-platform or non-cross-platform libraries, it's to highlight use cases that are important to a subset of developers.

The Dart FFI is interesting, from the _very_ brief read of the sqllite example, it looks similar to C# with PInvoke, but unfortunately that's not suitable for C++, as either nearly every type you deal with would need wrapping, or you would have to write some fully generic type-less interface system to wrap the C++. Neither of those are particularly appealing when you compare it to the ease of the following Obj-C class:

#include <mylib/mytype.h>
@implementation MyView
{
    MyLib::MyType *_pMyType;
}
@end

Or UWP with C++/WinRT:

#include <mylib/mytype.h>
class MyUserControl : public UserControl
{
    MyLib::MyType *_pMyType;
};

Thanks :-)

@Hixie @MarkIngramUK Neither of those are cross-platform, which was my point.
AppKit is Apple-only, while UWP is Windows-only.
Perhaps if Flutter had used Swift or C# instead of Dart, then we'd already have the same level of support, but that's an entirely different argument.
Xamarin might be a more appropriate comparison than UWP, but Xamarin's cross platform views weren't nearly as customizable as Flutter's and often required a lot of native code to get looking decent.
My suggestion still remains: If you want to use Flutter with C++, you should participate in the Dart team's FFI preview and help improve support for all of us 😃

This issue is about language feature and should not be mixed with UI widget API design.

@atsushieno Sure, and that's why this discussion would be more productive on the Dart FFI forum... Flutter is the framework. Dart is the language.

Neither of those are particularly appealing when you compare it to the ease of the following Obj-C class:

@MarkIngramUK I'm sure that's exactly the kind of feedback that the Dart team would love to see over at https://groups.google.com/forum/#!forum/dart-ffi

I have a project called ezored (https://ezored.com) that is a C++ bootstrap project for SDKs and applications in C++. We are using in mobile projects (android and iOS). Im waiting for FFI be finished to create a project that will use the default SDK into flutter.

We don't have any problems with C++ and the time of dev new features are reduced, since the SDK has the same code into all platforms, as you can see in the default implementation (poco project, openssl, sqlite, specific platform code integrated with bridge code etc).

In my option this is the best way:

• iOS and Android with C++ backend (ezored)
• Flutter and C++ as backend

Feel free to add a start to the project :)

Kotlin Multiplatform could be a workaround, not perfect thought. Still need to wait for https://github.com/dart-lang/sdk/issues/34452

Unity3d seems is somehow porting flutter to their engine which is based on C# VM [1] - in that world talking between C# and C++ is decent. Maybe worth to take a look at their repo how they solved some issues. They state: "UIWidgets is mainly derived from Flutter". I would also have a look at react native camp and their new approach with TurboModules - their solution might have edge over flutter approach since will be
1) both synchronous and asynchronous and
2) there won't be any marshalling and
3) will support not only C but C++

I'm cheer-leading both camps.

[1] https://github.com/UnityTech/UIWidgets

As of Dart 2.5, this (dart:ffi) is now in preview:
https://medium.com/dartlang/announcing-dart-2-5-super-charged-development-328822024970

Great news!

Mmm... Will it be enough to use Oboe with Flutter?..

https://github.com/google/oboe

@rg4real Yep! But, you'll need to write some C wrappers since the Oboe interface is in C++.

You can see https://github.com/flutter/flutter/wiki/Binding-to-native-code-via-FFI for instructions on getting started.

You can reuse my oboe-c.so that I wrote for my C# bindings, if that works https://github.com/atsushieno/oboe-sharp/tree/master/native

@sjindel-google , that are some awesome news!

So I need to create a bridge between C++ and C code by creating classes and functions. And then I can use that classes and call that function from a Dart code. I think that's right.

@atsushieno , thank you. I am taking a look. I am not sure how to make bridges in my case (lack of experience). But did you manage to achieve your overall goal of precise playing with oboe? Was it that good?

@rg4real I was doing that merely for simpler API (compared to OpenSLES) than low latency audio. If I were really serious about latency then I wouldn't use Xamarin.Android. If you are talking about Oboe (or AAudio behind it), then I do use it in Fluidsynth and it works well. Not sure "how good" AAudio is compared to OpenSLES though.

Is there any guide on how memory gets managed?

If C++ code creates a memory using new/malloc and returns to dart code, how to free that memory.

c++ code
void foo(char** out) {
*out = new char[25];
}

How delete the memory assigned to |out| variable from dart code?

If you're on Dart 2.5, there's a .free() on Pointer. If you're on dev/master branch this method moved package:ffi https://github.com/dart-lang/ffi/blob/master/lib/src/allocation.dart#L70.

As per comment - "It may only be used against pointers allocated in a manner equivalent to [allocate]." - free() can be used only if memory is allocated using allocate() method.

e.g.
ffi.Pointer ptr = ffi.Pointer.allocate();
ptr.free();

Does this take care of freeing memory which is allocated in C++ side using either new or malloc from dart code?

As long as the memory was allocated through malloc, either via Dart or C++, it can be freed with free.

In Dart 2.6 we use DynamicLibrary.lookupFunction("free") to define free in Dart, so it will be exactly the same free as in the C++ part of the program. (Unless you're linking in multiple versions of free into your binary.)

Closing this issue as this feature is now generally available (in beta) in all Flutter channels. We're continue to improve the issue. For any detailed issues, please file them in https://github.com/dart-lang/sdk/issues/new.

making c++ classes to c compatibility is messy. plz make capability to directly call c++ classes

+1 Can we have C++ support?

@KaungZawHtet and @fzyzcjy - please consider opening a new issue (probably in dart-lang rather than flutter) for this.

I'm going to lock this issue - there are a lot of people subscribed to it, but it's original goal is pretty clearly resolved.

Yes, for new issues, please file them using this link: https://github.com/dart-lang/sdk/issues/new?labels=library-ffi,area-vm