Flutter: Prise en charge de l'intégration avec C/C++ dans le framework de plugin

@jason-simmons en sait le plus sur Gradle. Une fois que nous avons un .so, je peux certainement aider à le charger.

J'ai trouvé que sous buildSrc il y a une autre propriété pour définir la version de build gradle. Après la mise à jour vers 2.2.2, j'ai progressé et j'ai pu vérifier que le .so se charge et qu'il est appelable à partir de Java.

Vraisemblablement, nous aurions également besoin d'ajouter une API C pour envoyer des HostMessages du code C/C++ à Dart.

Oui s'il vous plaît. Je soupçonne que le rappel C-> Java n'est peut-être pas bon marché.

Une mise à jour pour ceci? Considérer Flutter pour créer une application multiplateforme qui appelle du code C++ compilé dans une bibliothèque partagée, et c'est le seul point d'arrêt majeur.

C'est possible aujourd'hui (et @jtrunick l'a fait dans son application d'expédition), mais vous devez d'abord passer par Java ou Obj-C.

c'est-à-dire que vous pouvez utiliser https://flutter.io/platform-channels/ pour parler de Dart à Obj-C/Java, puis d'Obj-C/Java appeler dans votre code C++. Ce bogue couvre l'ajout d'une prise en charge plus directe pour cela et évite potentiellement le passthrough Obj-C/Java.

Étant donné que Dart VM est implémenté en C++, ne devrait-il pas y avoir un moyen plus simple (quoique moins sûr) d'appeler directement les bibliothèques partagées C (par exemple via dlopen) ? Quel changement faudrait-il pour une assistance de base (dangereuse/expérimentale) ?

Est-ce que quelque chose comme ça : https://www.dartlang.org/articles/dart-vm/native-extensions est disponible sur android ou ios ?

Nous avons entendu cette exigence dans quelques applications Google :

• Une de ces applications a écrit ses propres bibliothèques C++ pour faire fonctionner la caméra afin de réduire la latence. Ces bibliothèques sont spécifiques à la plate-forme et optimisées pour fonctionner le plus rapidement possible. L'appel de ces bibliothèques avec la latence la plus faible possible est essentiel pour de telles applications. Les forcer à passer par PlatformChannel + JNI n'y parviendra pas sur Android.

• Il existe des équipes mobiles avancées qui écrivent des composants de logique métier en C++ pour pouvoir les partager entre leurs implémentations Android et iOS. Flutter prenant en charge l'intégration directe avec ces bibliothèques consoliderait davantage sa position d'être le meilleur framework multiplateforme sur le marché.

Je ne pense pas que ce soit un _must have_. Cependant, c'est un domaine dans lequel Flutter peut se différencier davantage des autres solutions multiplateformes.

Une de ces applications a écrit ses propres bibliothèques C++ pour faire fonctionner la caméra afin de réduire la latence. [...] Les forcer à passer par PlatformChannel + JNI n'y parviendra pas sur Android.

Quelle était leur solution sur Android pour passer de C++ à Java et vice-versa ?

Si cela est vraiment nécessaire, nous pouvons autoriser les extensions natives de Dart sur les plateformes mobiles. Pour le moment, nous n'exposons pas les symboles dans dart_api.h . Nous devrons décider de ce qui suit avant de pouvoir basculer le commutateur :

• Découvrez comment informer le compilateur AOT du code Dart dont le seul point d'entrée provient d'une méthode qui peut ne pas se trouver dans la bibliothèque dynamique principale du moteur Flutter. Sinon, la passe de secouage d'arbre peut se débarrasser du code.
• Fournir des conseils sur la création et l'empaquetage d'extensions natives (Gradle et Xcode pour Android et iOS respectivement).
• Fournir des garanties de stabilité ABI pour les routines dans dart_api.h . Bien qu'il soit pour la plupart stable, je pense qu'il continue d'évoluer pour tenir compte des différents modes.

Jusqu'à présent, le mécanisme des canaux des plates-formes semble avoir été adéquat pour les cas d'utilisation les plus simples.

Quelle était leur solution sur Android pour passer de C++ à Java et vice-versa ?

Je n'ai pas examiné en profondeur leur cas d'utilisation. Il semblait qu'ils aient écrit tous les bits nécessitant une communication à très faible latence en C++. Je vais leur demander s'ils utilisent des JNI pour des cas d'utilisation critiques en termes de performances (mon intuition est non).

Cela dépend vraiment de ce que nous pouvons faire du côté de Flutter. Si nous pouvons fournir un interop beaucoup plus rapide que JNI, ce serait une grande victoire pour ces équipes. Ils peuvent réduire leur base de code C++ et passer davantage du côté de l'application. Si nos performances d'interopérabilité sont comparables à celles de JNI, je ne vois pas de grande victoire ici. Ils pourraient probablement continuer ce qu'ils font maintenant et utiliser PlatformChannel.

Il s'agit de donner à ces équipes une raison supplémentaire de passer à Flutter. Je n'ai pas entendu parler de cela comme un bloqueur, alors priorisez en conséquence.

Si je comprends bien ce que vous dites, vous dites que les solutions actuelles consistent à avoir toute la logique (caméra + interface utilisateur) en C++ avec un minimum de logique en Java, et le désir est de déplacer la partie interface utilisateur de cette logique vers Dart, sans perdre l'interface utilisateur à faible latence<->interactivité de la caméra.

Pouvez-vous nous parler de leur situation de threading ? Ont-ils juste un fil pour appareil photo + UI ?

@chinmaygarde pourrait nous rapprocher de la résolution de ce problème avec son travail actuel sur l'API d'intégration.

+1

Des progrès avec ce problème?

Nous avons déjà utilisé djinni pour partager des logiques sur différentes plateformes. Ce serait formidable si nous pouvions avoir une interopérabilité entre Dart et C++, plutôt que d'avoir à faire des allers-retours via Java/Objc-C.

Si Dart peut s'intégrer à C/C++, je pense que c'est une excellente idée pour le mobile de réutiliser une tonne de bibliothèque native et sans avoir besoin de se lier à une plate-forme spécifique en utilisant JNI ou Objective C++.

Avez-vous pensé à https://github.com/mono/CppSharp ? Ils ont déjà l'analyse et l'AST en place pour c++, ainsi que la prise en charge de plusieurs langages cibles. Peut-être pourriez-vous créer un générateur de Dart pour CppSharp ?

L'intégration d'une base de données basée sur C++ comme Realm directement dans C++ permettrait d'obtenir une augmentation significative des performances et de la productivité des développeurs :-) Monter/descendre via JNI serait un tel gaspillage.

J'envisage Flutter pour une application AR faisant de la vision par ordinateur (probablement en utilisant OpenCV), et une interopérabilité Dart-C++ efficace et directe serait un point positif majeur. J'imagine que beaucoup d'autres personnes faisant des applications difficiles en termes de calcul pourraient partager ce besoin.

Quelqu'un peut-il confirmer que l'interopérabilité C++ n'est toujours pas disponible ? Est-il possible de le faire en utilisant des packages ?

L'interopérabilité @tofutim Direct c/c++ n'est toujours pas disponible, c'est pourquoi ce problème est toujours ouvert. Cependant, vous pouvez utiliser des canaux de plate-forme, puis utiliser Obj-C/Java pour interagir avec votre code C++. Ce n'est pas génial mais c'est tout ce que nous avons pour le moment.

Quelqu'un peut-il confirmer que l'interopérabilité C++ n'est toujours pas disponible ? Est-il possible de le faire en utilisant des packages ?

Pour interagir avec les bibliothèques de la plate - canaux de la forme est toujours la recommandation actuelle.

Un mécanisme plus performant décrit dans le document sur les extensions natives peut être ajouté de manière triviale. Cependant, je ne suis au courant d'aucune garantie de stabilité ABI pour les symboles exposés à partir de dart_api.h . Si @a-siva et @eseidelGoogle peuvent confirmer que de telles garanties existent, je peux commencer à exposer ces symboles dès que possible. En option, nous pouvons ensuite créer un sous-ensemble de Tonic en tant que wrappers pratiques autour de l'API C pour une utilisation facile à partir de C++.

D'après ce que je comprends, ce bogue consiste à fournir une API C et des crochets d'outils pour faciliter l'obtention d'un plugin entièrement C/C++ (aucun shimming Obj-C/Java requis, mais toujours asynchrone via platform_channels).

Je ne pense pas que nous devrions envisager des méthodes synchrones comme les extensions natives pour le moment. (Mais honnêtement, je m'en remets à @Hixie ou @cbracken).

@eseidel

Je ne pense pas que nous devrions envisager des méthodes synchrones comme les extensions natives pour le moment

pourquoi donc?

L'approche actuelle pour appeler le code C est Dart -> Java -> C
On croise JNI deux fois, non ?
première fois : dart à Java via les canaux de la plate-forme (sous le capot, appel JNI utilisé, non ?)
deuxième fois : Java -> C via JNI

A titre d'exemple, du point de vue des besoins de mon projet, avoir accès à dart_api.h même sans garantie de stabilité (comme fonctionnalité expérimentale par exemple) serait déjà suffisant. Ma principale préoccupation est de déplacer de gros blocs de données binaires (images) du côté Dart vers le côté C et inversement sans trier et idéalement copier. Unity/Mono y parvient .

D' après le numéro 31960 de dart-sdk, je comprends que l'implémentation actuelle des isolats pourrait ne pas permettre de transmettre des données sans copier (bien qu'en théorie, il devrait être possible de détecter que le tampon créé dans l'isolat A n'est plus utilisé après avoir été transmis à l'isolat B et donc sa propriété peut être transférée, sans copier... aucun plan sur ce front ?), mais si au moins dans un isolat il n'y a pas de regroupement vers/depuis C ce serait bien.

Le marshalling pourrait être évité avec les flatbuffers qui devraient bientôt arriver : https://github.com/google/flatbuffers/pull/4676
Ou avec des messages protobuf utilisant un champ à un seul octet.

Bien sûr, cela implique de grandes quantités de copie d'octets, ce qui n'est pas idéal pour tous les cas d'utilisation.

J'entends au moins trois désirs différents présentés ici :

1. J'aimerais un moyen d'écrire facilement un plugin pour Flutter en utilisant uniquement du code C/C++ sans avoir à ajouter un tas de colle Java/Obj-C (c'était ma compréhension originale de ce bogue et quelque chose que je pense vraiment que nous pourrions/devrions faire) .
2. Aimerait un moyen de déplacer un grand volume de données dans/hors de Dart rapidement/avec une faible latence/etc. (Vraisemblablement à partir d'une variété de langages, y compris C++. Cela ressemble à un cas très valable ! Je recommande fortement de déposer un bogue séparé comprenant un exemple.)
3. Souhaitez-vous un moyen d'étendre Dart avec des appels/objets synchrones ? (Par exemple, des extensions natives ou d'autres méthodes ? C'est également tout à fait faisable. Il existe des difficultés potentielles autour de la stabilité de l'API, et je pense que nous voudrions en savoir plus sur le cas d'utilisation spécifique avant d'agir.)

Mon retour de lecture de ce qui précède est que nous devrions envisager de séparer quelques bogues supplémentaires. Nous devons certainement investir dans l'interopérabilité C++, mais il est difficile de déterminer à partir de ce long fil de discussion quels cas d'utilisation exacts nous devrions aborder et dans quel ordre ?

Les parties intéressées seraient-elles disposées/capables de signaler de nouveaux bogues avec leurs cas d'utilisation souhaités et de les lier ici ? Heureux de laisser ce problème ouvert pour suivre l'intérêt général dans cet espace de problème.

En ce qui concerne les performances et 2. ci-dessus : bien que je sois certain que les performances de platform_channels de Flutter pourraient être améliorées (et que nous aurons probablement besoin d'autres méthodes de plugin/inter-op pour couvrir tous les cas d'utilisation), nous aurons besoin de quelques cas d'utilisation (peut-être existent-ils et je ne les ai pas vus ?) Mon expérience avec l'optimisation des performances des systèmes est que mon instinct est souvent erroné. Même si des choses comme JNI ou platform_channels semblent être des goulots d'étranglement potentiels, nous ne le saurons pas tant que nous n'aurons pas mesuré.

Merci encore à tous pour votre aide et vos retours !

J'aimerais un moyen d'écrire facilement un plugin pour Flutter en utilisant uniquement du code C/C++ sans avoir à ajouter un tas de colle Java/Obj-C (c'était ma compréhension originale de ce bogue et quelque chose que je pense vraiment que nous pourrions/devrions faire) .

cela donnerait également une meilleure intégration de sqlite pour flutter + il existe des tonnes de bibliothèques C / Rust pour crypto, ssh et autres. Ce serait cool de pouvoir l'utiliser facilement.

@eseidel

J'entends au moins trois désirs différents présentés

Mon vote pour 1.)

À la lecture de la documentation Flutter, il devrait être assez "simple" d'étendre les canaux de la plate-forme pour prendre en charge C.
La seule nouveauté serait probablement un moyen de charger des _objets partagés dynamiques_ dans le processus actuel.

J'imagine que l'utilisation d'_Android-C_ ressemble à quelque chose comme :

#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)
}

Conceptuellement, au moins pour _Android-C_, vous devrez décider comment gérer la combinaison de Java et C.

@eseidelGoogle
Nous exposons actuellement le code golang via les wrappers Java et swift et la latence est un problème appréciable que nous rencontrons.
Pourquoi ?

• Nous devons partager la logique métier entre de nombreuses plateformes.
• Pour les fonctionnalités de vidéo et d'image comme le partage d'écran.
• Pour DB.

Si vous pouviez ajouter un support de golang au niveau direct, cela ferait une différence de câlin !
La compilation de code golang pour mobile est également très simple sans aucune magie LDFLags, donc je pense que ce serait populaire. Je connais quelques autres codeurs de golang qui utilisent également actuellement les canaux de méthode.
En ce qui concerne la sérialisation, nous utilisons actuellement des Protobufs et des flatbuffers.

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

En fuchsia, cela se fait avec FIDL et il a des fixations en c, rouille et golang.
C'est assez génial à utiliser et j'ai aimé essayer la rouille et le golang sur une carte intégrée.

Il devrait être possible d'exposer les éléments fidl via iOS et Java également.
Cela donnerait une belle rampe d'accès entre le fuchsia et le flutter sur les mobiles et les ordinateurs de bureau.
Juste une idée avec laquelle je joue

@eseidelGoogle
Hiixe m'a dit que FIDL ne peut pas être fait au niveau Flutter car FIDL repose sur le code du noyau de zircon en Fuchsia. Ainsi, la seule façon de reproduire la fonctionnalité de style FIDL IPC dans Flutter serait d'écrire une version FIDL dans le moteur Flutter. Mais ensuite, je jouais avec et j'ai remarqué que c'était assez similaire à Flatbuffers. Alors pourquoi ne pas simplement utiliser FlatBuffers pour la couche de sérialisation entre le Flutter et le cpp ou le golang ou la couche de rouille sur Flutter. ?

Juste +1 à ce sujet, nous avons une application flottante utilisant une bibliothèque appelée Superpowered. Superpowered est écrit en C++, nous utilisons ensuite des éléments de type java et JNI pour interagir avec lui, que nous utilisons à leur tour des canaux de plate-forme pour parler avec le code Java. Ce serait certainement bien si nous pouvions sauter l'homme du milieu.

Cela empêche également les bibliothèques mobiles populaires comme Realm de créer des versions flottantes, car leur noyau est écrit en C/C++ et elles ne veulent pas non plus avoir à faire à un intermédiaire java/objc/swift.

Pour ces raisons, mis à part la stabilité générale, je pense que ce problème est l'un des changements les plus nécessaires en ce qui concerne le flottement en ce moment. (Plus précisément n°1 sur la liste de @eseidelGoogle .)

Si vous voulez entendre un argument pour contourner Java/JNI dans les extensions de plate-forme (c'est-à-dire pas seulement pour masquer/automatiser la couche de colle Java pour le développeur), Superpowered a beaucoup à dire sur ce sujet : https://www.youtube. com/watch?v=LzIuir3r6Co

@pnico Pouvez-vous expliquer en quoi cela fait valoir que Java/JNI devrait être bipassé ? Cela semble dire peu plus que votre code de traitement audio devrait être écrit en C++. (Ce qui ne veut pas dire que vous ne pouvez pas l'appeler via le JNI ou par tout autre moyen)

@csga5000 vous avez tout à fait raison, cela n'avait aucun sens :D JNI n'affectera probablement pas vraiment les performances à moins que vous n'essayiez de faire des choses plus ésotériques. Je suppose que cela se résume vraiment à la commodité/maintenabilité, et je suppose que peut-être la possibilité de déplacer plus de code spécifique à l'application de Java/C++ vers Dart

Je pense que @pnico dit qu'il PEUT l'appeler via JINI, mais que le JINI ajoute trop de latence.
C'est donc la perf qui pose problème.
Oui Non ??

Celui-ci pourrait faire une énorme différence, principalement pour les travaux liés à la cryptographie.

Je suppose aussi pour Android Things, bien que je n'aie pas vu ou fait d'expériences
et des repères pour gpio sensible au timing dans ni c ni dart pendant plus d'un
année.

Le samedi 9 juin 2018, 10:52 Eddy WM, [email protected] a écrit :

Celui-ci pourrait faire une énorme différence, principalement pour les travaux liés à la cryptographie.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/flutter/flutter/issues/7053#issuecomment-395927258 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AFHMcSI2JDHbgv3iYrStDN5mlzkQ8XEkks5t6xxMgaJpZM4K-PLw
.

Des progrès depuis ?

Jusqu'à ce que ce problème soit résolu, existe-t-il une recommandation pour un exemple de plugin flutter qui montre comment intégrer ac/c++ lib ? Est-ce que Djinni est une bonne voie à suivre ?

Jusqu'à ce qu'il soit résolu, le seul moyen d'intégrer l'écriture c/c++ du code natif android et ios, puis l'interfaçage avec le code dart en utilisant les canaux de la plate-forme

J'ai implémenté des plugins qui utilisent des canaux de plate-forme (vers les fichiers jar et CocoaPods). Je recherche un exemple de plugin qui montre comment s'intégrer à la même bibliothèque c/c++ (pour Android et ios). Des recommandations ?

@ mmcc007 C'est comme ça que vous le faites en Java ou 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

Vous pouvez voir à quel point superpowered vous recommande de le faire si vous voulez vraiment un exemple (c'est juste un exemple que je connais): https://github.com/superpoweredSDK/Low-Latency-Android-iOS-Linux-Windows-tvOS-macOS- Plateforme-Audio-Interactive
Voir les exemples de dossiers. Ex, dans https://github.com/superpoweredSDK/Low-Latency-Android-iOS-Linux-Windows-tvOS-macOS-Interactive-Audio-Platform/tree/master/Examples_Android/SuperpoweredRecorder/app/src/main il y a java/com/superpowered/recorder/MainActivity.java qui fait référence au code dans cpp/RecorderExample.cpp

@csga5000 Il semble que ce serait raisonnablement simple .. lors du premier examen. Ce serait quand même bien de regarder à travers un plugin flutter fonctionnel. Merci.

+1 pour cela. Tout exemple fonctionnel d'une application flutter utilisant c++ serait bien reçu

Il y a un projet qui fait ça pour le golang et je pense la même approche
peut aussi être utilisé pour c++.

Le programme golang utilise jsonrpc.
Ensuite, tout ce que vous avez à faire est de créer votre propre code golang avec jsonrpc.

Ensuite, tout est très facile.

Je pense que les canaux de plate-forme prennent UNIQUEMENT en charge JSON en tant que sérialisation agnostique
formater ?

Le mer. 18 juillet 2018, 16:50 Jefferson Bledsoe, [email protected]
a écrit:

+1 pour cela. Tout exemple fonctionnel d'une application flutter utilisant c++ serait
bien reçu

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/flutter/flutter/issues/7053#issuecomment-405958345 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ATuCwkPbb9vLdoaEwM-bLhYPZxtyQ5Vjks5uH0sqgaJpZM4K-PLw
.

Salut, des nouvelles ?

Vous voulez juste savoir si quelqu'un dans ce fil a réussi à intégrer la bibliothèque Superpowered directement dans une application flutter ?

Oui @skills-up nous l' avons fait. Mais pas dans un projet open source donc je ne peux pas le montrer. Mais si vous voyez mes conseils plus tôt, c'est comme ça que vous le faites. Vous devrez peut-être créer votre application flutter pour chaque architecture de processeur.

Je comprends que vous l'avez fait via JNI/Java et non directement depuis Dart. Je me demandais s'il était possible d'éviter complètement le code spécifique à la plate-forme.

Vous devrez peut-être créer votre application flutter pour chaque architecture de processeur.

Vous voulez dire une application distincte pour chaque architecture, ou simplement spécifier toutes les architectures prises en charge ?

BTW, nous avons déjà une application fonctionnelle écrite nativement en Java. Cependant, maintenant que nous devons également créer une application iOS, je me demandais si en créer une en flutter (au lieu de déployer des efforts sur Swift/XCode) aurait plus de sens du point de vue de la maintenabilité future, avec l'avantage d'une base de code unique.

Bien. Realm attend que vous fournissiez un moyen : https://github.com/realm/realm-object-server/issues/55

lukaspili : Je suppose que tout le monde attend toujours : flutter/flutter#7053
bmunkholm : @lukaspili Oui, c'est une condition préalable à coup sûr.

Pour ce que ça vaut, j'attends ça aussi. Je ne peux pas vraiment envisager de remplacer les applications XF par flutter idem jusqu'à ce que vous ayez la plomberie appropriée. Dans l'état actuel des choses, Xamarin souffle hors de l'eau dans ce département.

En retard à cette fête mais un gros +1 pour ce fil.

Je développe des applications de bureau, ma vue comme une ligne de code (pour le bureau) :

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

Si Flutter peut offrir un support de première classe pour C++, je pense que son approche générale pourrait être un gagnant absolu pour le développement d'applications multiplateformes, pas seulement une "première mobile" mais une première mondiale. Qt est cher pour les petits développeurs, est opiniâtre et n'embrasse pas le C++ moderne et rien ne rivalise vraiment, Flutter pourrait-il manger au moins une partie de sa tarte à l'interface utilisateur?

PS : je ne suis pas anti-Dart, c'est un autre nouveau C#/Go/Rust/etc. langage concurrent qui peut être super productif pour une nouvelle plate-forme, mais le monde des applications de bureau hautes performances (ce qui m'intéresse ici) est fermement C++, avec une prise en charge étendue des systèmes d'exploitation et des bibliothèques, un langage qui avance à un rythme effréné lui-même (ce n'est pas C), et je pense que Flutter le mérite !

Je ne pense pas que Flutter supportera le C++ dans un avenir proche, et ce n'est certainement pas possible maintenant. Et pour ma part, je préfère énormément Dart - écrire des applications en C++ même avec un flottement demanderait beaucoup plus d'efforts. Et je ne pense pas que C++ se traduise directement par la prise en charge du bureau, ils devraient quand même écrire pas mal de code, et la machine virtuelle dart devrait fonctionner de toute façon pour le bureau. Je pense que les performances sont négligeables pour la plupart des applications.

Je pense qu'en fin de compte, Google veut prendre en charge l'interopérabilité afin que vous puissiez écrire des applications flottantes pour toutes les plates-formes en utilisant toutes les langues prises en charge ou même une combinaison de ces langues. Mais je ne m'attendrais pas à ce que bien quand ou après la sortie de Fuchsia. Pour l'instant, leur objectif est de faciliter l'écriture de code une seule fois. Dart correspond à cet objectif car il est facile à utiliser/apprendre, efficace et de toute façon l'un des langages de Google. Je ne vois vraiment aucun avantage pratique pour l'utilisateur moyen d'avoir un support C++ de première classe. Les performances sont négligeables dans une application mobile, et l'utilisation de canaux de plate-forme avec C++ serait pratique pour interagir avec les bibliothèques C++ existantes. Du côté positif, vous pouvez être certain qu'ils ont finalement l'intention de faire en sorte que le flutter prenne en charge le bureau (enfin, à tout le moins, le capybara de Fuchsia, mais je doute qu'ils s'arrêtent là).

Ce fil de discussion concerne la prise en charge de l'intégration directe avec C++ à partir de dart/flutter, qui, espérons-le, pourrait arriver dans un proche avenir.

Je ne pense pas que Flutter prendra en charge le C++
Je ne vois vraiment aucun avantage pratique pour l'utilisateur moyen d'avoir un support C++ de première classe.

Il ne s'agit pas de savoir à quel point Flutter/Dart est génial par rapport à C++, mais plutôt du point/de la facilité des intégrations dont vous avez besoin pour s'adapter à l'écosystème actuel. Il existe une longue liste de bibliothèques en tant qu'objet partagé (OpenCV pour n'en nommer qu'une) qui sont la norme de l'industrie, vous ne pouvez pas vous attendre à ce que les gens les réécrivent dans Dart ?

Les performances sont négligeables dans une application mobile, et l'utilisation de canaux de plate-forme avec C++ serait pratique pour interagir avec les bibliothèques C++ existantes.

Bien au contraire, utiliser des canaux est sous-optimal dans ce contexte, pensez aux cas d'utilisation où vous devez travailler avec un gros objet binaire sur la mémoire (images), vous auriez besoin soit de :
1- Copiez ces binaires depuis/vers la mémoire C++
2- Travailler avec JNI pour s'interfacer avec la bibliothèque (et gérer les pointeurs alloués dynamiquement à ces binaires)
sans parler des frais généraux liés au coût des valeurs/paramètres de sérialisation/désérialisation que vous encourez en utilisant les canaux.

Un bon framework est un équilibre entre les nouvelles fonctionnalités/paradigmes qu'il introduit et la facilité d'intégration avec l'écosystème/l'héritage actuel, dont nous ne pouvons nier que C++ fait partie.

@nhachicha @csga5000 ne être utilisé directement à partir de C++ , comme dans, sans avoir besoin de code Dart.

Les performances sont négligeables dans une application mobile, et l'utilisation de canaux de plate-forme avec C++ serait pratique pour interagir avec les bibliothèques C++ existantes.
@nhachicha Je ne pourrais pas être plus d'accord.

La vérité est pour les applications qui n'ont pas besoin de performances mordantes (qui sont nombreuses), alors pourquoi ne pas échanger le C++ difficile à maîtriser pour quelque chose de plus productif, en fait pourquoi s'arrêter à Dart seul, pourquoi ne pas insérer l'un de ces super populaires, ( beaucoup plus populaires/établis que Dart) :

• Runtime C#/.Net Core
• Runtime Javascript/Typescript V8 (vous auriez presque un navigateur à ce moment-là, mais alors)
• Rouille (aussi rapide !)
• GoLang
• Python
• [Insérez votre favori ici]...

Et bien que personnellement j'aime et utilise certains de ces langages tous les jours, C et C++ sont au cœur de Linux, donc Android, iOS et des plates-formes de bureau telles que Windows, MacOS et d'autres ordinateurs de bureau. La moitié des langages ci-dessus (y compris Dart) sont écrits en C++. Les technologies de pointe nécessitent à maintes reprises des performances natives optimisées, telles que l'IA (Tensorflow est C++, Caffe C++, Pytorch est C sous Python, etc.), les bibliothèques de réalité augmentée, les moteurs de jeu AAA et tout ce qui doit s'approcher d'un GPU (CUDA , appelé depuis C/C++).

Pour la même raison que le moteur de rendu Flutter est lui-même écrit en C++ (natif, hautes performances, batterie/mémoire/cpu efficace), je pense qu'il serait super de débloquer les meilleures performances possibles, en cas de besoin, sans s'approcher d'un runtime géré et simplement en prenant en charge C++. Cela distinguerait Flutter des autres frameworks tels que Xamarin et Nativescript, qui offrent honnêtement une expérience de développement similaire (ayant utilisé les deux) uniquement avec des langages différents, pourquoi ne pas rendre Flutter spécial plutôt que simplement « celui de Dart » ?

_En passant, je suis totalement à l'aise avec tout écrire en C/C++, de la validation de formulaire aux pixel shaders, mais je ne prétends pas que c'est l'avis de beaucoup de gens qui regardent ce repo - et c'est parce que je trouve C++ un langue très productive - totalement un choix personnel cependant._

C'est l'une des principales raisons pour lesquelles nous avons besoin de l'intégration C++

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

Il existe deux manières simples de procéder à l'intégration C/C++ :

• Fournir une implémentation de canal de méthode en C++
• Fournir la prise en charge des extensions natives Dart VM

Malheureusement, les deux présentent des inconvénients majeurs qui nous empêchent de les poursuivre :

• Les canaux de méthode sont une abstraction de surcharge élevée - tandis que l'intégration C/C++ est requise lorsque des interactions à faible surcharge sont souhaitables. Cela signifie que les canaux de méthode ne résoudraient pas réellement le problème.
• Les extensions natives de Dart VM exigent que les utilisateurs utilisent l'API Dart VM C - il n'est peut-être pas souhaitable d'introduire trop de dépendances externes à ce sujet, d'autant plus que l'API n'a pas bien vieilli et nécessite une refactorisation sérieuse.

Il semble qu'une alternative plus souhaitable soit l'introduction de dart:ffi - un composant central de Dart VM qui permettrait de se lier directement au code natif permettant aux gens d'écrire quelque chose comme :

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);

Nous avions un certain intérêt à mettre en œuvre un FFI comme celui-ci depuis longtemps - je m'attendrais à ce que nous l'expérimentions dans un avenir proche, mais je ne m'engagerais pas sur des délais concrets.

@kirbyfan64 Est tout à fait exact, @nailgilaziev , @bytesoftly Je n'essaie pas de dire que l'intégration C++ n'est pas nécessaire, je disais juste que je ne pense pas qu'il y ait autant de raisons/demande de faire flutter le support C++ AU LIEU de la fléchette - mais Je ne dis pas que l'intégration n'est pas nécessaire. Ce que dit @mraleph me semble intelligent.

@mraleph Le Dartino avait une implémentation similaire pour FFI . Est-il difficile de ressusciter ?

@listepo en fait partie. La mise en œuvre de FFI par Dartino a été très dynamique - ce n'est pas quelque chose que nous voulons pour Dart 2 qui est considérablement plus statique que Dart 1.

En retard dans le jeu, mais voici un autre cas d'utilisation : nous aimerions inclure des fichiers c et des méthodes dans dart à des fins cryptographiques.

Ce que nous espérons, ce sont les suivants :
1) Code identique pour iOS et Android, c'est-à-dire sans passer par les couches ObjC ou JNI.
2) Avec un peu de chance, une implémentation plus efficace que lors du passage par exemple de JNI deux fois.
3) Possibilité de réutiliser le code du modèle de fléchette dans une application Web de suivi, par exemple dans AngularDart, ou des applications de bureau de suivi à l'aide de ce projet : https://github.com/google/flutter-desktop-embedding

Je pense que ce que nous voulons est le plus proche du point 2 @eseidelGoogle mentionné ci-dessus. En ce qui concerne le support synchrone, je le considère comme un "agréable à avoir", car les fonctions asynchrones ne peuvent pas être utilisées dans un constructeur, où l'on peut vouloir effectuer par exemple un calcul de hachage rapide. Mais en s'habituant à la manière asynchrone de Darts, le support synchrone semble moins important que la possibilité générale d'atteindre les points 1)-3) ci-dessus.

En utilisant FFI comme suggéré par @mraleph , cela permettrait-il 1)-3) comme dans mon commentaire précédent, ou cela signifierait-il qu'un code différent est nécessaire sur différentes plates-formes (Android, iOS, ...) ?

@CryptUser si votre code C/C++ est le même sur toutes les plateformes, le code Dart pour l'appeler via FFI serait également le même sur toutes les plateformes.

@mraleph Ça a l'

@mraleph y a-t-il un problème ouvert pour FFI dans Dart quelque part ?

@dnfield J'en ai déposé un tout à l'heure https://github.com/dart-lang/sdk/issues/34452

J'aimerais pouvoir écrire du code C/C++/Rust et pouvoir l'utiliser sur ffi

Exemple:

Je teste le flutter sur tablette Android (Android 4.4).
flutter court rapidement.
Mais quand j'essaie de lire 1000 lignes avec sqflite qui utilise le canal de la plate-forme, c'est ridiculement lent.
la raison : je ne peux pas utiliser le lecteur de curseur sqlite.

mais si je pouvais utiliser directement la bibliothèque sqlite, la même requête est instantanée. (testé avec xamarin et projet android natif).

Nous discutons en ce moment de la meilleure façon d'aborder cela. Comme indiqué ci-dessus dans https://github.com/flutter/flutter/issues/7053#issuecomment-377711814, ce problème comporte de nombreuses parties et doit probablement être divisé. :)

Mais nous avons trouvé des ingénieurs intéressés par l'exploration d'un FFI (comme indiqué dans https://github.com/flutter/flutter/issues/7053#issuecomment-415161464). Notre objectif en ce moment est de sortir la version 1.0, mais une fois cela fait, cela sera en haut de la liste. Merci encore pour tous vos commentaires continus. Nous mettrons à jour ce problème lorsque nous aurons plus de progrès à partager.

Je suis également utilisateur de Matlab/Simulink. Je peux générer du code c/cpp spécifique au processeur hautement optimisé. Je veux intégrer mon algorithme dans le flutter. J'ai beaucoup d'algorithme de traitement d'image. J'ai besoin d'un générateur de liaison pour les codes natifs. Sinon, j'oublierai toutes mes expériences de flottement de fléchettes et je commencerai à apprendre le xamarin ou quelque chose qui me convient.

Pouvons-nous accélérer la progression ?

C'est tellement pénible d'interagir entre Dart et C.

Le fait de précipiter le processus n'aboutira probablement pas à un produit de bonne qualité. Ce sera prêt quand ce sera prêt. :-)

Le fait de précipiter le processus n'aboutira probablement pas à un produit de bonne qualité. Ce sera prêt quand ce sera prêt. :-)

Eh bien, ce que j'ai essayé de dire, c'est que nous pourrions vouloir augmenter la priorité afin de pouvoir consacrer plus de ressources et d'efforts à la résolution de ce problème. Vous savez qu'il y a actuellement 1386 problèmes ouverts ciblant « Objectif » qui seront « réparés dans les années à venir ».

Après avoir relu le fil, j'ai remarqué que

« Objectif » peut être le mauvais seau. :) @mraleph a quelqu'un qui explore https://github.com/dart-lang/sdk/issues/34452 pendant que nous parlons. C'est au moins une partie d'une solution.

Voici la doc vision pour la FFI que nous prototypons actuellement du côté de Dart.

Jetez-y un œil et dites-nous ce que vous en pensez.

Je ne peux pas dire grand chose sur la partie FFI car je n'ai jamais utilisé quelque chose comme ça,
mais je me demande à quoi ressemblera l'intégration du pub.

Comment seraient gérés les packages de publication utilisant FFI ?
Comment la consommation de colis utilisant FFI serait-elle gérée ?

@zoechi, nous n'avons pas encore discuté pub intégration de

Ils devraient pouvoir fonctionner de la même manière que les plugins Flutter actuels - inclure des sources et/ou des binaires appropriés à la plate-forme/architecture qui peuvent être compilés/liés dans l'application consommatrice.

D'un point de vue pub, cela ne devrait pas être un gros problème - sauf qu'il peut y avoir des fichiers binaires plus volumineux inclus dans le package.

Il faudrait cependant faire un peu de travail autour de la fin des outils Flutter pour les intégrer dans les projets Flutter - ils ne fonctionneraient pas vraiment de la même manière que les plugins Android/iOS le font aujourd'hui.

L'intégration de pub doit-elle être déplacée vers un problème dart-lang/pub pour que ce problème reste plus ciblé ?

J'ai lu 'vision doc' et je vois enfin des formes à travers le brouillard.

Pendant ce temps, je réfléchissais à quelque chose de très différent.

À savoir de (ré)utiliser Flatbuffers pour faire quelque chose comme NativeChannels. Au moment de l'exécution (AOT), cela se résumerait au passage du pointeur, tandis qu'au moment du développement, cela me permettrait d'exploiter les outils existants pour le côté "natif" écrit non seulement en C/C++ mais également en Go ou Rust.

L'approche de transmission de messages est également plus conforme aux architectures actuelles basées sur les flux (Bloc, Rx). Cela élimine également toute préoccupation concernant la gestion de la mémoire, car le compilateur peut générer des tampons en anneau appropriés le cas échéant ou supposer de simples « libérations de l'appelé » où un appelé doit conserver les données plus longtemps.

Mais pour être honnête, j'applaudirai toute forme de ffi si elle est intégrée de manière transparente dans l'écosystème Flutter (Fuchsia) et me permet d'utiliser du code natif optimisé pour le processeur à partir de l'application Dart.

@ohir ce que vous aviez envisagé serait une autre solution à certains des problèmes présentés par le bogue. Ce bogue a évolué en un fourre-tout à usage général pour tout ce qui concerne C++. :/ Je soupçonne (comme je l'ai noté dans les commentaires précédents) que nous devons diviser ce bogue en plus petits. Le travail FFI n'est peut-être pas la seule solution que nous construisons dans cet espace.

@eseidelGoogle des progrès à ce sujet ? en ce moment, nous avons un projet qui doit implémenter des tâches de traitement vidéo lourdes qui pourraient être effectuées via ffmpeg， car le package dart actuel ne peut pas fournir une solution viable，nous attendons avec impatience que flutter appelle directement ffmpeg lib.

Pour ces applications basées sur l'interface utilisateur page à page, je pense que le flutter est vraiment un bon choix plutôt que de se tourner vers le travail de double codage sur Android et iOS, si nous étions il y a 5 ans avec un si bel équipement, toute l'industrie des applications pourrait être changé. Cependant, les avantages du flutter en ce moment ne sont pas si époustouflants pour les entreprises qui migrent vers celui-ci, car elles avaient déjà fait assez bien avec l'ancienne méthode, mais pour certaines tâches non liées à l'interface utilisateur, Dart est loin derrière l'exigence principale.

cela ne veut pas dire que dart n'est pas bon ni viable pour ces tâches un jour, mais du point de vue d'une société informatique normale qui pourrait être incluse dans l'écosystème flutter, ce dont elle a besoin, c'est de réduire le coût en utilisant un cross- méthode de codage de la plate-forme uniquement si les fonctionnalités les plus intéressantes peuvent être obtenues, telles que le traitement des données côté client, la vidéo/audio, le personnel AR, etc. il est vraiment difficile pour eux de le ré-implémenter ou de le réinventer en utilisant Dart Lang.

et la solution clé est d'introduire le moyen direct et efficace pour flutter de communiquer avec c++, je pense même que c'est la première priorité d'une chose "multiplateforme", la fléchette pour le personnel de l'interface utilisateur est parfaite, une logique de données normale peut également être fait dans dart, mais il est bien mieux pour Flutter de se fondre dans le long mais toujours actif et efficace écosystème c++ plutôt que d'en reconstruire un nouveau sacré !

le rêve d'une véritable expérience de codage « multiplateforme » est le personnel de l'interface utilisateur dart avec c++ derrière le capot, pas de code java du tout, pas de code oc du tout. wahaha, j'ai hâte de voir ça arriver!

@smellbee Vous ne pouvez pas utiliser la ligne de commande ffmpeg ?

@smellbee Je pense que je ne suis pas le bon pour répondre à ça. @eseidelGoogle des nouvelles à ce sujet ?

@smellbee Vous ne pouvez pas utiliser la ligne de commande ffmpeg ?

c'est un travail côté client, utilisant ffmpeg lib pour rendre les images vidéo afin de produire un flux de retour instantané, est-il possible d'utiliser la ligne de commande?

@smellbee Je pense que je ne suis pas le bon pour répondre à ça. @eseidelGoogle des nouvelles à ce sujet ?

désolé pour cela, j'ai tapé "es" , et il s'est terminé automatiquement, je ne l'ai pas remarqué... j'espère que @eseidelGoogle pourra le voir

Les travaux sont en cours du côté de Dart - nous espérons avoir quelque chose de prêt au premier trimestre 2019.

C'est une fonctionnalité importante et nous aimerions bien faire les choses : comme nous voulons qu'elle fonctionne parfaitement dans différents modes d'exécution pour Dart, veuillez donc être patient pendant que nous travaillons sur les détails.

Vous pouvez suivre dart-lang/sdk#34452 qui suit le travail du côté de Dart.

Dart FFI permettra d'appeler des fonctions C depuis Dart.
Mais qu'en est-il des fonctionnalités C++ - classes, conteneurs std, pointeurs intelligents, exceptions ?
Pouvons-nous nous attendre à la possibilité d'exporter des classes C++ vers Dart avec un minimum de passe-partout ?

Une autre fonctionnalité assez importante est la prise en charge asynchrone - la possibilité d'exécuter du code C++ sur un thread séparé et de renvoyer Future/Stream à partir de méthodes.

@t-artikov Il n'est actuellement pas prévu de prendre en charge directement l'interopérabilité C++. C'est trop compliqué. La seule chose qui peut interagir de manière ergonomique avec C++ est C++.

Si vous êtes intéressé par l'interopérabilité de haut niveau avec C++, vous devrez créer votre propre couche d'interopérabilité qui expose votre API C++ via une API de type C.

Une autre fonctionnalité assez importante est la prise en charge asynchrone - la possibilité d'exécuter du code C++ sur un thread séparé et de renvoyer Future/Stream à partir de méthodes.

Je pense que cela peut être construit comme un package. Nous devrions juste nous assurer que nous fournissons les bonnes primitives pour que cela puisse être construit.

Dart FFI permettra d'appeler des fonctions C depuis Dart.
Mais qu'en est-il des fonctionnalités C++ - classes, conteneurs std, pointeurs intelligents, exceptions ?
Pouvons-nous nous attendre à la possibilité d'exporter des classes C++ vers Dart avec un minimum de passe-partout ?

Tant que s'il existe un moyen pour C++ d'appeler dart， je pense que ces choses sont possibles， C++ s'occupe de ce qui préoccupe le C++，et communique avec dart en étant appelé ou en appelant, pas besoin d'exposer une manipulation de bas niveau à dart qui détruira la facilité d'utilisation de dart.

Une autre fonctionnalité assez importante est la prise en charge asynchrone - la possibilité d'exécuter du code C++ sur un thread séparé et de renvoyer Future/Stream à partir de méthodes.

Et dart a déjà son mécanisme asynchrone， donc， qu'un thread soit orienté C++ ou non ne fait aucune différence，tant que la partie C++ peut appeler dart chaque fois que nécessaire, et un "Isolate" peut faire le travail.

C'est ce que je pense @mraleph , corrigez moi si je me trompe ;)

@mraleph
En fait, il existe des exemples de grande interopérabilité C++ avec d'autres langages.
https://github.com/boostorg/python
https://github.com/ThePhD/sol2
https://github.com/dropbox/djinni
J'espère que Dart/Flutter fournira un mécanisme similaire prêt à l'emploi.

Si vous êtes intéressé par l'interopérabilité de haut niveau avec C++, vous devrez créer votre propre couche d'interopérabilité qui expose votre API C++ via une API de type C.

Pour expliquer clairement comment cette approche est applicable, pourriez-vous la démontrer en utilisant les classes С++ suivantes comme exemple :

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);
};

Pour qu'il puisse être utilisé depuis Dart

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

@t-artikov boostorg::python et sol2 illustrent très bien mon propos. Notez qu'il s'agit de bibliothèques C++ pour interagir avec d'autres langages, et non l'inverse. Dart FFI est une manière centrée sur Dart d'appeler des API C, et non une manière centrée sur C++ d'appeler Dart.

Pour expliquer clairement comment cette approche est applicable, pourriez-vous la démontrer en utilisant les classes С++ suivantes comme exemple :

Vous devrez écrire (ou générer par un outil) quelque chose comme ça.

// 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); }
}

Notez qu'il s'agit de bibliothèques C++ pour interagir avec d'autres langages, et non l'inverse.

Vous vous trompez, ils permettent d'exposer les classes C++ à d'autres langages.
https://www.boost.org/doc/libs/1_68_0/libs/python/doc/html/tutorial/tutorial/exposing.html

Merci pour votre exemple Dart FFI.
Il y a quelques défauts : l'exception C++ doit être passée du côté de Dart ; et MyObject.data ne fonctionnera pas de cette façon (il n'obtient que le pointeur, mais pas la taille des données).
Mais l'idée est claire.

À mon avis, un tel code est trop verbeux pour l'écrire manuellement.
J'ai hâte de voir si ce processus sera automatisé pour les nouvelles fixations Dart FFI Flutter Engine.

La liaison au moment de l'exécution pour l'interopérabilité C++ est presque impossible (comment gérez-vous les génériques, l'héritage multiple, les surcharges d'opérateurs, les noms mutilés, etc.). Il y a eu de nombreuses tentatives difficiles (BridJ, CppSharp, etc.) et, à ma connaissance, les gens trouvent l'interopérabilité C comme l'option la plus viable.

Il est peu probable que les développeurs officiels d'interopérabilité puissent trouver une solution très générique pour C++. Kotlin/Native ne propose pas cela. iether natif scala. .NET soit (l'interopérabilité Microsoft C++ est toujours soit étrange, soit statique). JNI prend en charge l'interopérabilité C++ uniquement lorsque la compilation statique est impliquée. Quelque chose comme la colle python boost doit être écrit manuellement. N'importe quel groupe tiers peut développer des choses comme JNAerator (c'est-à-dire que VOUS pouvez le faire, pas besoin d'attendre des équipes Dart/Flutter pour y parvenir).

Suite à cette conversation sans vraie réponse, je pense que je vais m'en tenir à Qt, qui est multiplateforme et prend en charge C++. Je pensais juste essayer Flutter pour mon prochain projet mais maintenant je ne le ferai pas, merci beaucoup !

Cela aurait pu être mieux si Flutter avait été écrit en C++, avec lequel l'interopérabilité avec n'importe quel autre langage aurait été facilement possible. Existe-t-il une tentative de réécriture de flutter en C++ ?

Je pense que la discussion s'étire inutilement maintenant.

Nous savons ce qui est (ou n'est pas) sur la feuille de route du développement de flutter.
En conséquence, nous pouvons décider de l'utiliser (ou de ne pas l'utiliser) pour des cas d'utilisation spécifiques.

Je ne vois aucune utilité à essayer de changer le programme de développement, ou
exigeant une mise en œuvre architecturale spécifique, au-delà de ce point.

Merci,
Gaurav

Le lundi 25 février 2019, à 22 h 51 bhauj, [email protected] a écrit :

Cela aurait pu être mieux si flutter avait été écrit en C++, avec
quelle interopérabilité avec n'importe quelle autre langue aurait été facilement possible. Est
existe-t-il une tentative de réécriture de flutter en C++ ?

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/flutter/flutter/issues/7053#issuecomment-467098455 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AZ86acDpZgNeyezx40uxe_c5E2xZHWxaks5vRBumgaJpZM4K-PLw
.

En fait, comme je le sais, Flutter est écrit en C++, mais la programmation en Flutter ne peut être effectuée qu'avec l'interpréteur Language Dart qui s'exécute dans une machine virtuelle. Mais vous n'avez encore aucune chance de passer de Dart à la partie C++ de Flutter...

Donc, quiconque lit ceci et a le cas d'utilisation courant dans le développement d'applications d'un bon développement multiplateforme, Flutter n'autorisera pas l'utilisation directe de C++ si vous en avez besoin, utilisez un autre framework multiplateforme comme Qt C++.

Pour moi, C++ est essentiel pour le développement multiplateforme car c'est le plus petit dénominateur commun dans presque toutes les technologies.

@aqmappdesigners

interpréteur Language Dart qui s'exécute dans une VM

Ce n'est pas exact.

Flutter utilise la VM Dart en mode débogage, ce qui rend également possible le rechargement à chaud.
Dans les versions de version, Dart est compilé en code binaire comme C++.

@zoechi Merci, je ne le savais pas. ça sonne bien pour la performance

ça sonne bien pour la performance

et est une exigence pour l'App Store d'Apple.

Le prototype dart:ffi a progressé au point où nous prenons des décisions sur les décisions de l'API. (Certaines décisions de conception sont discutées ici .)

Pour prendre des décisions de conception éclairées, nous aimerions plus d'exemples sur les API C que vous souhaitez lier. Jusqu'à présent, ce numéro mentionne SQLite, Realm, OpenCV, Superpowered et ffmpeg. Y a-t-il d'autres API que nous devrions considérer ?

@dcharkes Je ne sais pas si cela aide, mais Telegram dans Android fait du réseautage en C++ via JNI :
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/TgNetWrapper.cpp
Il gère également la lecture GIF avec ffmpeg, en écrivant directement sur Android Bitmaps :
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/gifvideo.cpp

Il pourrait être intéressant d'avoir un moyen d'analyser les téléphones et les adresses via libphonenumber et libpostal pour les formulaires d'inscription. Aussi glfw + flutter-embedder et peut-être qu'un jour nous verrons une application de bureau entièrement écrite en dart.

+1 pour SQLite et Realm. Veuillez également consulter Couchbase , ils ont un noyau C++ commun avec un SDK C.

L'API Firebase C++ serait-elle intéressante ? https://firebase.google.com/docs/reference/cpp/

Je n'y ai pas beaucoup réfléchi, mais je pensais que cela pourrait remplacer les plugins iOS et Android par un seul plugin qui communique directement avec C++.

Certaines bibliothèques cryptographiques devraient recevoir un peu d'amour comme ring de rouille - https://github.com/briansmith/ring

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

bibliothèques de cryptographie. En particulier le libsodium ou le tink.

https://github.com/google/tink

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

Il existe déjà une bibliothèque flutter-sodium, elle communique via les canaux de plate-forme aux wrappers libsodium sur chaque plate-forme, puis au natif.

Bibliothèques de cartographie personnalisées telles que mapbox-gl https://github.com/mapbox/mapbox-gl-native

La gestion SMTP / IMAP (pour le chat par e-mail) pour Flutter via https://github.com/deltachat/deltachat-core est quelque chose que j'aimerais utiliser directement.

Si je peux être assez audacieux pour paraphraser, les cas d'utilisation courants sont les suivants :

1. Accès matériel audio/vidéo à faible latence (tel que Superpowered)
2. Traitement audio/vidéo assisté par matériel (tel que ffmpeg)
3. Accès socket basé sur TCP, pour XMPP/autres protocoles orientés réseau
   (pour le chat, les notifications push)
4. Mises à niveau au niveau du processus (accès root)/création de threads dans
   manière compatible multiplateforme (pour les applications système, le multitâche, les émulateurs)

Il peut y avoir plus de cas d'utilisation, mais ce sont les principaux qui viennent à mon
dérange.

Merci à tous pour ces exemples ! C'est très utile.

@skills-up note que nous sommes beaucoup plus intéressés par des exemples concrets que par une classification abstraite. En effet, nous souhaitons évaluer l'ergonomie de FFI sur des exemples concrets.

Curieusement, l'un des langages qui offre la meilleure interface de/vers C++ est Rust, via son puissant système de macro + build, malgré une approche complètement différente de l'OO.

Je dirais OpenSSL, car nous devons signer numériquement les demandes de savon et les fichiers xml (XMLDSig, Xades l) à l'aide de certificats clients.
Dart lui-même a BoringSSL, mais seule une partie est exposée via Dart. Donc, la meilleure chose à faire est d'appeler les bibliothèques natives openssl à partir de flutter

J'espère que je ne spamme pas, mais j'aimerais aussi avoir une meilleure intégration avec tensorflow lite, sans passer par JNI, ce serait génial pour les opérations vidéo

Je n'y ai pas beaucoup réfléchi, mais je pensais que cela pourrait remplacer les plugins iOS et Android > par un seul plugin qui communique directement avec C++.

En plus de prendre en charge C++, ce sera génial s'il existe un plugin qui peut parler directement à Go. À l'heure actuelle, nous parlons de passer par les canaux de la plate-forme gomobile et flutter, ce qui ralentit la réactivité de l'interface utilisateur. La prise en charge native de Go et C++ dans Flutter nous aidera également à maintenir une base de code uniforme (logique métier/algorithme) pour plusieurs plates-formes.

+1 pour l'accès natif à la bibliothèque.

J'aimerais accéder à Vulkan/MoltenVK sans avoir à créer des canaux de plate-forme pour Android/iOS et maintenir deux plugins (ce qui serait également énorme). Cela permettrait de créer des applications 3D et de les rendre dans un widget Texture, tout en développant uniquement dans Dart. Les canaux de la plate-forme semblent être une solution de contournement bidon. Je préfère accéder aux bibliothèques natives sans avoir à écrire un wrapper pour chaque plate-forme et les maintenir chaque fois qu'il y a une nouvelle version pour cette bibliothèque.
Je pense que cette fonctionnalité attirerait beaucoup plus de développeurs.

Oui, plz accès direct à la bibliothèque native à partir de flutter.
J'aimerais utiliser une bibliothèque c++ à flutter.

Oui, plz accès direct à la bibliothèque native à partir de flutter.
J'aimerais utiliser une bibliothèque c++ à flutter.

Nous sommes maintenant à un point où nous aimerions offrir un avant-goût pour obtenir des commentaires.

Pour plus de détails, veuillez consulter la mise à jour dans le bogue de suivi de Dart .

@mit-mit Cela aidera-t-il à résoudre ce problème : puis-je appeler ou utiliser la bibliothèque python avec flutter ?

En retard à la fête, mais +1 pour SQLCipher @dcharkes @mraleph

@doc-rj, nous en sommes maintenant au stade où vous devriez pouvoir expérimenter la liaison SQLCipher et nous faire part de votre retour d'expérience. Voir ce commentaire .

Je voudrais souligner que nous ne visons pas vraiment à fournir nous-mêmes des liaisons de bibliothèque spécifiques - car les demandes sont extrêmement diverses, mais nous visons à permettre à tout le monde et à n'importe qui de se lier à n'importe quelle bibliothèque avec une API C.

Je suppose que la nécessité de cela augmente maintenant que la multi-plateforme a été annoncée.

Cela fait-il partie d'une feuille de route ?

@felemedeiros le travail est en cours - si vous avez une bibliothèque que vous souhaitez lier à l'aide de FFI, je suggère fortement de commencer à travailler sur les liaisons pour nous faire part de vos commentaires. Voir ce commentaire pour plus d'informations.

Je n'y ai pas beaucoup réfléchi, mais je pensais que cela pourrait remplacer les plugins iOS et Android > par un seul plugin qui communique directement avec C++.

En plus de prendre en charge C++, ce sera génial s'il existe un plugin qui peut parler directement à Go. À l'heure actuelle, nous parlons de passer par les canaux de la plate-forme gomobile et flutter, ce qui ralentit la réactivité de l'interface utilisateur. La prise en charge native de Go et C++ dans Flutter nous aidera également à maintenir une base de code uniforme (logique métier/algorithme) pour plusieurs plates-formes.

J'ai écrit un article sur la façon dont nous appelons actuellement l'API de la bibliothèque Go de Flutter. Cela peut être utile à quelqu'un que ça intéresse. https://medium.com/@archan.paul/using -go-library-in-flutter-a04e3496aa05

Comment puis-je ajouter du code c++ sur l'application Flutter ?

Comment puis-je ajouter du code c++ sur l'application Flutter ?

Je suppose que pour le moment, la seule option est de prendre C++ -> JNI (pour Android) -> PlatformChannel jusqu'à ce que nous ayons un moyen plus élégant de faire la même chose !!

J'ai créé un projet appelé ezored (http://ezored.com). Ce serait bien si je pouvais passer des objets complexes à Flutter sans avoir besoin de les convertir en autre chose, car il est déjà en java et objc. Tout le monde peut utiliser ezored pour générer le SDK (ou télécharger le pré-construit) pour tester l'intégration de Flutter entre natif et Dart. Il contient des requêtes, une analyse, une base de données brute et beaucoup de choses dans le SDK de démonstration déjà implémentées.

Je recherche dans des groupes flutter mais je n'ai aucun moyen de transmettre les objets et la liste d'objets à Flutter directement.

Merci pour toute aide.

De nouveaux progrès ? Il semble que plus de 2,5 ans se soient écoulés...

@fzyzcjy nous y travaillons. Nous avons publié un avant-première. Voir https://github.com/dart-lang/sdk/issues/34452#issuecomment -482136759 pour savoir comment s'impliquer.

Depuis cette première préversion, nous avons ajouté la prise en charge d'Intel 32, Arm 64 et Arm 32. Ces plates-formes ne sont pas encore publiées sur stable ou dev, elles ne sont disponibles que sur la branche master du SDK Dart. Les progrès sont suivis ici .

@dcharkes Tellement heureux d'entendre ça! Merci pour votre bon travail!

Aucun progrès?

Pour les mises à jour de statut et des informations supplémentaires, veuillez consulter https://github.com/dart-lang/sdk/issues/34452. Le commentaire le plus haut contient la mise à jour la plus récente.

Lors de l'utilisation de flutter pour créer une application Web, l'utilisation de ffi avec la bibliothèque ac sera-t-elle possible ?

Lors de l'utilisation de flutter pour créer une application Web, l'utilisation de ffi avec la bibliothèque ac sera-t-elle possible ?

Ce n'est pas probable. Théoriquement, à plus long terme, il pourrait être pris en charge à l'aide de WebAssembly, mais ce n'est pas quelque chose sur lequel nous travaillons actuellement.

@ avec-avec vraiment？

Lors de l'utilisation de flutter pour créer une application Web, l'utilisation de ffi avec la bibliothèque ac sera-t-elle possible ?

Ce n'est pas probable. Théoriquement, à plus long terme, il pourrait être pris en charge à l'aide de WebAssembly, mais ce n'est pas quelque chose sur lequel nous travaillons actuellement.

Pourquoi cela nécessiterait-il WebAssembly ? Si vous pouvez demander aux gens de reconstruire vers WebAssembly à l'avenir, vous pouvez leur demander de reconstruire vers ASM.js maintenant.

@nic-hartley C'est une bonne idée, mais le défi n'est pas de savoir comment compiler le code natif, c'est de créer le pont entre Dart (compilé en JS) et le code natif, quelle que soit sa forme.

Le FFI natif est de très bas niveau pour des raisons de performances et ne peut pas être facilement traduit en asm.js ou WebAssembly.

Pour clarifier, je veux dire que notre implémentation est de très bas niveau -- c'est certainement une fonctionnalité intéressante, mais il faudrait un travail considérable pour la livrer.

flutter n'est qu'un jouet jusqu'à ce qu'il supporte c++

Je suis venu ici pour faire écho aux mêmes points par d'autres, que jusqu'à ce que Flutter puisse facilement interagir avec C ++ (sans bibliothèque de pont et sans pénalité de performance), il ne sera jamais adopté par des applications à grande échelle avec des investissements dans des bibliothèques ou des applications natives existantes où la performance est la priorité la plus élevée.

Je noterai que même React Native utilise actuellement un pont, il semble donc que Flutter soit en fait en avance sur la courbe en termes d'essai de mise en œuvre d'un FFI.

L'intégration avec C++ est triviale sur iOS avec AppKit. C'est à cela que nous devrions comparer, pas à React Native.

UWP & C++ est également trivial.

Je suis en général pour le parti "Soutenir l'effort de Dart FFI" aussi, cependant...

Xamarin est peut-être une comparaison plus appropriée que UWP, mais les vues multiplateformes de Xamarin n'étaient pas aussi personnalisables que celles de Flutter et nécessitaient souvent beaucoup de code natif pour avoir l'air décent.

Ce n'est pas vrai. Contrairement à Flutter, Xamarin a des liaisons de plate-forme à l'API native (c'est-à-dire Xamarin.iOS et Xamarin.Android), et il est facile pour les développeurs d'applications d'écrire une implémentation spécifique à la plate-forme dans son propre langage (C#/.NET). Ce problème concerne la fonctionnalité de langue et ne doit pas être mélangé avec la conception de l'API du widget d'interface utilisateur.

Il y a beaucoup d'utilisations d' API natives, mais pas d'invocation de code natif, où Flutter serait sur le même bateau (bien que Xamarin ne nécessite pas d'y écrire Java ou ObjC, sans hack de réflexion dans le code de l'application). Pour le code natif, même sur Xamarin.Android lui-même (l'un des backends de la plate-forme principale), l'utilisation de code natif est très limitée et les développeurs d'applications n'écrivent aucun code natif.

Et contrairement à React Native ou Xamarin, Flutter doit fournir son framework complet, il est donc tout à fait juste que nous comparions l'ensemble du framework Flutter avec des choses comme AppKit.

c'est bizarre que personne ne mentionne même le framework Qt qui est loin devant tout le reste concernant l'intégration C++

QT est C++. Et a une licence défavorable pour commencer.

Le lun. 12 août 2019, 06:41 Vladyslav Stelmakhovskyi, <
[email protected]> a écrit :

c'est bizarre que personne ne mentionne même le framework Qt qui est loin devant
tout le reste concernant l'intégration C++

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/flutter/flutter/issues/7053?email_source=notifications&email_token=AGDYMWXHTJUBUW64LEOO27TQEDSWNA5CNFSM4CXY6LYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDNYAWW2Z184# ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AGDYMWTNMTM7QUOY2BEIPM3QEDSWNANCNFSM4CXY6LYA
.

Qt est C++ et QML (moteur JS)
Quelle licence ? LGPL ? GPL ? Qu'est-ce qui va pas avec ça?

Tout d'abord IANAL, mais si je comprends bien, la plupart de Qt est LGPL (l'IDE, etc. sont GPL), ce qui signifie qu'il a un langage qui, bien qu'il n'interdise pas expressément les liens statiques, le rend difficile à faire tout en respectant la licence si votre application est à source fermée.

Techniquement, si vous utilisez uniquement LGPL et fournissez vos fichiers objets (et probablement des instructions) afin que les utilisateurs puissent potentiellement se reconnecter à une version différente de la bibliothèque, vous répondez aux exigences de la LGPL. Mais je suis presque sûr que la société Qt n'annonce pas ce fait, donc la conception commune est que vous ne pouvez pas déployer de bibliothèques statiques, ce qui signifie que vous ne pouvez pas publier votre application sur l'App Store sans payer leurs frais de licence exorbitants. Et je peux me tromper en fournissant des fichiers objets, c'est juste ma compréhension, et je ne sais pas si des entreprises le font.

Android est plus facile car il autorise les bibliothèques chargées dynamiquement qui sont plus explicitement autorisées sous la LGPL, mais en toute honnêteté, une liaison statique serait probablement préférable là aussi pour réduire la taille de l'application, ce qui signifie rencontrer le même problème.

Salut @cpboyd , je pense que je regarde cela dans la direction opposée. Nous avons déjà des applications construites sur des frameworks d'interface utilisateur spécifiques à la plate-forme, où chaque plate-forme nous permet d'utiliser notre vaste collection de bibliothèques C++ existantes. Je comprends que Flutter est multiplateforme, ce qui est génial, mais à moins que je puisse l'utiliser réellement (avec mon code existant), alors je ferais mieux de m'en tenir à une interface utilisateur non multiplateforme. Le seul point de blocage survient lorsqu'un futur système d'exploitation (par exemple Fuchsia) nécessite l'utilisation de Flutter & Dart, mais ne permet pas ce cas d'utilisation. Dans ce cas, il est susceptible d'être ignoré par toute personne possédant de grandes bases de code existantes.

Je suppose que je ne sais pas si Flutter / Dart est conçu avec des applications "web" (c'est-à-dire où les backends sont sur le Web) à l'esprit, ou si les besoins des développeurs d'applications de bureau professionnels sont sérieusement pris en compte. En fin de compte, de telles décisions peuvent affecter le nombre et la qualité de nombreuses applications sur une boutique d'applications. Si je peux écrire une application professionnelle de haute qualité pour iOS en utilisant UIKit, en utilisant des millions de lignes de code existant, mais je ne peux pas (avec un coût de performance proche de zéro) si je développe pour Fuchsia / Flutter / Dart, alors ce serait être un système d'exploitation et une plate-forme pour lesquels je ne développerais pas.

Le but de mes articles n'est pas de comparer Flutter à d'autres bibliothèques multiplateformes ou non multiplateformes, c'est de mettre en évidence des cas d'utilisation importants pour un sous-ensemble de développeurs.

Le Dart FFI est intéressant, d'après la _très_ brève lecture de l'exemple sqllite , il ressemble à C# avec PInvoke, mais malheureusement cela ne convient pas à C++, car presque tous les types que vous traitez auraient besoin d'être enveloppés, ou vous auriez à écrire un système d'interface sans type entièrement générique pour envelopper le C++. Aucun de ceux-ci n'est particulièrement attrayant lorsque vous le comparez à la facilité de la classe Obj-C suivante :

#include <mylib/mytype.h>
<strong i="11">@implementation</strong> MyView
{
    MyLib::MyType *_pMyType;
}
<strong i="12">@end</strong>

Ou UWP avec C++/WinRT :

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

Merci :-)

@Hixie @MarkIngramUK Aucun de ceux-ci n'est multiplateforme, ce qui était mon propos.
AppKit est uniquement Apple, tandis que UWP est uniquement Windows.
Peut-être que si Flutter avait utilisé Swift ou C# au lieu de Dart, nous aurions déjà le même niveau de support, mais c'est un argument totalement différent.
Xamarin est peut-être une comparaison plus appropriée que UWP, mais les vues multiplateformes de Xamarin n'étaient pas aussi personnalisables que celles de Flutter et nécessitaient souvent beaucoup de code natif pour avoir l'air décent.
Ma suggestion reste la même : si vous souhaitez utiliser Flutter avec C++, vous devez participer à l'aperçu FFI de l'équipe Dart et contribuer à améliorer le support pour nous tous 😃

Ce problème concerne la fonctionnalité de langue et ne doit pas être mélangé avec la conception de l'API du widget d'interface utilisateur.

@atsushieno Bien sûr, et c'est pourquoi cette discussion serait plus productive sur le forum Dart FFI... Flutter est le cadre. Dart est la langue.

Aucun de ceux-ci n'est particulièrement attrayant lorsque vous le comparez à la facilité de la classe Obj-C suivante :

@MarkIngramUK Je suis sûr que c'est exactement le genre de commentaires que l'équipe Dart aimerait voir sur https://groups.google.com/forum/#!forum/dart -ffi

J'ai un projet appelé ezored (https://ezored.com) qui est un projet d'amorçage C++ pour les SDK et les applications en C++. Nous utilisons dans des projets mobiles (Android et iOS). J'attends que FFI soit terminé pour créer un projet qui utilisera le SDK par défaut en flutter.

Nous n'avons aucun problème avec C++ et le temps de développement des nouvelles fonctionnalités est réduit, puisque le SDK a le même code dans toutes les plateformes, comme vous pouvez le voir dans l'implémentation par défaut (projet poco, openssl, sqlite, code de plateforme spécifique intégré avec code de pont, etc.).

Dans mon option, c'est la meilleure façon:

• iOS et Android avec backend C++ (ezored)
• Flutter et C++ comme backend

N'hésitez pas à ajouter un début au projet :)

Kotlin Multiplatform pourrait être une solution de contournement, pas une pensée parfaite. Encore faut-il attendre https://github.com/dart-lang/sdk/issues/34452

Unity3d semble porter un flottement sur son moteur basé sur C# VM [1] - dans ce monde, parler entre C# et C++ est décent. Cela vaut peut-être la peine de jeter un œil à leur repo sur la façon dont ils ont résolu certains problèmes. Ils déclarent : « UIWidgets est principalement dérivé de Flutter ». J'examinerais également le camp natif de réaction et leur nouvelle approche avec TurboModules - leur solution pourrait avoir un avantage sur l'approche flutter car ce sera
1) à la fois synchrone et asynchrone et
2) il n'y aura pas de rassemblement et
3) supportera non seulement C mais C++

Je suis cheer-leader dans les deux camps.

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

À partir de Dart 2.5, ceci ( dart:ffi ) est maintenant en avant-première :
https://medium.com/dartlang/announcing-dart-2-5-super-charged-development-328822024970

Bonne nouvelle!

Mmm... Sera-ce suffisant d'utiliser Hautbois avec Flutter ?..

https://github.com/google/oboe

@rg4real Ouais ! Mais, vous aurez besoin d'écrire des wrappers C puisque l'interface Oboe est en C++.

Vous pouvez voir https://github.com/flutter/flutter/wiki/Binding-to-native-code-via-FFI pour obtenir des instructions sur la mise en route.

Vous pouvez réutiliser mon oboe-c.so que j'ai écrit pour mes liaisons C#, si cela fonctionne https://github.com/atsushieno/oboe-sharp/tree/master/native

@sjindel-google , ce sont des nouvelles géniales !

J'ai donc besoin de créer un pont entre le code C++ et le code C en créant des classes et des fonctions. Et puis je peux utiliser ces classes et appeler cette fonction à partir d'un code Dart. Je pense que c'est vrai.

@atsushieno , merci. Je jette un œil. Je ne sais pas trop comment faire des ponts dans mon cas (manque d'expérience). Mais avez-vous réussi à atteindre votre objectif global de jouer avec précision avec le hautbois ? C'était si bon que ça ?

@rg4real Je le faisais simplement pour une API plus simple (par rapport à OpenSLES) que l'audio à faible latence. Si j'étais vraiment sérieux au sujet de la latence, je n'utiliserais pas Xamarin.Android. Si vous parlez de hautbois (ou de AAudio derrière), alors je l'utilise dans Fluidsynth et cela fonctionne bien. Cependant, je ne sais pas "à quel point" AAudio est comparé à OpenSLES.

Existe-t-il un guide sur la gestion de la mémoire ?

Si le code C++ crée une mémoire en utilisant new/malloc et retourne au code Dart, comment libérer cette mémoire.

code c++
void foo(char** out) {
*out = nouveau caractère[25] ;
}

Comment supprimer la mémoire affectée à |out| variable du code fléchette?

Si vous êtes sur Dart 2.5, il y a un .free() sur Pointer . Si vous êtes sur la branche dev/master, cette méthode a déplacé package:ffi https://github.com/dart-lang/ffi/blob/master/lib/src/allocation.dart#L70.

Selon le commentaire - "Il ne peut être utilisé que contre des pointeurs alloués d'une manière équivalente à [allouer]." - free() ne peut être utilisé que si la mémoire est allouée à l'aide de la méthode allow().

par exemple
ffi.Pointeurptr = ffi.Pointeur.allouer();
ptr.free();

Cela permet-il de libérer de la mémoire allouée du côté C++ à l'aide de new ou de malloc à partir du code Dart ?

Tant que la mémoire a été allouée via malloc , via Dart ou C++, elle peut être libérée avec free .

Dans Dart 2.6, nous utilisons DynamicLibrary.lookupFunction("free") pour définir free dans Dart, ce sera donc exactement le même free que dans la partie C++ du programme. (À moins que vous ne liez plusieurs versions de free dans votre binaire.)

Fermeture de ce problème car cette fonctionnalité est désormais généralement disponible (en version bêta) dans tous les canaux Flutter. Nous continuons d'améliorer le problème. Pour tout problème détaillé, veuillez les déposer sur https://github.com/dart-lang/sdk/issues/new.

rendre les classes c++ avec la compatibilité c est compliqué. plz make capacité d'appeler directement les classes c++

+1 Pouvons-nous avoir le support C++ ?

@KaungZawHtet et @fzyzcjy - veuillez envisager d'ouvrir un nouveau numéro (probablement en dart-lang plutôt qu'en flutter) pour cela.

Je vais verrouiller ce problème - il y a beaucoup de gens qui y sont abonnés, mais son objectif initial est assez clairement résolu.

Oui, pour les nouveaux problèmes, veuillez les classer en utilisant ce lien : https://github.com/dart-lang/sdk/issues/new?labels=library-ffi ,area-vm