Flutter: प्लगइन ढांचे में सी/सी++ के साथ एकीकरण का समर्थन

@ जेसन-सीमन्स ग्रैडल के बारे में सबसे ज्यादा जानते हैं। एक बार हमारे पास .so हो जाने पर, मैं निश्चित रूप से इसे लोड करने में मदद कर सकता हूं।

मैंने पाया कि बिल्डएसआरसी के तहत ग्रेडेल बिल्ड संस्करण सेट करने के लिए एक और संपत्ति है। 2.2.2 में अपडेट करने के बाद मैंने प्रगति की है, और .so लोड को सत्यापित करने में सक्षम था, और जावा से कॉल करने योग्य है।

संभवतः हमें डार्ट को C/C++ कोड से HostMessages भेजने के लिए एक C API भी जोड़ना होगा।

जी बोलिये। मुझे संदेह है कि सी-> जावा कॉलबैक सस्ता नहीं हो सकता है।

इस पर किसी भी अद्यतन? एक साझा पुस्तकालय में संकलित सी ++ कोड को कॉल करने वाले क्रॉस प्लेटफॉर्म ऐप के निर्माण के लिए स्पंदन को ध्यान में रखते हुए, और यह एकमात्र प्रमुख रोक बिंदु है।

यह आज संभव है (और @jtrunick ने अपने शिपिंग ऐप में ऐसा किया था), लेकिन आपको पहले जावा या ओब्ज-सी के माध्यम से बाउंस करना होगा।

यानी आप डार्ट से ओब्ज-सी/जावा पर बात करने के लिए https://flutter.io/platform-channels/ का उपयोग कर सकते हैं और फिर ओब्ज-सी/जावा कॉल से अपने सी++ कोड में बात कर सकते हैं। इस बग में इसके लिए अधिक प्रत्यक्ष समर्थन जोड़ने और संभावित रूप से ओब्जे-सी/जावा पासथ्रू से बचने को शामिल किया गया है।

चूंकि डार्ट वीएम सी ++ में लागू किया गया है, क्या सी साझा पुस्तकालयों को सीधे कॉल करने का एक आसान (यदि कम सुरक्षित) तरीका नहीं होना चाहिए (dlopen के माध्यम से कहें)? बुनियादी (असुरक्षित/प्रयोगात्मक) समर्थन के लिए कितने परिवर्तन की आवश्यकता होगी?

क्या ऐसा कुछ है: https://www.dartlang.org/articles/dart-vm/native-extensions android या ios पर उपलब्ध है?

हमने इस आवश्यकता को कुछ Google ऐप्स से सुना है:

• ऐसे ही एक ऐप ने विलंबता को कम करने के लिए कैमरे के संचालन के लिए अपनी स्वयं की C++ लाइब्रेरी लिखी। ये पुस्तकालय मंच विशिष्ट हैं और जितनी जल्दी हो सके काम करने के लिए अनुकूलित हैं। इन पुस्तकालयों को न्यूनतम संभव विलंबता के साथ लागू करना ऐसे ऐप्स के लिए महत्वपूर्ण है। उन्हें PlatformChannel + JNI के माध्यम से जाने के लिए मजबूर करने से Android पर वह हासिल नहीं होगा।

• वहाँ उन्नत मोबाइल टीमें हैं जो अपने Android और iOS कार्यान्वयन के बीच इसे साझा करने में सक्षम होने के लिए C++ में व्यावसायिक तर्क घटकों को लिखती हैं। उन पुस्तकालयों के साथ सीधे एकीकरण का समर्थन करने वाला स्पंदन वहां से सबसे अच्छा क्रॉस-प्लेटफ़ॉर्म ढांचा होने की अपनी स्थिति को और मजबूत करेगा।

मुझे नहीं लगता कि यह _होना चाहिए_. हालाँकि, यह एक ऐसा क्षेत्र है जहाँ Flutter खुद को अन्य क्रॉस-प्लेटफ़ॉर्म समाधानों से अलग कर सकता है।

ऐसे ही एक ऐप ने विलंबता को कम करने के लिए कैमरे के संचालन के लिए अपनी स्वयं की C++ लाइब्रेरी लिखी। [...] उन्हें PlatformChannel + JNI के माध्यम से जाने के लिए मजबूर करने से Android पर वह हासिल नहीं होगा।

सी ++ से जावा और पीछे जाने के लिए एंड्रॉइड पर उनका समाधान क्या था?

यदि यह वास्तव में आवश्यक है, तो हम मोबाइल प्लेटफॉर्म पर डार्ट नेटिव एक्सटेंशन की अनुमति दे सकते हैं। अभी, हम dart_api.h में प्रतीकों को उजागर नहीं करते हैं। स्विच को फ़्लिप करने से पहले हमें निम्नलिखित पर निर्णय लेना होगा:

• पता लगाएँ कि एओटी कंपाइलर को डार्ट कोड से कैसे अवगत कराया जाए, जिसका एकमात्र प्रवेश बिंदु एक ऐसी विधि से है जो मुख्य फ़्लटर इंजन डायनेमिक लाइब्रेरी में नहीं हो सकता है। अन्यथा, ट्री शेकिंग पास कोड से छुटकारा पा सकता है।
• देशी एक्सटेंशन के निर्माण और पैकेजिंग पर मार्गदर्शन प्रदान करें (क्रमशः एंड्रॉइड और आईओएस के लिए ग्रेडल और एक्सकोड)।
• dart_api.h में रूटीन के लिए कुछ ABI स्थिरता गारंटी प्रदान करें। हालांकि यह ज्यादातर स्थिर है, मेरा मानना ​​है कि यह अभी भी विभिन्न तरीकों के हिसाब से विकसित हो रहा है।

अब तक, प्लेटफ़ॉर्म चैनल तंत्र सरल उपयोग के मामलों के लिए पर्याप्त प्रतीत होता है।

सी ++ से जावा और पीछे जाने के लिए एंड्रॉइड पर उनका समाधान क्या था?

मैंने उनके उपयोग के मामले में गहराई से नहीं देखा है। ऐसा लगता है कि उन्होंने सभी बिट्स लिखे हैं जिन्हें सी ++ में बहुत कम विलंबता संचार की आवश्यकता होती है। मैं पूछूंगा कि क्या वे प्रदर्शन-महत्वपूर्ण उपयोग के मामलों के लिए किसी जेएनआई का उपयोग करते हैं (मेरी आंत महसूस नहीं है)।

यह वास्तव में इस बात पर निर्भर करता है कि हम स्पंदन पक्ष पर क्या कर सकते हैं। अगर हम एक इंटरऑप की आपूर्ति कर सकते हैं जो जेएनआई से काफी तेज है, तो यह इन टीमों के लिए एक बड़ी जीत होगी। वे अपने सी ++ कोडबेस को कम कर सकते हैं और ऐप की तरफ अधिक स्थानांतरित कर सकते हैं। अगर हमारा इंटरऑप प्रदर्शन जेएनआई से तुलनीय है तो मुझे यहां बड़ी जीत नहीं दिख रही है। वे संभवत: जारी रख सकते हैं जो वे अभी कर रहे हैं और PlatformChannel का उपयोग कर सकते हैं।

यह ऐसी टीमों को फ़्लटर पर स्विच करने का एक अतिरिक्त कारण देने के बारे में है। मैंने इसे अवरोधक होने के बारे में नहीं सुना है, इसलिए तदनुसार प्राथमिकता दें।

अगर मैं समझता हूं कि आप सही तरीके से क्या कह रहे हैं, तो आप कह रहे हैं कि वर्तमान समाधान जावा में न्यूनतम तर्क के साथ सी ++ में सभी तर्क (कैमरा + यूआई) हैं, और इच्छा इस तर्क के यूआई भाग को डार्ट में ले जाने की है, कम विलंबता वाले UI<->कैमरा अन्तरक्रियाशीलता को खोए बिना।

क्या आप इस बारे में बात कर सकते हैं कि उनकी थ्रेडिंग स्थिति कैसी है? क्या उनके पास कैमरा+यूआई के लिए सिर्फ एक धागा है?

@chinmaygarde हमें

+1

इस मुद्दे के साथ कोई प्रगति?

हम पहले से ही विभिन्न प्लेटफार्मों पर तर्क साझा करने के लिए djinni का उपयोग कर

यदि डार्ट सी/सी++ के साथ एकीकृत हो सकता है, तो मुझे लगता है कि मोबाइल के लिए एक टन देशी पुस्तकालय का पुन: उपयोग करना एक अच्छा विचार है और जेएनआई या ऑब्जेक्टिव सी ++ का उपयोग करके किसी विशिष्ट प्लेटफॉर्म पर बाध्यकारी होने की आवश्यकता नहीं है।

क्या आपने https://github.com/mono/CppSharp पर विचार किया है

C++ आधारित डेटाबेस जैसे Realm को सीधे C++ में एकीकृत करने से महत्वपूर्ण प्रदर्शन और डेवलपर उत्पादकता को बढ़ावा मिलेगा :-) JNI के माध्यम से ऊपर/नीचे जाना इस तरह की बर्बादी होगी।

मैं कंप्यूटर विजन (शायद ओपनसीवी का उपयोग कर) एआर ऐप के लिए स्पंदन पर विचार कर रहा हूं, और एक कुशल और प्रत्यक्ष डार्ट-सी ++ इंटरऑप एक प्रमुख सकारात्मक बिंदु होगा। मुझे लगता है कि गणना की अवधि में चुनौतीपूर्ण ऐप्स करने वाले कई अन्य लोग इस आवश्यकता को साझा कर सकते हैं।

क्या आप कोई पुष्टि कर सकते हैं कि सी ++ इंटरऑप अभी भी उपलब्ध नहीं है? क्या यह संकुल का उपयोग करके किया जा सकता है?

@tofutim Direct c/c++ इंटरऑप अभी भी उपलब्ध नहीं है इसलिए यह मुद्दा अभी भी खुला क्यों है। हालाँकि, आप प्लेटफ़ॉर्म चैनलों का उपयोग कर सकते हैं और फिर अपने C++ कोड के साथ सहभागिता करने के लिए Obj-C/Java का उपयोग कर सकते हैं। यह बहुत अच्छा नहीं है लेकिन इस समय हमारे पास सब कुछ है।

क्या आप कोई पुष्टि कर सकते हैं कि सी ++ इंटरऑप अभी भी उपलब्ध नहीं है? क्या यह संकुल का उपयोग करके किया जा सकता है?

प्लेटफ़ॉर्म लाइब्रेरी के साथ इंटरऑपरेट करने के लिए, प्लेटफ़ॉर्म चैनल तंत्र अभी भी वर्तमान अनुशंसा है।

मूल एक्सटेंशन दस्तावेज़ में वर्णित एक अधिक प्रदर्शनकारी तंत्र को तुच्छ रूप से जोड़ा जा सकता है। हालांकि, मुझे dart_api.h से उजागर किए गए प्रतीकों के लिए किसी भी एबीआई स्थिरता गारंटी के बारे में पता नहीं है। अगर @a- siva और टॉनिक का एक सबसेट बना सकते हैं।

मेरी समझ यह है कि यह बग एक सी-एपीआई और टूलिंग हुक प्रदान करने के बारे में है ताकि पूरी तरह से सी/सी ++ प्लगइन होना आसान हो सके (कोई ओब्जे-सी/जावा शिमिंग आवश्यक नहीं है, लेकिन फिर भी प्लेटफॉर्म_चैनल्स के माध्यम से एसिंक्स)।

मुझे नहीं लगता कि हमें इस समय देशी एक्सटेंशन जैसे सिंक्रोनस विधियों पर विचार करना चाहिए। (लेकिन ईमानदारी से मैं इसे @Hixie या @cbraken के लिए

@eseidel

मुझे नहीं लगता कि हमें इस समय देशी एक्सटेंशन जैसे सिंक्रोनस विधियों पर विचार करना चाहिए

ऐसा क्यों है?

C पर कॉल करने का वर्तमान तरीका है Dart -> Java -> C
हम जेएनआई को दो बार पार करते हैं, है ना?
पहली बार: dart से Java प्लेटफॉर्म चैनलों के माध्यम से (हुड जेएनआई कॉल के तहत इस्तेमाल किया गया, है ना?)
दूसरी बार: Java -> C जेएनआई के माध्यम से

एक उदाहरण के रूप में, मेरी परियोजना की जरूरतों के दृष्टिकोण से, स्थिरता गारंटी के बिना भी dart_api.h तक पहुंच होना (उदाहरण के लिए एक प्रयोगात्मक सुविधा के रूप में) पहले से ही काफी अच्छा होगा। मेरी मुख्य चिंता बाइनरी डेटा (छवियों) के बड़े बूँद को डार्ट की ओर से C ओर ले जाना है और बिना मार्शलिंग और आदर्श रूप से कॉपी करना है। एकता/मोनो इसे प्राप्त करता है ।

डार्ट-एसडीके अंक 31960 से मैं समझता हूं कि आइसोलेट्स का वर्तमान कार्यान्वयन कॉपी किए बिना डेटा पास करने की अनुमति नहीं दे सकता है (हालांकि सिद्धांत रूप में यह पता लगाना संभव होना चाहिए कि आइसोलेट ए में बनाए गए बफर का उपयोग बी को अलग करने के लिए पारित होने के बाद नहीं किया जाता है। और इसलिए इसके स्वामित्व को कॉपी किए बिना स्थानांतरित किया जा सकता है.. उस मोर्चे पर कोई योजना?), लेकिन अगर कम से कम एक आइसोलेट में C से/के लिए कोई मार्शलिंग नहीं है तो यह अच्छा होगा।

फ्लैटबफ़र्स के साथ मार्शलिंग से बचा जा सकता है जो जल्द ही उतरने लगता है: https://github.com/google/flatbuffers/pull/4676
या केवल एक बाइट फ़ील्ड का उपयोग करके प्रोटोबफ़ संदेशों के साथ।

बेशक, इसमें बड़ी मात्रा में बाइट कॉपी करना शामिल है, इसलिए सभी उपयोग के मामलों के लिए यह बहुत अच्छा नहीं है।

मैं यहाँ प्रस्तुत कम से कम तीन अलग-अलग इच्छाएँ सुन रहा हूँ:

1. जावा/ओबीजे-सी गोंद का एक गुच्छा जोड़ने के बिना केवल सी/सी ++ कोड का उपयोग करके स्पंदन के लिए आसानी से एक प्लगइन लिखने का एक तरीका चाहते हैं (यह इस बग की मेरी मूल समझ थी और कुछ मुझे निश्चित रूप से लगता है कि हम कर सकते हैं/करना चाहिए) .
2. डार्ट के अंदर/बाहर बड़ी मात्रा में डेटा को जल्दी/कम विलंबता/आदि के साथ स्थानांतरित करने का एक तरीका चाहते हैं। (संभावित रूप से सी ++ सहित विभिन्न भाषाओं से। यह एक बहुत ही वैध मामला लगता है! मैं एक उदाहरण सहित एक अलग बग दर्ज करने की दृढ़ता से अनुशंसा करता हूं।)
3. डार्ट को सिंक्रोनस कॉल/ऑब्जेक्ट्स के साथ विस्तारित करने का कोई तरीका चाहते हैं? (उदाहरण के लिए मूल एक्सटेंशन या अन्य तरीके? यह भी पूरी तरह से करने योग्य है। एपीआई स्थिरता के आसपास संभावित कठिनाइयां हैं, और मुझे लगता है कि हम कार्रवाई करने से पहले विशिष्ट उपयोग के मामले के बारे में अधिक जानना चाहते हैं।)

उपरोक्त पढ़ने से मेरी प्रतिक्रिया यह है कि हमें कुछ अतिरिक्त बगों को विभाजित करने पर विचार करना चाहिए। हमें निश्चित रूप से सी ++ इंटर-ऑप के आसपास कुछ निवेश करने की ज़रूरत है, लेकिन इस लंबे धागे से यह निर्धारित करना मुश्किल है कि हमें किस सटीक उपयोग के मामलों को संबोधित करना चाहिए और किस क्रम में?

क्या इच्छुक पक्ष अपने वांछित उपयोग के मामलों के साथ नई बग दर्ज करने के इच्छुक/सक्षम होंगे और उन्हें यहां वापस लिंक करेंगे? इस समस्या स्थान में सामान्य रुचि को ट्रैक करने के लिए इस मुद्दे को खुला छोड़ कर खुशी हो रही है।

प्रदर्शन और 2. ऊपर के संबंध में: हालांकि मुझे यकीन है कि फ़्लटर के प्लेटफ़ॉर्म_चैनल के प्रदर्शन में सुधार किया जा सकता है (और हमें सभी उपयोग मामलों को कवर करने के लिए अन्य प्लगइन/इंटर-ऑप विधियों की आवश्यकता होगी), हम कुछ ठोस चाहते हैं मामलों का उपयोग करें (शायद वे मौजूद हैं और मैंने उन्हें नहीं देखा है?) जहां कार्रवाई करने से पहले फ़्लटर के प्लेटफॉर्म_चैनल्स का प्रदर्शन एक अड़चन है। सिस्टम के प्रदर्शन को अनुकूलित करने के साथ मेरा अनुभव यह है कि मेरी आंत की प्रवृत्ति अक्सर गलत होती है। हालांकि जेएनआई या प्लेटफॉर्म_चैनल जैसी चीजें संभावित बाधाओं की तरह महसूस करती हैं, हम वास्तव में तब तक नहीं जान पाएंगे जब तक हम माप नहीं लेते।

आपकी मदद और प्रतिक्रिया के लिए आप सभी का फिर से धन्यवाद!

जावा/ओबीजे-सी गोंद का एक गुच्छा जोड़ने के बिना केवल सी/सी ++ कोड का उपयोग करके स्पंदन के लिए आसानी से एक प्लगइन लिखने का एक तरीका चाहते हैं (यह इस बग की मेरी मूल समझ थी और कुछ मुझे निश्चित रूप से लगता है कि हम कर सकते हैं/करना चाहिए) .

यह स्पंदन के लिए बेहतर स्क्लाइट एकीकरण भी देगा + क्रिप्टो, एसएसएच और अन्य सामानों के लिए बहुत सी सी/रस्ट पुस्तकालय हैं। इसे आसानी से उपयोग करने में सक्षम होना अच्छा होगा।

@eseidel

मैं प्रस्तुत कम से कम तीन अलग-अलग इच्छाओं को सुन रहा हूँ

मेरा वोट 1.)

स्पंदन डॉक्स को पढ़ने से प्लेटफॉर्म चैनलों को सी का समर्थन करने के लिए विस्तारित करना काफी "सरल" होना चाहिए।
एकमात्र उपन्यास चीज शायद वर्तमान प्रक्रिया में _डायनामिक साझा ऑब्जेक्ट_ (ओं) को लोड करने का एक तरीका होगा।

मैं कुछ इस तरह दिखने के लिए _Android-C_-उपयोग की कल्पना करूंगा:

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

संकल्पनात्मक रूप से, कम से कम _एंड्रॉइड-सी_ के लिए, आपको यह तय करना होगा कि जावा और सी के संयोजन को कैसे संभालना है।

@eseidelGoogle
हम वर्तमान में जावा और स्विफ्ट रैपर के माध्यम से गोलांग कोड को उजागर करते हैं और विलंबता एक सराहनीय मुद्दा है जिसे हम मार रहे हैं।
क्यों ?

• हमें कई प्लेटफार्मों के बीच व्यावसायिक तर्क साझा करने की आवश्यकता है।
• स्क्रीन शेयरिंग जैसी वीडियो और छवि कार्यक्षमता के लिए।
• डीबी के लिए

यदि आप सीधे स्तर पर गोलंग समर्थन जोड़ने में सक्षम हैं जो गले लगाने में अंतर लाएगा!
मोबाइल के लिए गोलंग कोड संकलित करना भी बिना किसी एलडीएफएलैग्स जादू के बहुत आसान है, इसलिए मुझे लगता है कि यह लोकप्रिय होगा। मैं कुछ अन्य गोलंग कोडर्स के बारे में जानता हूं जो वर्तमान में मेथड चैनल्स का भी उपयोग कर रहे हैं।
जहाँ तक क्रमांकन की बात है, हम वर्तमान में प्रोटोबफ़्स और फ़्लैटबफ़र्स का उपयोग करते हैं।

उदाहरण:
https://github.com/dnfield/flatbuffers/blob/master/samples/sample_binary.go

फुकिया में यह FIDL के साथ किया जाता है और इसमें c, रस्ट और गोलंग के साथ बाइंडिंग होती है।
इसका उपयोग करने के लिए बहुत बढ़िया है और मैं एक एम्बेडेड बोर्ड पर जंग और गोलंग को आजमाने का आनंद ले रहा हूं।

आईओएस और जावा के माध्यम से भी फिडल सामान का पर्दाफाश करना संभव होना चाहिए।
यह मोबाइल और डेस्कटॉप पर फुकिया और स्पंदन के बीच एक अच्छा ऑनरैंप देगा।
बस एक विचार जिसके साथ मैं खेल रहा हूँ

@eseidelGoogle
Hiixe ने मुझे बताया कि FIDL स्पंदन स्तर पर नहीं किया जा सकता क्योंकि FIDL फुकिया में जिक्रोन से कर्नेल कोड पर निर्भर करता है। इसलिए फ़्लटर के भीतर FIDL IPC शैली की कार्यक्षमता को दोहराने का एकमात्र तरीका फ़्लटर इंजन में FIDL संस्करण लिखना होगा। लेकिन तब मैं इसके साथ खेल रहा था और देखा कि यह फ्लैटबफर के समान ही है। तो क्यों न फ़्लटर और सीपीपी या गोलांग या फ़्लटर पर जंग परत के बीच क्रमांकन परत के लिए फ़्लैटबफ़र्स का उपयोग करें। ?

इस पर बस +1, हमारे पास सुपरपावर नामक लाइब्रेरी का उपयोग करने वाला एक स्पंदन ऐप है। सुपरपावर सी ++ में लिखा गया है, फिर हम इसके साथ बातचीत करने के लिए जावा और जेएनआई प्रकार की सामग्री का उपयोग करते हैं, जिसे हम बदले में प्लेटफॉर्म चैनलों का उपयोग डब्ल्यू/जावा कोड पर बात करने के लिए करते हैं। यह निश्चित रूप से अच्छा होगा यदि हम बिचौलिए को छोड़ दें।

यह इसके साथ ही रियलम जैसे लोकप्रिय मोबाइल पुस्तकालयों को स्पंदन संस्करण बनाने से रोकता है क्योंकि उनका मूल सी/सी ++ में लिखा गया है और वे जावा/ओबीजेसी/स्विफ्ट बिचौलिए से भी निपटना नहीं चाहते हैं।

उन कारणों से, सामान्य स्थिरता के अलावा, मुझे लगता है कि यह मुद्दा इस समय स्पंदन में सबसे आवश्यक परिवर्तनों में से एक है। (अधिक विशेष रूप से #1 पर @eseidelGoogle की सूची।)

यदि आप प्लेटफ़ॉर्म एक्सटेंशन में जावा/जेएनआई को बायपास करने के लिए एक तर्क सुनना चाहते हैं (यानी, केवल डेवलपर के लिए जावा गोंद परत को छिपाना/स्वचालित नहीं करना), तो सुपरपावर के पास उस विषय पर कहने के लिए बहुत कुछ है: https://www.youtube। कॉम/घड़ी?v=LzIuir3r6Co

@pnico क्या आप बता सकते हैं कि यह कैसे तर्क दे रहा है कि जावा/जेएनआई को बायपास किया जाना चाहिए? ऐसा लगता है कि आपके ऑडियो प्रोसेसिंग कोड से थोड़ा अधिक सी ++ में लिखा जाना चाहिए। (इसका मतलब यह नहीं है कि आप इसे जेएनआई या किसी अन्य माध्यम से कॉल नहीं कर सकते हैं)

@ csga5000 आप पूरी तरह से सही हैं, इसका कोई मतलब नहीं है: डी जेएनआई शायद प्रदर्शन को वास्तव में प्रभावित नहीं करेगा जब तक कि आप अधिक गूढ़ सामान करने की कोशिश नहीं कर रहे हों। मुझे लगता है कि यह वास्तव में सुविधा/रखरखाव के लिए नीचे आता है, और मुझे लगता है कि जावा/सी ++ और डार्ट में अधिक ऐप-विशिष्ट कोड को स्थानांतरित करने की क्षमता हो सकती है

मुझे लगता है कि @pnico कह रहा है कि वह इसे जिनी के माध्यम से कॉल कर सकता है, लेकिन यह कि जिनी बहुत अधिक विलंबता जोड़ता है।
तो perf समस्या है।
हाँ नही ??

यह ज्यादातर क्रिप्टो से संबंधित कार्यों के लिए बहुत बड़ा अंतर ला सकता है।

इसके अलावा, मैं एंड्रॉइड थिंग्स के लिए मानता हूं, हालांकि मैंने प्रयोग नहीं देखा है या नहीं किया है
और समय संवेदनशील gpio के लिए बेंचमार्क न तो c और न ही dart a . से अधिक के लिए
वर्ष।

शनिवार, 9 जून 2018 को, 10:52 एड़ी डब्ल्यूएम, नोटिफिकेशन @github.com ने लिखा:

यह ज्यादातर क्रिप्टो से संबंधित कार्यों के लिए बहुत बड़ा अंतर ला सकता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/flutter/flutter/issues/7053#issuecomment-395927258 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AFHMcSI2JDHbgv3iYrStDN5mlzkQ8XEkks5t6xxMgaJpZM4K-PLw
.

तब से कोई प्रगति?

जब तक यह हल नहीं हो जाता है, तब तक एक उदाहरण स्पंदन प्लगइन के लिए एक सिफारिश है जो दिखाता है कि एसी/सी ++ lib को कैसे एकीकृत किया जाए? क्या जिन्नी जाने का एक अच्छा तरीका है?

जब तक इसका समाधान नहीं हो जाता, तब तक सी/सी++ को एकीकृत करने का एकमात्र तरीका देशी एंड्रॉइड और आईओएस कोड लिखना, फिर प्लेटफॉर्म चैनलों का उपयोग करके डार्ट कोड में इंटरफेस करना

मैंने प्लगइन्स लागू किए हैं जो प्लेटफॉर्म चैनल (जार फाइलों और कोकोपोड्स के लिए) का उपयोग करते हैं। मैं एक उदाहरण प्लगइन की तलाश में हूं जो दिखाता है कि उसी सी/सी ++ lib (एंड्रॉइड और आईओएस दोनों के लिए) को कैसे एकीकृत किया जाए। कोई सुझाव?

@ mmcc007 इस तरह आप इसे जावा या स्विफ्ट में करते हैं।

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

स्विफ्ट: https://www.google.com/search?client=opera&q=swift+use+C%2B%2B&sourceid=opera&ie=UTF-8&oe=UTF-8

आप देख सकते हैं कि यदि आप वास्तव में एक उदाहरण चाहते हैं तो सुपरपावर आपको इसे करने की सलाह देता है (यह सिर्फ एक है जिसे मैं जानता हूं): https://github.com/superPowerSDK/Low-Latency-Android-iOS-Linux-Windows-tvOS-macOS- इंटरएक्टिव-ऑडियो-प्लेटफ़ॉर्म
उदाहरण फ़ोल्डर देखें। उदाहरण के लिए, https://github.com/superpowerSDK/Low-Latency-Android-iOS-Linux-Windows-tvOS-macOS-Interactive-Audio-Platform/tree/master/Examples_Android/SuperpoweredRecorder/app/src/main के भीतर है java/com/superPowered/recorder/MainActivity.java जो cpp/RecorderExample.cpp में कोड का संदर्भ देता है

@ csga5000 ऐसा लगता है कि यह यथोचित रूप से सीधे आगे होगा .. पहली समीक्षा पर। अभी भी एक काम कर रहे स्पंदन प्लगइन के माध्यम से देखना अच्छा होगा। धन्यवाद।

इसके लिए +1। सी ++ का उपयोग कर स्पंदन ऐप के किसी भी कार्यशील उदाहरण को अच्छी तरह से प्राप्त किया जाएगा

एक परियोजना है जो गोलंग के लिए ऐसा करती है और मुझे लगता है कि यह वही दृष्टिकोण है
सी ++ के लिए भी इस्तेमाल किया जा सकता है।

गोलंग प्रोग्राम jsonrpc का उपयोग करता है।
फिर आपको बस इतना करना है कि jsonrpc के साथ अपना खुद का गोलांग कोड सामने रखना है।

फिर सब कुछ बहुत आसान है।

मुझे लगता है कि प्लेटफ़ॉर्म चैनल केवल JSON को अज्ञेय क्रमांकन के रूप में समर्थन करते हैं
प्रारूप ?

बुध, 18 जुलाई 2018, 16:50 जेफरसन ब्लेडसो, नोटिफिकेशन @github.com . पर
लिखा था:

इसके लिए +1। सी ++ का उपयोग कर एक स्पंदन ऐप का कोई भी काम करने वाला उदाहरण होगा
ठीक ढंग से प्राप्त

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने टिप्पणी की थी।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/flutter/flutter/issues/7053#issuecomment-405958345 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ATuCwkPbb9vLdoaEwM-bLhYPZxtyQ5Vjks5uH0sqgaJpZM4K-PLw
.

हाय, कोई खबर?

बस यह जानना चाहते हैं कि क्या इस धागे में कोई भी सुपरपावर लाइब्रेरी को सीधे स्पंदन ऐप में एकीकृत करने में कामयाब रहा है?

हाँ @ कौशल-अप हमने यह किया है। ओपन सोर्स प्रोजेक्ट में नहीं, इसलिए मैं नहीं दिखा सकता। लेकिन अगर आप मेरे सुझावों को पहले देखते हैं, तो आप इसे वैसे ही करते हैं। हालांकि आपको प्रत्येक सीपीयू आर्किटेक्चर के लिए अपना स्पंदन ऐप बनाने की आवश्यकता हो सकती है

मैं समझता हूं कि आपने जेएनआई/जावा के माध्यम से किया है न कि सीधे डार्ट से। मैं सोच रहा था कि प्लेटफॉर्म विशिष्ट कोड से पूरी तरह से बचना संभव है या नहीं।

हालांकि आपको प्रत्येक सीपीयू आर्किटेक्चर के लिए अपना स्पंदन ऐप बनाने की आवश्यकता हो सकती है

आपका मतलब प्रत्येक आर्किटेक्चर के लिए एक अलग ऐप है, या बस सभी समर्थित आर्किटेक्चर निर्दिष्ट करना है?

BTW, हमारे पास पहले से ही जावा में मूल रूप से लिखा गया एक कार्यशील ऐप है। हालांकि, अब जब हमें एक आईओएस ऐप भी बनाना है, तो मैं सोच रहा था कि क्या स्पंदन में एक बनाना (स्विफ्ट/एक्सकोड पर प्रयासों को खर्च करने के बजाय) भविष्य में रखरखाव के नजरिए से अधिक समझ में आएगा, एकल कोड आधार के लाभ के साथ।

कुंआ। दायरे आप लोगों के लिए एक रास्ता प्रदान करने की प्रतीक्षा कर रहा है: https://github.com/realm/realm-object-server/issues/55

लुकास्पिली : मुझे लगता है कि हर कोई अभी भी प्रतीक्षा कर रहा है: स्पंदन/स्पंदन#7053
bmunkholm: @lukaspili हाँ यह निश्चित रूप से एक शर्त है।

इसके लायक क्या है, मैं भी इसका इंतजार कर रहा हूं। वास्तव में एक्सएफ ऐप्स को स्पंदन डिट्टो के साथ बदलने पर विचार नहीं कर सकता जब तक कि आप लोगों को उचित नलसाजी नहीं मिलती। जैसा कि यह वर्तमान में खड़ा है, ज़ामरीन इस विभाग में पानी से बाहर फड़फड़ाता है।

इस पार्टी के लिए देर हो चुकी है लेकिन इस धागे के लिए एक बड़ा +1 है।

मैं डेस्कटॉप ऐप्स विकसित करता हूं, कोड की एक पंक्ति के रूप में मेरा विचार (डेस्कटॉप के लिए):

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

यदि स्पंदन सी ​​++ के लिए प्रथम श्रेणी के समर्थन की पेशकश कर सकता है, तो मुझे लगता है कि यह सामान्य दृष्टिकोण क्रॉस प्लेटफॉर्म एप्लिकेशन डेवलपमेंट के लिए एक पूर्ण विजेता हो सकता है, न कि केवल "मोबाइल पहले" बल्कि दुनिया पहले। क्यूटी छोटे देवों के लिए मूल्यवान है, माना जाता है और आधुनिक सी ++ को गले नहीं लगाता है और वास्तव में कुछ भी प्रतिस्पर्धा नहीं करता है, क्या स्पंदन कम से कम यूआई पाई खा सकता है?

पीएस: मैं डार्ट विरोधी नहीं हूं, यह एक और नया सी #/गो/जंग/आदि है। प्रतिस्पर्धी भाषा जो एक नए मंच के लिए सुपर उत्पादक हो सकती है लेकिन उच्च प्रदर्शन डेस्कटॉप (यहां मेरी रुचि) अनुप्रयोगों की दुनिया दृढ़ता से सी ++ है, व्यापक ओएस और पुस्तकालय समर्थन के साथ, एक ऐसी भाषा जो समुद्री मील की दर से आगे बढ़ रही है (यह नहीं है सी), और मुझे लगता है कि स्पंदन इसके लायक है!

मुझे नहीं लगता कि स्पंदन निकट भविष्य में किसी भी बिंदु पर C++ का समर्थन करेगा, और यह निश्चित रूप से अब संभव नहीं है। और मैं एक के लिए जबरदस्त रूप से डार्ट को पसंद करता हूं - सी ++ में ऐप्स लिखना भी w/स्पंदन बहुत अधिक प्रयास करेगा। और मुझे नहीं लगता कि सी ++ सीधे डेस्कटॉप समर्थन में अनुवाद करता है, उन्हें अभी भी काफी कोड लिखना होगा, और डार्ट वीएम को वैसे भी डेस्कटॉप के लिए काम करना चाहिए। मुझे लगता है कि अधिकांश अनुप्रयोगों के लिए प्रदर्शन नगण्य है।

मुझे लगता है कि अंत में Google इंटरऑपरेबिलिटी का समर्थन करना चाहता है ताकि आप किसी भी समर्थित भाषाओं या यहां तक ​​​​कि उक्त भाषाओं के संयोजन का उपयोग करके किसी भी और सभी प्लेटफॉर्म के लिए स्पंदन ऐप लिख सकें। लेकिन मैं यह उम्मीद नहीं करूंगा कि फुकिया के रिलीज होने के बाद या बाद में भी। अभी के लिए उनका लक्ष्य एक बार कोड लिखना आसान बनाना है। डार्ट उस लक्ष्य से मेल खाता है क्योंकि इसका उपयोग करना/सीखना आसान है, कुशल है, और वैसे भी Google की भाषाओं में से एक है। मैं वास्तव में प्रथम श्रेणी सी ++ समर्थन रखने वाले औसत उपयोगकर्ता के लिए लगभग कोई व्यावहारिक लाभ नहीं देखता हूं। मोबाइल ऐप में प्रदर्शन नगण्य है, और प्लेटफॉर्म चैनल w/C++ का उपयोग करना w/मौजूदा C++ पुस्तकालयों को इंटरैक्ट करने के उद्देश्य से सुविधाजनक होगा। उज्ज्वल पक्ष पर, आप निश्चित हो सकते हैं कि वे अंततः डेस्कटॉप का समर्थन करने के लिए स्पंदन का इरादा रखते हैं (अच्छी तरह से कम से कम फूशिया के कैपिबारा पर, लेकिन मुझे संदेह है कि वे वहां रुकेंगे)।

यह धागा डार्ट/स्पंदन से प्रत्यक्ष एकीकरण w/C++ का समर्थन करने के बारे में है, जो उम्मीद है कि निकट भविष्य में आ सकता है।

मुझे नहीं लगता कि स्पंदन C++ का समर्थन करेगा
मैं वास्तव में प्रथम श्रेणी के C++ समर्थन के औसत उपयोगकर्ता के लिए लगभग कोई व्यावहारिक लाभ नहीं देखता हूं।

यह इस बारे में नहीं है कि फ़्लटर/डार्ट बनाम सी ++ कितना भयानक है, यह वर्तमान पारिस्थितिकी तंत्र में फिट होने के लिए आवश्यक एकीकरण के बिंदु/आसानी के बारे में अधिक है। पुस्तकालयों की एक लंबी सूची साझा वस्तु (एक नाम के लिए ओपनसीवी) के रूप में मौजूद है जो उद्योग मानक हैं, आप लोगों से उन्हें डार्ट में फिर से लिखने की उम्मीद नहीं कर सकते हैं?

मोबाइल ऐप में प्रदर्शन नगण्य है, और प्लेटफॉर्म चैनल w/C++ का उपयोग करना w/मौजूदा C++ पुस्तकालयों को इंटरैक्ट करने के उद्देश्य से सुविधाजनक होगा।

इसके विपरीत, इस संदर्भ में चैनलों का उपयोग करना उप-इष्टतम है, उन मामलों के बारे में सोचें जहां आपको स्मृति (छवियों) पर एक बड़ी बाइनरी ऑब्जेक्ट के साथ काम करने की आवश्यकता है, आपको या तो इसकी आवश्यकता होगी:
1- इन बायनेरिज़ को/से C++ मेमोरी में कॉपी करें
2- पुस्तकालय के साथ इंटरफेस करने के लिए जेएनआई के साथ काम करें (और इन बायनेरिज़ को गतिशील रूप से आवंटित पॉइंटर्स को संभालें)
चैनलों का उपयोग करके आपके द्वारा किए जाने वाले सीरियलाइज़िंग/deserializing मूल्यों/पैरामीटर लागत के ऊपरी हिस्से का उल्लेख नहीं करना।

एक अच्छा ढांचा नई सुविधाओं/प्रतिमानों के बीच संतुलन है जो इसे पेश करता है बनाम वर्तमान पारिस्थितिक तंत्र/विरासत के साथ एकीकृत करना कितना आसान है, जिसे हम अस्वीकार नहीं कर सकते हैं सी ++ का हिस्सा है।

@nhachicha @ csga5000 असहमत नहीं था कि सीधे सी ++ को एकीकृत करना महत्वपूर्ण था; वह पिछली टिप्पणी का जवाब दे रहा था जिसमें पूछा गया था कि क्या फ़्लटर को सीधे सी ++ से इस्तेमाल किया जा सकता है , जैसे कि, बिना किसी डार्ट कोड की आवश्यकता के।

मोबाइल ऐप में प्रदर्शन नगण्य है, और प्लेटफॉर्म चैनल w/C++ का उपयोग करना w/मौजूदा C++ पुस्तकालयों को इंटरैक्ट करने के उद्देश्य से सुविधाजनक होगा।
@nhachicha मैं और अधिक सहमत नहीं हो सका।

सच्चाई उन अनुप्रयोगों के लिए है जिन्हें दांत काटने के प्रदर्शन की आवश्यकता नहीं है (जो कि कई हैं) तो क्यों न कुछ अधिक उत्पादक के लिए हार्ड को मास्टर सी ++ में स्वैप करें, वास्तव में अकेले डार्ट पर ही क्यों रुकें, इनमें से किसी भी सुपर लोकप्रिय में स्लॉट क्यों नहीं, ( डार्ट की तुलना में कई अधिक लोकप्रिय/स्थापित) भाषाएं:

• सी#/.नेट कोर रनटाइम
• जावास्क्रिप्ट/टाइपस्क्रिप्ट V8 रनटाइम (उस समय आपके पास लगभग एक ब्राउज़र होगा लेकिन ऐसा क्या है)
• जंग (भी तेज!)
• GoLang
• अजगर
• [अपना पसंदीदा यहां डालें]...

और जितना मैं व्यक्तिगत रूप से उन भाषाओं में से कुछ को हर रोज प्यार करता हूं और उपयोग करता हूं, सी और सी ++ लिनक्स के मूल में हैं इसलिए एंड्रॉइड, आईओएस और डेस्कटॉप प्लेटफॉर्म जैसे विंडोज, मैकओएस और अन्य डेस्कटॉप। उपरोक्त भाषाओं में से आधी (डार्ट सहित) C++ में लिखी गई हैं। अत्याधुनिक तकनीकों के लिए समय-समय पर ट्यून किए गए देशी प्रदर्शन की आवश्यकता होती है, जैसे कि एआई (टेंसरफ्लो सी ++ है, कैफ सी ++, पाइटोरच सी पायथन के तहत है, आदि), ऑगमेंटेड रियलिटी लाइब्रेरी, एएए गेम इंजन और कुछ भी जो एक जीपीयू (सीयूडीए के पास जाने की जरूरत है) , सी/सी ++ से कहा जाता है)।

उसी कारण से कि फ़्लटर रेंडरिंग इंजन स्वयं C ++ (देशी, उच्च प्रदर्शन, बैटरी/मेमोरी/सीपीयू कुशल)

_एक साइड नोट के रूप में, मैं पूरी तरह से सी/सी ++ में सब कुछ लिखने के साथ घर पर हूं, फॉर्म सत्यापन से लेकर पिक्सेल शेडर्स तक, लेकिन मैं नाटक नहीं कर रहा हूं कि इस रेपो को देखने वाले कई लोगों का विचार है - और ऐसा इसलिए है क्योंकि मुझे सी ++ ए अत्यधिक उत्पादक भाषा - हालांकि पूरी तरह से एक व्यक्तिगत पसंद।_

यह मुख्य कारणों में से एक है कि हमें सी ++ एकीकरण की आवश्यकता है

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

C/C++ एकीकरण के बारे में जाने के दो सरल तरीके हैं:

• सी ++ में विधि चैनल कार्यान्वयन प्रदान करें
• डार्ट वीएम नेटिव एक्सटेंशन सपोर्ट प्रदान करें

दुर्भाग्य से इन दोनों में बड़ी कमियां हैं जो हमें उनका पीछा करने से रोकती हैं:

• विधि चैनल उच्च ओवरहेड एब्स्ट्रैक्शन हैं - जबकि कम ओवरहेड इंटरैक्शन वांछनीय होने पर सी/सी ++ एकीकरण का अनुरोध किया जाता है। इसका मतलब है कि विधि चैनल वास्तव में समस्या का समाधान नहीं करेंगे।
• डार्ट वीएम नेटिव एक्सटेंशन के लिए लोगों को डार्ट वीएम सी एपीआई का उपयोग करने की आवश्यकता होती है - उस पर बहुत अधिक बाहरी निर्भरताएं पेश करना वांछनीय नहीं हो सकता है, विशेष रूप से इस तथ्य को देखते हुए कि एपीआई की उम्र अच्छी नहीं थी और कुछ गंभीर रिफैक्टरिंग की आवश्यकता होती है।

ऐसा लगता है कि एक अधिक वांछनीय विकल्प dart:ffi का परिचय है - डार्ट वीएम का एक मुख्य घटक जो सीधे मूल कोड से जुड़ने की अनुमति देगा जिससे लोग कुछ लिख सकें:

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

इस तरह के एफएफआई को लंबे समय तक लागू करने में हमारी कुछ रुचि थी - मैं उम्मीद करता हूं कि हम निकट भविष्य में कुछ समय इसके साथ प्रयोग करेंगे, लेकिन मैं किसी ठोस समयसीमा के लिए प्रतिबद्ध नहीं हूं।

@ kirbyfan64 बिल्कुल सही है, @nailgilaziev , @bytesoftly मैं यह कहने की कोशिश नहीं कर रहा हूं कि सी ++ एकीकरण की आवश्यकता नहीं है, मैं बस इतना कह रहा था कि मुझे नहीं लगता कि स्पंदन समर्थन सी ++ डार्ट के स्थान पर बनाने के लिए इतना कारण/मांग है - लेकिन मैं यह नहीं कह रहा हूं कि एकीकरण की जरूरत नहीं है। @mraleph जो कह रहा है वह मुझे स्मार्ट लगता है।

@mraleph डार्टिनो का एफएफआई के लिए समान कार्यान्वयन था। पुनरुत्थान करना कितना कठिन है?

@listepo इसके कुछ हिस्से। डार्टिनो का एफएफआई का कार्यान्वयन बहुत गतिशील था - यह ऐसा कुछ नहीं है जिसे हम डार्ट 2 के लिए चाहते हैं जो डार्ट 1 की तुलना में काफी अधिक स्थिर है।

खेल के लिए देर हो चुकी है, लेकिन यहां एक और उपयोग का मामला है: हम क्रिप्टोग्राफिक उद्देश्यों के लिए सी फाइलों और विधियों को डार्ट में शामिल करना चाहते हैं।

हम जो उम्मीद करेंगे वह निम्नलिखित हैं:
1) आईओएस और एंड्रॉइड के लिए समान कोड, यानी ओबीजेसी या जेएनआई परतों के माध्यम से नहीं जा रहा है।
2) उम्मीद है कि दो बार जेएनआई के माध्यम से जाने से अधिक कुशल कार्यान्वयन।
3) फॉलो-अप वेब ऐप जैसे एंगुलरडार्ट में डार्ट मॉडल कोड का पुन: उपयोग करने की संभावना, या इस प्रोजेक्ट का उपयोग करके फॉलो-अप डेस्कटॉप ऐप: https://github.com/google/flutter-desktop-embeding

मेरा मानना ​​है कि हम जो चाहते हैं वह ऊपर बताए गए बिंदु 2 @eseidelGoogle के सबसे करीब है। सिंक्रोनस सपोर्ट के लिए, मैं इसे "अच्छा होना" मानता हूं, क्योंकि एसिंक्रोनस फ़ंक्शंस का उपयोग किसी कंस्ट्रक्टर में नहीं किया जा सकता है, जहाँ कोई त्वरित हैश गणना करना चाहता है। लेकिन डार्ट्स एसिंक तरीके से अभ्यस्त होने के कारण, ऊपर दिए गए अंक 1)-3) प्राप्त करने की सामान्य संभावना की तुलना में सिंक्रोनस समर्थन कम महत्वपूर्ण प्रतीत होता है।

@mraleph द्वारा सुझाए गए एफएफआई का उपयोग करना, क्या यह मेरी पिछली टिप्पणी के अनुसार 1) -3 के लिए अनुमति देगा, या इसका मतलब यह होगा कि विभिन्न प्लेटफार्मों (एंड्रॉइड, आईओएस, ...) पर अलग-अलग कोड की आवश्यकता है?

@CryptUser यदि आपका C/C++ कोड सभी प्लेटफॉर्म पर समान है तो FFI के माध्यम से कॉल करने के लिए डार्ट कोड भी सभी प्लेटफॉर्म पर समान होगा।

@mraleph बहुत अच्छा लगता है! यह देखते हुए कि मूल मुद्दे में 200 से अधिक अंगूठे हैं, क्या इस पर प्राथमिकता बढ़ाने का कोई मौका है?

@mraleph कहीं न कहीं डार्ट में FFI के लिए एक खुला मुद्दा है?

@dnfield मैंने अभी एक फाइल की है https://github.com/dart-lang/sdk/issues/34452

मैं सी/सी++/रस्ट कोड लिखने में सक्षम होना चाहता हूं और इसे एफएफआई पर उपयोग करने में सक्षम होना चाहता हूं

उदाहरण:

मैं एंड्रॉइड टैबलेट (एंड्रॉइड 4.4) पर स्पंदन का परीक्षण करता हूं।
स्पंदन तेजी से भागो।
लेकिन जब मैं प्लेटफॉर्म चैनल का उपयोग करने वाले वर्गफलाइट के साथ 1000 पंक्ति पढ़ने की कोशिश करता हूं, तो यह हास्यास्पद धीमा है।
कारण: मैं sqlite कर्सर रीडर का उपयोग नहीं कर सकता।

लेकिन अगर मैं सीधे एसक्लाइट लाइब्रेरी का उपयोग कर सकता हूं, तो वही क्वेरी तत्काल है। (xamarin और देशी Android परियोजना के साथ परीक्षण किया गया)।

हम अभी इस बारे में चर्चा कर रहे हैं कि इस तक कैसे पहुंचा जाए। जैसा कि ऊपर बताया गया है https://github.com/flutter/flutter/issues/7053#issuecomment-377711814 इस मुद्दे के कई हिस्से हैं और शायद इसे विभाजित करने की आवश्यकता है। :)

लेकिन हमने पाया है कि कुछ इंजीनियर एफएफआई की खोज में रुचि रखते हैं (जैसा कि https://github.com/flutter/flutter/issues/7053#issuecomment-415161464 में बताया गया है)। अभी हमारा ध्यान 1.0 से बाहर निकलने पर है, लेकिन एक बार ऐसा हो जाने के बाद यह सूची में सबसे ऊपर होगा। आपकी सभी निरंतर प्रतिक्रिया के लिए फिर से धन्यवाद। जब हमारे पास साझा करने के लिए और प्रगति होगी तो हम इस समस्या को अपडेट करेंगे।

मैं मैटलैब/सिमुलिंक उपयोगकर्ता भी हूं। मैं अत्यधिक अनुकूलित सीपीयू विशिष्ट सी/सीपीपी कोड उत्पन्न कर सकता हूं। मैं अपने एल्गोरिथ्म को स्पंदन में एकीकृत करना चाहता हूं। मेरे पास बहुत सारे इमेज प्रोसेसिंग एल्गोरिदम हैं। मुझे देशी कोड के लिए बाध्यकारी जनरेटर की आवश्यकता है। नहीं तो मैं अपने सभी डार्ट-फड़फड़ाहट के अनुभवों को भूल जाऊंगा और मैं ज़ामरीन या कुछ ऐसा सीखना शुरू कर दूंगा जो मुझे सूट करे।

क्या हम प्रगति को गति दे सकते हैं?

डार्ट और सी के बीच इंटरऑपरेट करना इतना बड़ा दर्द है।

प्रक्रिया को तेज करने से अच्छी गुणवत्ता वाले उत्पाद के परिणाम की संभावना नहीं है। यह तैयार होने पर तैयार हो जाएगा। :-)

प्रक्रिया को तेज करने से अच्छी गुणवत्ता वाले उत्पाद के परिणाम की संभावना नहीं है। यह तैयार होने पर तैयार हो जाएगा। :-)

खैर, मैंने जो कहने की कोशिश की वह यह था कि हम प्राथमिकता बढ़ाना चाहते हैं ताकि हम इसे हल करने के लिए और अधिक संसाधन और प्रयास कर सकें। आप जानते हैं कि "लक्ष्य" को लक्षित करने के लिए अभी तक 1386 खुले मुद्दे हैं जो "आने वाले वर्षों में फिक्सिंग" होंगे।

थ्रेड को एक बार फिर से पढ़ने के बाद, मैंने देखा कि @eseidelGoogle ने कहा कि

"लक्ष्य" गलत बकेट हो सकता है। :) @mraleph के पास https://github.com/dart-lang/sdk/issues/34452 की खोज करने वाला कोई है। यह कम से कम समाधान का एक हिस्सा है।

यहां एफएफआई के लिए विजन डॉक है जिसे हम वर्तमान में डार्ट पक्ष पर प्रोटोटाइप कर रहे हैं।

कृपया एक नज़र डालें और हमें बताएं कि आप क्या सोचते हैं।

मैं एफएफआई भाग के बारे में ज्यादा कुछ नहीं कह सकता क्योंकि मैंने कभी ऐसा कुछ इस्तेमाल नहीं किया,
लेकिन मैं सोच रहा हूं कि पब एकीकरण कैसा दिखेगा।

एफएफआई का उपयोग करने वाले प्रकाशन पैकेजों को कैसे नियंत्रित किया जाएगा?
एफएफआई का उपयोग करने वाले उपभोग पैकेजों को कैसे संभाला जाएगा?

@zoechi हमने अभी तक pub एकीकरण पर चर्चा नहीं की है।

वे आज फ़्लटर प्लगइन्स के समान काम करने में सक्षम होना चाहिए - प्लेटफ़ॉर्म/आर्किटेक्चर उपयुक्त स्रोत और/या बाइनरी शामिल करें जिन्हें उपभोग करने वाले एप्लिकेशन में संकलित/लिंक किया जा सकता है।

पब के नजरिए से, यह कोई बड़ी बात नहीं होनी चाहिए - सिवाय इसके कि पैकेज में बड़ी बाइनरी फाइलें शामिल हो सकती हैं।

हालांकि कुछ काम करने की जरूरत है, हालांकि चीजों के स्पंदन टूलिंग अंत के आसपास उन्हें फ़्लटर परियोजनाओं में एकीकृत करने के लिए - वे वास्तव में एंड्रॉइड/आईओएस प्लगइन्स के समान काम नहीं करेंगे।

क्या इस मुद्दे को और अधिक केंद्रित रखने के लिए पब-एकीकरण को डार्ट-लैंग/पब मुद्दे पर ले जाया जाना चाहिए?

मैंने 'विज़न डॉक' पढ़ा है और मैं कोहरे के माध्यम से आकृतियों को देखता हूँ।

इस बीच मैं कुछ और ही सोच रहा था।

नेटिवचैनल की तरह कुछ बनाने के लिए

संदेश भेजने का तरीका भी वर्तमान स्ट्रीम आधारित आर्किटेक्चर (ब्लॉक, आरएक्स) के अनुरूप है। यह स्मृति प्रबंधन के बारे में किसी भी चिंता से भी बचता है, क्योंकि संकलक उपयुक्त रिंग बफ़र्स उत्पन्न कर सकता है जहाँ उपयुक्त हो या सरल 'कैली फ़्रीज़' मान लें जहाँ एक कैली को अधिक समय तक डेटा रखने की आवश्यकता होती है।

लेकिन ईमानदारी से कहूं तो मैं एफएफआई के किसी भी रूप की सराहना करूंगा अगर इसे फ़्लटर (फ्यूशिया) पारिस्थितिकी तंत्र में मूल रूप से एकीकृत किया जाएगा और मुझे डार्ट ऐप के भीतर से सीपीयू अनुकूलित देशी कोड का उपयोग करने दें।

@ohir आपने जो कल्पना की थी वह बग प्रस्तुत कुछ समस्याओं के लिए एक और समाधान होगा। यह बग C++ से संबंधित किसी भी चीज़ के लिए एक सामान्य प्रयोजन कैच-ऑल के रूप में विकसित हुआ। :/ मुझे संदेह है (जैसा कि मैंने पिछली टिप्पणियों में उल्लेख किया है) हमें इस बग को छोटे में तोड़ने की जरूरत है। इस क्षेत्र में हमारे द्वारा निर्मित एकमात्र समाधान FFI कार्य नहीं हो सकता है।

@seidelGoogle इस पर कोई प्रगति कर रहा है? अभी हमारे पास भारी वीडियो प्रोसेसिंग कार्यों को लागू करने के लिए एक परियोजना की आवश्यकता है जो कि ffmpeg के माध्यम से किया जा सकता है, क्योंकि वर्तमान डार्ट पैकेज एक व्यवहार्य समाधान प्रदान नहीं कर सकता है, हम बेसब्री से ffmpeg लिब को सीधे कॉल करने के लिए स्पंदन की प्रतीक्षा कर रहे हैं।

उन पेज-टू-पेज यूआई आधारित ऐप्स के लिए, अब स्पंदन मुझे लगता है कि एंड्रॉइड और आईओएस दोनों पर डबल कोडिंग काम करने की तुलना में वास्तव में एक अच्छा विकल्प है, अगर हम 5 साल पहले इतने प्यारे उपकरण के साथ थे, तो पूरे ऐप उद्योग को हो सकता है बदला गया। हालांकि, अभी स्पंदन के फायदे यह नहीं है कि कंपनियों के लिए यह लुभावनी है क्योंकि वे पहले से ही पुराने तरीके से काफी अच्छा कर चुके हैं, लेकिन कुछ गैर-यूआई कार्यों के लिए डार्ट शीर्ष आवश्यकता से पीछे है।

इसका मतलब यह नहीं है कि डार्ट एक दिन उन कार्यों के लिए अच्छा या व्यवहार्य नहीं है, लेकिन एक सामान्य आईटी कंपनी की दृष्टि में जिसे स्पंदन इको-सिस्टम में शामिल किया जा सकता है, उन्हें क्रॉस- प्लेटफ़ॉर्म कोडिंग विधि केवल तभी प्राप्त की जा सकती है जब क्लाइंट-साइड डेटा प्रोसेसिंग, वीडियो/ऑडियो, एआर स्टाफ इत्यादि जैसे सबसे शीर्ष शानदार सुविधाएं हासिल की जा सकती हैं, जब तक कि कुछ एल्गोरिदम वे पहले से ही सी/सी ++ के माध्यम से कर चुके हों। डार्ट लैंग का उपयोग करके इसे फिर से लागू करना या फिर से आविष्कार करना उनके लिए वास्तव में कठिन है।

और मुख्य समाधान स्पंदन के लिए सी ++ के साथ संवाद करने के लिए प्रत्यक्ष और कुशल तरीका पेश कर रहा है, मुझे भी लगता है कि यह "क्रॉस-प्लेटफ़ॉर्म" चीज़ की पहली प्राथमिकता है, यूआई कर्मचारियों के लिए डार्ट सही है, कुछ सामान्य डेटा तर्क भी हो सकते हैं डार्ट में किया गया है, लेकिन स्पंदन के लिए एक पवित्र नए के पुनर्निर्माण के बजाय लंबे लेकिन अभी भी सक्रिय और कुशल सी ++ इको-सिस्टम में विलय करना बेहतर है!

एक वास्तविक "क्रॉस-प्लेटफ़ॉर्म" कोडिंग अनुभव का सपना हुड के पीछे सी ++ के साथ डार्ट यूआई स्टाफ है, कोई जावा कोड नहीं, कोई ओसी कोड नहीं है। वहाहा, मैं इसे होते हुए देखने के लिए इंतजार नहीं कर सकता!

@smellbee क्या आप ffmpeg कमांड लाइन का उपयोग नहीं कर सकते?

@smellbee मैं करतब मैं इसका उत्तर देने के लिए सही नहीं हूं। @seidelGoogle इस पर कोई खबर?

@smellbee क्या आप ffmpeg कमांड लाइन का उपयोग नहीं कर सकते?

यह एक क्लाइंट साइड वर्क है, ffmpeg लिब का उपयोग करके वीडियो फ्रेम रेंडर करने के लिए इंस्टेंट फीड बैक स्ट्रीम का उत्पादन करता है, क्या कमांड लाइन का उपयोग करना संभव है?

@smellbee मैं करतब मैं इसका उत्तर देने के लिए सही नहीं हूं। @seidelGoogle इस पर कोई खबर?

इसके लिए खेद है, मैंने "es" टाइप किया, और यह स्वतः पूर्ण हो गया, मैंने इसे नोटिस नहीं किया... आशा है @eseidelGoogle इसे देख सकता है

डार्ट पक्ष पर कार्य प्रगति पर है - हम 2019 की पहली तिमाही के लिए कुछ तैयार होने की आशा करते हैं।

यह एक बड़ी विशेषता है और हम इसे ठीक करना चाहते हैं: चूंकि हम इसे डार्ट के लिए विभिन्न निष्पादन मोड में बढ़िया काम करना चाहते हैं, इसलिए विवरण तैयार करते समय कृपया हमारे साथ रहें।

आप डार्ट-लैंग/एसडीके#34452 का अनुसरण कर सकते हैं जो डार्ट साइड पर काम को ट्रैक करता है।

डार्ट एफएफआई डार्ट से सी कार्यों को कॉल करने की अनुमति देगा।
लेकिन सी ++ सुविधाओं के बारे में क्या - कक्षाएं, एसटीडी कंटेनर, स्मार्ट पॉइंटर्स, अपवाद?
क्या हम न्यूनतम बॉयलरप्लेट के साथ डार्ट को सी ++ कक्षाओं को निर्यात करने की संभावना की उम्मीद कर सकते हैं?

एक और महत्वपूर्ण विशेषता एसिंक्रोनस समर्थन है - सी ++ कोड को एक अलग थ्रेड पर चलाने की क्षमता और विधियों से फ्यूचर/स्ट्रीम वापस करने की क्षमता।

@ टी-आर्टिकोव सीधे सी ++ इंटरऑपरेबिलिटी का समर्थन करने की कोई मौजूदा योजना नहीं है। यह बहुत जटिल है. केवल एक चीज जो एर्गोनोमिक रूप से सी ++ के साथ इंटरऑप कर सकती है वह सी ++ है।

यदि आप सी ++ के साथ उच्च स्तरीय इंटरऑप में रूचि रखते हैं तो आपको अपनी खुद की इंटरऑप परत बनाने की आवश्यकता होगी जो आपके सी ++ एपीआई को सी जैसे एपीआई के माध्यम से उजागर करे।

एक और महत्वपूर्ण विशेषता एसिंक्रोनस समर्थन है - सी ++ कोड को एक अलग थ्रेड पर चलाने की क्षमता और विधियों से फ्यूचर/स्ट्रीम वापस करने की क्षमता।

मुझे लगता है कि इसे एक पैकेज के रूप में बनाया जा सकता है। हमें बस यह सुनिश्चित करना चाहिए कि हम सही आदिम प्रदान करें ताकि इसे बनाया जा सके।

डार्ट एफएफआई डार्ट से सी कार्यों को कॉल करने की अनुमति देगा।
लेकिन सी ++ सुविधाओं के बारे में क्या - कक्षाएं, एसटीडी कंटेनर, स्मार्ट पॉइंटर्स, अपवाद?
क्या हम न्यूनतम बॉयलरप्लेट के साथ डार्ट को सी ++ कक्षाओं को निर्यात करने की संभावना की उम्मीद कर सकते हैं?

जब तक सी ++ के लिए डार्ट को कॉल करने का कोई तरीका है, मुझे लगता है कि वे चीजें संभव हैं， सी ++ इस बात का ख्याल रखता है कि सी ++ किस बारे में चिंतित है， और डार्ट के साथ संचार या कॉल करके संचार करता है, किसी भी निम्न-स्तरीय हेरफेर को बेनकाब करने की आवश्यकता नहीं है डार्ट जो डार्ट के उपयोग की आसानी को नष्ट कर देगा।

एक और महत्वपूर्ण विशेषता एसिंक्रोनस समर्थन है - सी ++ कोड को एक अलग थ्रेड पर चलाने की क्षमता और विधियों से फ्यूचर/स्ट्रीम वापस करने की क्षमता।

और डार्ट में पहले से ही इसकी एसिंक्रोनस तंत्र है， इसलिए चाहे कोई थ्रेड सी ++ उन्मुख है या नहीं, इससे कोई फर्क नहीं पड़ता है, जब तक कि सी ++ भाग जब भी आवश्यक हो, डार्ट को कॉल कर सकता है, और एक "आइसोलेट" काम कर सकता है।

मुझे यही लगता है @mraleph , अगर मैं गलत हूं तो मुझे

@mraleph
वास्तव में, अन्य भाषाओं के साथ महान C++ इंटरऑप के उदाहरण हैं।
https://github.com/boostorg/python
https://github.com/ThePhD/sol2
https://github.com/dropbox/djinni
मुझे उम्मीद है कि डार्ट/स्पंदन बॉक्स से बाहर एक समान तंत्र प्रदान करेगा।

यदि आप सी ++ के साथ उच्च स्तरीय इंटरऑप में रूचि रखते हैं तो आपको अपनी खुद की इंटरऑप परत बनाने की आवश्यकता होगी जो आपके सी ++ एपीआई को सी जैसे एपीआई के माध्यम से उजागर करे।

यह स्पष्ट करने के लिए कि यह दृष्टिकोण कैसे लागू होता है, क्या आप उदाहरण के रूप में निम्नलिखित С++ कक्षाओं का उपयोग करके इसे प्रदर्शित कर सकते हैं:

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

ताकि इसे Dart . से इस्तेमाल किया जा सके

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

@ टी-आर्टिकोव दोनों boostorg::python और sol2 वास्तव में मेरी बात को बहुत अच्छी तरह से चित्रित करते हैं। ध्यान दें कि यह अन्य भाषाओं के साथ इंटरऑपरेट करने के लिए सी ++ पुस्तकालय है, दूसरी तरफ नहीं। डार्ट एफएफआई सी एपीआई को कॉल करने का डार्ट केंद्रित तरीका है, डार्ट को कॉल करने का सी ++ केंद्रित तरीका नहीं है।

यह स्पष्ट करने के लिए कि यह दृष्टिकोण कैसे लागू होता है, क्या आप उदाहरण के रूप में निम्नलिखित С++ कक्षाओं का उपयोग करके इसे प्रदर्शित कर सकते हैं:

आपको कुछ इस तरह लिखना होगा (या किसी टूल द्वारा जेनरेट करना होगा)।

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

ध्यान दें कि यह अन्य भाषाओं के साथ इंटरऑपरेट करने के लिए सी ++ पुस्तकालय है, दूसरी तरफ नहीं।

आप गलत हैं, वे सी ++ कक्षाओं को अन्य भाषाओं में बेनकाब करने की अनुमति देते हैं।
https://www.boost.org/doc/libs/1_68_0/libs/python/doc/html/tutorial/tutorial/expose.html

आपके डार्ट एफएफआई उदाहरण के लिए धन्यवाद।
कुछ खामियां हैं: सी ++ अपवाद डार्ट पक्ष को पारित किया जाना चाहिए; और MyObject.data इस तरह से काम नहीं करेगा (इसे केवल पॉइंटर मिलता है, लेकिन डेटा का आकार नहीं)।
लेकिन विचार स्पष्ट है।

मेरी राय में, ऐसा कोड मैन्युअल रूप से लिखने के लिए बहुत अधिक क्रियात्मक है।
मैं यह देखने के लिए उत्सुक हूं कि क्या यह प्रक्रिया नए डार्ट एफएफआई स्पंदन इंजन बाइंडिंग के लिए स्वचालित होगी।

C++ इंटरऑपरेबिलिटी के लिए रन-टाइम बाइंडिंग लगभग असंभव है (आप जेनरिक, मल्टीपल इनहेरिटेंस, ऑपरेटर ओवरलोड, मैंगल्ड नेम आदि से कैसे निपटते हैं ...) कई कठिन प्रयास किए गए थे (BridJ, CppSharp, आदि), और मेरी समझ से लोग C इंटरऑप को सबसे व्यवहार्य विकल्प के रूप में पाते हैं।

आधिकारिक इंटरऑपरेबिलिटी डेवलपर लोग सी ++ के लिए प्राप्त कर सकते हैं कि बहुत ही सामान्य समाधान की संभावना नहीं है। कोटलिन/मूल यह पेशकश नहीं करता है। स्कैला-देशी iether. .NET या तो (माइक्रोसॉफ्ट सी ++ इंटरऑप हमेशा अजीब या स्थिर होता है)। जेएनआई केवल सी ++ इंटरऑप का समर्थन करता है जहां स्थिर संकलन शामिल होता है। पाइथन बूस्ट ग्लू जैसा कुछ मैन्युअल रूप से लिखा जाना चाहिए। कोई भी तृतीय पक्ष समूह JNAerator जैसी चीजें विकसित कर सकता है (यानी आप इसे कर सकते हैं, डार्ट/स्पंदन टीमों को इसे प्राप्त करने की अपेक्षा करने की कोई आवश्यकता नहीं है)।

बिना किसी वास्तविक उत्तर के इस बातचीत के बाद मुझे लगता है कि मैं क्यूटी से चिपके रहूंगा जो क्रॉस-प्लेटफॉर्म है और इसमें पूर्ण सी ++ समर्थन है। मैं बस अपने अगले प्रोजेक्ट के लिए फ़्लटर को आज़माने के बारे में सोच रहा था, लेकिन अब मैं नहीं करूँगा, बहुत बहुत धन्यवाद!

स्पंदन C++ में लिखा होता तो बेहतर होता, जिससे किसी अन्य भाषा के साथ इंटरऑप आसानी से संभव हो पाता। क्या सी ++ में स्पंदन को फिर से लिखने का कोई प्रयास है?

मुझे लगता है कि चर्चा अब अनावश्यक रूप से खिंची जा रही है।

हम जानते हैं कि स्पंदन के विकास रोडमैप पर क्या है (या नहीं)।
तदनुसार, हम विशिष्ट उपयोग के मामलों के लिए इसका उपयोग (या उपयोग नहीं) करने का निर्णय ले सकते हैं।

मैं विकास के एजेंडे को बदलने की कोशिश में कोई उपयोगिता नहीं देखता, या
इस बिंदु से परे विशिष्ट वास्तुशिल्प कार्यान्वयन की मांग करना।

धन्यवाद,
गौरव

सोम 25 फरवरी, 2019, रात 10:51 बजे भौज, नोटिफिकेशन @github.com ने लिखा:

यह बेहतर हो सकता था अगर स्पंदन C++ में लिखा होता, with
जो किसी भी अन्य भाषा के साथ आसानी से जुड़ सकता था। है
सी ++ में स्पंदन को फिर से लिखने का कोई प्रयास?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/flutter/flutter/issues/7053#issuecomment-467098455 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AZ86acDpZgNeyezx40uxe_c5E2xZHWxaks5vRBumgaJpZM4K-PLw
.

वास्तव में स्पंदन जैसा कि मुझे पता है कि सी ++ में लिखा गया है, लेकिन स्पंदन में प्रोग्रामिंग के लिए केवल दुभाषिया भाषा डार्ट के साथ किया जा सकता है जो एक वीएम में चलता है। लेकिन आपके पास अभी तक डार्ट से सी++ स्पंदन के भाग में जाने का कोई मौका नहीं है...

तो जो कोई भी इसे पढ़ता है और अच्छे क्रॉस-प्लेटफ़ॉर्म डेवलपमेंट के एपडेवलपमेंट में सामान्य उपयोग का मामला है, फ़्लटर सी ++ के प्रत्यक्ष उपयोग की अनुमति नहीं देगा यदि आपको इसकी आवश्यकता है तो क्यूटी सी ++ जैसे अन्य क्रॉस-प्लेटफ़ॉर्म फ्रेमवर्क का उपयोग करें।

मेरे लिए C++ क्रॉस-प्लेटफ़ॉर्म-डेवलपमेंट के लिए आवश्यक है क्योंकि यह लगभग हर तकनीक में सबसे कम आम भाजक है।

@aqmappdesigners

दुभाषिया भाषा डार्ट जो एक VM में चलता है

यह सटीक नहीं है।

स्पंदन डिबग मोड में डार्ट वीएम का उपयोग करता है, जो हॉट-रीलोड को भी संभव बनाता है।
रिलीज बिल्ड में डार्ट को सी ++ जैसे बाइनरी कोड में संकलित किया गया है।

@zoechi धन्यवाद, मुझे यह नहीं पता था। यह प्रदर्शन के लिए अच्छा लगता है

यह प्रदर्शन के लिए अच्छा लगता है

और सेब ऐप स्टोर के लिए एक आवश्यकता है।

dart:ffi प्रोटोटाइप उस बिंदु तक आगे बढ़ गया है जहां हम एपीआई निर्णयों पर निर्णय ले रहे हैं। (कुछ डिजाइन निर्णयों पर यहां चर्चा की गई

सूचित डिज़ाइन निर्णय लेने के लिए, हम इस बारे में और उदाहरण चाहते हैं कि आप किन C API को बाध्य करना चाहते हैं। अब तक इस मुद्दे में SQLite, Realm, OpenCV, SuperPowered, और ffmpeg का उल्लेख है। कोई अन्य एपीआई जिस पर हमें विचार करना चाहिए?

@dcharkes मुझे नहीं पता कि यह मदद करता है, लेकिन एंड्रॉइड में टेलीग्राम
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/TgNetWrapper.cpp
यह ffmpeg के साथ जीआईएफ प्लेबैक को भी संभालता है, सीधे एंड्रॉइड बिटमैप्स पर लिखता है:
https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/jni/gifvideo.cpp

पंजीकरण फॉर्म के लिए libphonenumber और libpostal के माध्यम से फोन और पते को पार्स करने का एक तरीका दिलचस्प हो सकता है। इसके अलावा glfw + स्पंदन-एम्बेडर और शायद एक दिन हम पूरी तरह से डार्ट में लिखा हुआ एक डेस्कटॉप ऐप देखेंगे।

SQLite और दायरे के लिए +1। कृपया कॉचबेस को भी देखें, उनके पास सी एसडीके के साथ एक सामान्य सी ++ कोर है।

क्या फायरबेस सी ++ एपीआई दिलचस्प होगा? https://firebase.google.com/docs/reference/cpp/

इस पर ज्यादा ध्यान नहीं दिया गया, लेकिन यह सोच रहा था कि आईओएस और एंड्रॉइड प्लगइन्स को एक ही प्लगइन के साथ बदलने में सक्षम हो सकता है जो सीधे सी ++ से बात करता है।

कुछ क्रिप्टो पुस्तकालयों को जंग से अंगूठी जैसा कुछ प्यार मिलना चाहिए - https://github.com/briansmith/ring

OpenCV, दायरे, SqlCipher के लिए +1 (https://github.com/sqlcipher/sqlcipher)

क्रिप्टोग्राफी पुस्तकालय। विशेष रूप से लिबसोडियम या टिंक।

https://github.com/google/tink

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

पहले से ही एक स्पंदन-सोडियम पुस्तकालय है, यह प्लेटफॉर्म चैनलों के माध्यम से प्रत्येक प्लेटफॉर्म पर लिब्सोडियम रैपर से बात करता है, फिर देशी के लिए।

कस्टम मैपिंग लाइब्रेरी जैसे कि मैपबॉक्स-ग्ल https://github.com/mapbox/mapbox-gl-native

https://github.com/deltachat/deltachat-core के माध्यम से फ़्लटर के लिए एसएमटीपी/आईएमएपी हैंडलिंग (चैट-ओवर-ईमेल के लिए) कुछ ऐसा है जिसे मैं सीधे उपयोग करना पसंद करूंगा।

यदि मैं इतना बोल्ड हो सकता हूं कि पैराफ्रेश के रूप में, सामान्य उपयोग के मामले नीचे दिए गए हैं:

1. कम विलंबता ऑडियो/वीडियो हार्डवेयर एक्सेस (जैसे, सुपरपावर)
2. हार्डवेयर असिस्टेड a/v प्रोसेसिंग (जैसे, ffmpeg)
3. एक्सएमपीपी/अन्य नेटवर्क उन्मुख प्रोटोकॉल के लिए टीसीपी आधारित सॉकेट एक्सेस
   (चैट के लिए, पुश नोटिफिकेशन)
4. प्रोसेस लेवल अपग्रेड (रूट एक्सेस) / स्पॉनिंग थ्रेड्स
   क्रॉस-प्लेटफ़ॉर्म संगत तरीके (सिस्टम ऐप्स, मल्टीटास्किंग, एमुलेटर के लिए)

अधिक उपयोग के मामले हो सकते हैं, लेकिन ये प्राथमिक हैं जो मेरे पास आते हैं
मन।

उदाहरण प्रदान करने के लिए आप सभी का धन्यवाद! यह बहुत मददगार है।

@ कौशल-अप ध्यान दें कि हम अमूर्त वर्गीकरण के बजाय ठोस उदाहरणों में अधिक रुचि रखते हैं। ऐसा इसलिए है क्योंकि हम ठोस उदाहरणों पर एफएफआई के एर्गोनॉमिक्स का आकलन करना चाहते हैं।

अजीब तरह से, भाषाओं में से एक जो सी ++ से/से सबसे अच्छा इंटरफ़ेस प्रदान करता है, रस्ट है, इसके शक्तिशाली मैक्रो + बिल्ड सिस्टम के माध्यम से, ओओ के लिए पूरी तरह से अलग दृष्टिकोण होने के बावजूद।

मैं ओपनएसएसएल कहूंगा, क्योंकि हमें क्लाइंट प्रमाणपत्रों का उपयोग करके साबुन अनुरोधों और एक्सएमएल फाइलों (एक्सएमएलडीएसआईजी, एक्सडेस एल) पर डिजिटल हस्ताक्षर करने की आवश्यकता है।
डार्ट में ही बोरिंगएसएसएल है, लेकिन इसका केवल एक हिस्सा डार्ट के संपर्क में है। तो अगली सबसे अच्छी बात स्पंदन से देशी ओपनस्ल लिब को कॉल कर रही है

आशा है कि मैं स्पैमिंग नहीं कर रहा हूं, लेकिन मैं टेन्सरफ्लो लाइट के साथ बेहतर एकीकरण करना चाहता हूं, जेएनआई के माध्यम से नहीं जा रहा हूं, यह वीडियो संचालन के लिए बहुत अच्छा होगा

इस पर ज्यादा ध्यान नहीं दिया, लेकिन सोच रहा था कि आईओएस और एंड्रॉइड प्लगइन्स> को एक ही प्लगइन के साथ बदलने में सक्षम हो सकता है जो सीधे सी ++ से बात करता है।

सी ++ का समर्थन करने के अलावा, यह बहुत अच्छा होगा यदि कोई प्लगइन है जो सीधे गो से बात कर सकता है। अभी हम गो मोबाइल और स्पंदन प्लेटफॉर्म चैनलों के माध्यम से बात कर रहे हैं जो यूआई प्रतिक्रिया को धीमा कर देता है। फ़्लटर में गो और सी ++ का मूल समर्थन होने से हमें कई प्लेटफार्मों के लिए समान कोड-बेस (बिजनेस-लॉजिक/एल्गोरिदम) बनाए रखने में भी मदद मिलेगी।

मूल पुस्तकालय पहुंच के लिए +1।

मैं एंड्रॉइड/आईओएस के लिए प्लेटफार्म चैनल बनाने और दो प्लगइन्स बनाए रखने के बिना वल्कन/मोल्टेनवीके तक पहुंचना चाहता हूं (जो भी बड़ा होगा)। यह केवल डार्ट में विकसित होने के दौरान, 3 डी अनुप्रयोगों के निर्माण और बनावट विजेट में प्रस्तुत करने की अनुमति देगा। प्लेटफ़ॉर्म चैनल बस एक हैकी वर्कअराउंड की तरह लगते हैं। मैं इसके बजाय प्रत्येक प्लेटफॉर्म के लिए एक रैपर लिखने के बिना देशी पुस्तकालयों तक पहुंच बनाना चाहता हूं और जब भी उस पुस्तकालय के लिए कोई नया संस्करण होता है तो उन्हें बनाए रखना चाहता हूं।
मुझे लगता है कि यह सुविधा बहुत अधिक डेवलपर्स को आकर्षित करेगी।

हाँ, कृपया स्पंदन से सीधे देशी पुस्तकालय का उपयोग करें।
मैं स्पंदन पर कुछ सी ++ पुस्तकालय का उपयोग करना चाहता हूँ।

हाँ, कृपया स्पंदन से सीधे देशी पुस्तकालय का उपयोग करें।
मैं स्पंदन पर कुछ सी ++ पुस्तकालय का उपयोग करना चाहता हूँ।

अब हम उस बिंदु पर हैं जहां हम कुछ प्रतिक्रिया प्राप्त करने के लिए एक प्रारंभिक पूर्वावलोकन की पेशकश करना चाहते हैं।

विवरण के लिए, कृपया डार्ट ट्रैकिंग बग में अपडेट देखें।

@ mit-mit क्या यह इस मुद्दे में मदद करेगा: क्या मैं स्पंदन के साथ अजगर पुस्तकालय को कॉल या उपयोग कर सकता हूं ?

पार्टी के लिए देर हो चुकी है, लेकिन SQLCipher @dcharkes @mraleph . के लिए +1

@ doc-rj अब हम उस अवस्था में हैं जहाँ आपको SQLCipher को बाध्य करने के साथ प्रयोग करने और अपने अनुभव पर हमें प्रतिक्रिया देने में सक्षम होना चाहिए। यह टिप्पणी देखें।

मैं इस बात पर जोर देना चाहता हूं कि हम वास्तव में कोई विशिष्ट पुस्तकालय बाइंडिंग स्वयं प्रदान करने का लक्ष्य नहीं बना रहे हैं - क्योंकि अनुरोध बेहद विविध हैं, लेकिन हमारा लक्ष्य हर किसी के लिए और किसी को भी सी एपीआई के साथ किसी भी पुस्तकालय से जुड़ना संभव बनाना है।

मुझे लगता है कि अब इसकी आवश्यकता बढ़ गई है कि मल्टी-प्लेटफॉर्म की घोषणा की गई है।

क्या यह किसी रोडमैप का हिस्सा है?

@felemedeiros काम प्रगति पर है - यदि आपके पास एक पुस्तकालय है जिसे आप एफएफआई का उपयोग करने के लिए बाध्य करना चाहते हैं, तो मैं दृढ़ता से सुझाव देता हूं कि हमें प्रतिक्रिया प्रदान करने के लिए बाइंडिंग पर काम करना शुरू करें। जानकारी के लिए यह टिप्पणी देखें।

इस पर ज्यादा ध्यान नहीं दिया, लेकिन सोच रहा था कि आईओएस और एंड्रॉइड प्लगइन्स> को एक ही प्लगइन के साथ बदलने में सक्षम हो सकता है जो सीधे सी ++ से बात करता है।

सी ++ का समर्थन करने के अलावा, यह बहुत अच्छा होगा यदि कोई प्लगइन है जो सीधे गो से बात कर सकता है। अभी हम गो मोबाइल और स्पंदन प्लेटफॉर्म चैनलों के माध्यम से बात कर रहे हैं जो यूआई प्रतिक्रिया को धीमा कर देता है। फ़्लटर में गो और सी ++ का मूल समर्थन होने से हमें कई प्लेटफार्मों के लिए समान कोड-बेस (बिजनेस-लॉजिक/एल्गोरिदम) बनाए रखने में भी मदद मिलेगी।

मैंने एक लेख लिखा था कि कैसे हम वर्तमान में फ़्लटर से गो लाइब्रेरी एपीआई को कॉल कर रहे हैं। यह रुचि रखने वाले किसी व्यक्ति के लिए उपयोगी हो सकता है। https://medium.com/@archan.paul/using -go-library-in-flutter-a04e3496aa05

मैं स्पंदन ऐप पर c++ कोड कैसे जोड़ सकता हूं?

मैं स्पंदन ऐप पर c++ कोड कैसे जोड़ सकता हूं?

मुझे लगता है कि अभी केवल विकल्प C++ -> JNI (एंड्रॉइड के लिए) -> PlatformChannel तरीका है जब तक कि हमारे पास ऐसा करने के लिए और अधिक शानदार तरीका न हो !!

मैंने ईज़ोरेड (http://ezored.com) नामक एक प्रोजेक्ट बनाया। अच्छा होगा अगर मैं जटिल वस्तुओं को स्पंदन में पास कर सकता हूं, बिना किसी अन्य चीज में कनवर्ट करने की आवश्यकता है, क्योंकि यह पहले से ही जावा और ओबीजेसी में है। देशी और डार्ट के बीच स्पंदन एकीकरण का परीक्षण करने के लिए कोई भी एसडीके (या प्रीबिल्ट डाउनलोड) उत्पन्न करने के लिए ईज़ोर्ड का उपयोग कर सकता है। इसमें डेटाबेस का उपयोग करके अनुरोध, पार्सिंग, क्रूड और डेमो एसडीके में बहुत सी चीजें पहले से ही लागू हैं।

मैं स्पंदन समूहों में खोज करता हूं लेकिन वस्तुओं और वस्तुओं की सूची को स्पंदन प्रत्यक्ष करने के लिए पास करने का कोई तरीका नहीं है।

किसी भी मदद में धन्यवाद।

कोई नई प्रगति? ऐसा लगता है कि 2.5 साल से अधिक समय बीत चुका है ...

@fzyzcjy हम इस पर काम कर रहे हैं। हमने एक प्रारंभिक पूर्वावलोकन जारी किया है। शामिल होने के तरीके के बारे में https://github.com/dart-lang/sdk/issues/34452#issuecomment -482136759 देखें।

इस प्रारंभिक पूर्वावलोकन के बाद से हमने इंटेल 32, आर्म 64 और आर्म 32 के लिए समर्थन जोड़ा है। ये प्लेटफॉर्म अभी तक स्थिर या देव पर जारी नहीं किए गए हैं, ये केवल डार्ट एसडीके की मास्टर शाखा पर उपलब्ध हैं। यहां प्रगति पर नजर रखी जा रही है ।

@dcharkes यह सुनकर बहुत खुशी हुई! आपके शानदार काम के लिए शुक्रिया!

कोइ प्रगति?

स्थिति अद्यतन और अतिरिक्त जानकारी के लिए, कृपया https://github.com/dart-lang/sdk/issues/34452 देखें। सबसे ऊपर की टिप्पणी में सबसे हालिया अपडेट है।

वेब ऐप बनाने के लिए स्पंदन का उपयोग करते समय, क्या एसी लाइब्रेरी के साथ एफएफआई का उपयोग करना संभव होगा?

वेब ऐप बनाने के लिए स्पंदन का उपयोग करते समय, क्या एसी लाइब्रेरी के साथ एफएफआई का उपयोग करना संभव होगा?

इसकी संभावना नहीं है। सैद्धांतिक रूप से लंबे समय तक इसे WebAssembly का उपयोग करके समर्थित किया जा सकता है, लेकिन यह ऐसा कुछ नहीं है जिस पर हम वर्तमान में काम कर रहे हैं।

@ साथ-साथ वास्तव में？

वेब ऐप बनाने के लिए स्पंदन का उपयोग करते समय, क्या एसी लाइब्रेरी के साथ एफएफआई का उपयोग करना संभव होगा?

इसकी संभावना नहीं है। सैद्धांतिक रूप से लंबे समय तक इसे WebAssembly का उपयोग करके समर्थित किया जा सकता है, लेकिन यह ऐसा कुछ नहीं है जिस पर हम वर्तमान में काम कर रहे हैं।

इसे WebAssembly की आवश्यकता क्यों होगी? अगर आप भविष्य में लोगों से WebAssembly को फिर से बनाने के लिए कह सकते हैं, तो आप उन्हें अभी ASM.js में फिर से बनाने के लिए कह सकते हैं।

@ nic-hartley यह अच्छा विचार है, लेकिन चुनौती यह नहीं है कि मूल कोड को कैसे संकलित किया जाए, यह डार्ट (JS के रूप में संकलित) और मूल कोड के बीच सेतु बनाने में है, चाहे वह किसी भी रूप में हो।

मूल FFI प्रदर्शन कारणों से बहुत निम्न-स्तर का है और इसे आसानी से asm.js या WebAssembly में अनुवादित नहीं किया जा सकता है।

स्पष्ट करने के लिए, मेरा मतलब है कि हमारा कार्यान्वयन बहुत निम्न स्तर का है - यह निश्चित रूप से एक दिलचस्प विशेषता है, लेकिन इसे वितरित करने के लिए काफी काम करना होगा।

स्पंदन केवल एक खिलौना है जब तक कि यह c++ का समर्थन नहीं करता है

मैं यहां दूसरों द्वारा समान बिंदुओं को प्रतिध्वनित करने के लिए आया हूं, जब तक कि फ़्लटर आसानी से C ++ (बिना ब्रिज लाइब्रेरी, और कोई प्रदर्शन दंड के साथ) के साथ इंटरऑप नहीं कर सकता है, इसे मौजूदा देशी पुस्तकालयों, या अनुप्रयोगों में निवेश के साथ बड़े पैमाने पर अनुप्रयोगों द्वारा कभी नहीं अपनाया जाएगा। जहां प्रदर्शन सर्वोच्च प्राथमिकता है।

मैं ध्यान दूंगा कि रिएक्ट नेटिव भी वर्तमान में एक पुल का उपयोग करता है, इसलिए ऐसा प्रतीत होता है कि एफएफआई को लागू करने की कोशिश के मामले में स्पंदन वास्तव में आगे की ओर है।

आईओएस पर ऐपकिट के साथ सी ++ के साथ एकीकरण छोटा है। हमें इसी से तुलना करनी चाहिए, न कि रिएक्ट नेटिव से।

यूडब्ल्यूपी और सी ++ भी छोटा है।

मैं सामान्य रूप से "डार्ट एफएफआई प्रयास का समर्थन" पार्टी के लिए भी हूं, हालांकि ...

Xamarin UWP की तुलना में अधिक उपयुक्त तुलना हो सकती है, लेकिन Xamarin के क्रॉस प्लेटफ़ॉर्म दृश्य फ़्लटर के रूप में लगभग अनुकूलन योग्य नहीं थे और अक्सर सभ्य दिखने के लिए बहुत सारे देशी कोड की आवश्यकता होती थी।

यह सच नहीं है। Flutter के विपरीत, Xamarin के पास मूल API (यानी Xamarin.iOS और Xamarin.Android) के लिए प्लेटफ़ॉर्म बाइंडिंग है, और ऐप डेवलपर्स के लिए अपनी भाषा (C#/.NET) में प्लेटफ़ॉर्म-विशिष्ट कार्यान्वयन लिखना आसान है। यह समस्या भाषा सुविधा के बारे में है और इसे UI विजेट API डिज़ाइन के साथ मिश्रित नहीं किया जाना चाहिए।

बहुत सारे देशी एपीआई उपयोग हैं, लेकिन कोई मूल कोड आमंत्रण नहीं है, जहां फ़्लटर एक ही नाव पर होगा (हालांकि ज़ैमरिन को जावा या ओबीजेसी लिखने की आवश्यकता नहीं है, ऐप कोड में कोई प्रतिबिंब हैक नहीं है)। मूल कोड के लिए , यहां तक ​​कि Xamarin.Android पर भी (बैकएंड प्लेटफ़ॉर्म बैकएंड में से एक) मूल कोड का उपयोग बहुत कम है, और ऐप डेवलपर कोई मूल कोड नहीं लिखते हैं।

और रिएक्ट नेटिव या ज़ामरीन के विपरीत, फ़्लटर को अपना पूरा ढांचा प्रदान करना है, इसलिए यह पूरी तरह से उचित दृष्टिकोण है कि हम पूरे फ़्लटर फ्रेमवर्क की तुलना ऐपकिट जैसी चीज़ों से करें।

यह अजीब है कि किसी ने भी क्यूटी ढांचे का उल्लेख नहीं किया है जो सी ++ एकीकरण के संबंध में बाकी सब कुछ बहुत आगे है

क्यूटी सी ++ है। और शुरू करने के लिए एक प्रतिकूल लाइसेंस है।

सोम पर, 12 अगस्त 2019, 06:41 व्लादिस्लाव स्टेलमाखोवस्की, <
सूचनाएं@github.com> ने लिखा:

यह अजीब है कि किसी ने भी क्यूटी ढांचे का उल्लेख नहीं किया है जो बहुत आगे है
सी ++ एकीकरण के संबंध में बाकी सब कुछ

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपने इस थ्रेड की सदस्यता ली है।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/flutter/flutter/issues/7053?email_source=notifications&email_token=AGDYMWXHTJUBUW64LEOO27TQEDSWNA5CNFSM4CXY6LYKYY3PNVWWWK3TUL52HS4DFVREXG43VMVBW63DNMVW20D2071KT
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AGDYMWTNMTM7QUOY2BEIPM3QEDSWNANCNFSM4CXY6LYA
.

क्यूटी सी ++ और क्यूएमएल (जेएस इंजन) है
क्या लाइसेंस? एलजीपीएल? जीपीएल? इसमें गलत क्या है?

IANAL से पहले, लेकिन जैसा कि मैं समझता हूं कि अधिकांश क्यूटी एलजीपीएल (आईडीई इत्यादि जीपीएल हैं) बंद स्रोत है।

तकनीकी रूप से, यदि आप केवल एलजीपीएल का उपयोग करते हैं और अपनी ऑब्जेक्ट फाइलें (और शायद निर्देश) प्रदान करते हैं ताकि उपयोगकर्ता लाइब्रेरी के किसी भिन्न संस्करण के विरुद्ध संभावित रूप से फिर से लिंक कर सकें, तो आप एलजीपीएल की आवश्यकताओं को पूरा कर रहे हैं। लेकिन मुझे पूरा यकीन है कि क्यूटी कंपनी उस तथ्य का विज्ञापन नहीं करती है, इसलिए आम धारणा यह है कि आप स्थिर पुस्तकालयों को तैनात नहीं कर सकते हैं, जिसका अर्थ है कि आप अपने ऐप को ऐप स्टोर पर उनके जबरन लाइसेंस शुल्क का भुगतान किए बिना जारी नहीं कर सकते। और मैं ऑब्जेक्ट फाइल प्रदान करने के बारे में गलत हो सकता हूं, यह सिर्फ मेरी समझ है, और मुझे नहीं पता कि कोई कंपनी ऐसा कर रही है या नहीं।

एंड्रॉइड आसान है क्योंकि यह गतिशील रूप से लोड पुस्तकालयों की अनुमति देता है जिन्हें एलजीपीएल के तहत अधिक स्पष्ट रूप से अनुमति दी जाती है, लेकिन सभी ईमानदारी से स्थिर लिंकिंग शायद ऐप आकार को नीचे रखने के लिए भी बेहतर होगा जिसका अर्थ है कि एक ही समस्या में चल रहा है।

हाय @cpboyd , मुझे लगता है कि मैं इसे विपरीत दिशा से देख रहा हूं। हमारे पास पहले से ही प्लेटफ़ॉर्म विशिष्ट UI फ्रेमवर्क पर निर्मित ऐप्स हैं, जहाँ प्रत्येक प्लेटफ़ॉर्म हमें मौजूदा C++ लाइब्रेरी के हमारे विशाल संग्रह का उपयोग करने की अनुमति देता है। मैं समझता हूं कि स्पंदन क्रॉस-प्लेटफ़ॉर्म है, जो बहुत अच्छा है, लेकिन जब तक मैं वास्तव में इसका उपयोग नहीं कर सकता (मेरे मौजूदा कोड के साथ), तो मैं गैर-क्रॉस-प्लेटफ़ॉर्म UI के साथ चिपके रहने से बेहतर हूं। एकमात्र स्टिकिंग पॉइंट तब आता है जब भविष्य के ओएस (जैसे फुकिया) को फ़्लटर और डार्ट के उपयोग की आवश्यकता होती है, लेकिन इस उपयोग के मामले की अनुमति नहीं देता है। उस स्थिति में बड़े मौजूदा कोडबेस वाले किसी भी व्यक्ति द्वारा इसे अनदेखा किए जाने की संभावना है।

मुझे लगता है कि मुझे यकीन नहीं है कि फ़्लटर/डार्ट को "वेब" ऐप्स (यानी जहां बैकएंड वेब पर हैं) के साथ डिजाइन किया जा रहा है, या पेशेवर डेस्कटॉप एप्लिकेशन डेवलपर्स की जरूरतों पर गंभीरता से विचार किया जा रहा है। अंततः इस तरह के निर्णय ऐप स्टोर पर कई एप्लिकेशन की संख्या और गुणवत्ता को प्रभावित कर सकते हैं। अगर मैं मौजूदा कोड की लाखों लाइनों का उपयोग करते हुए UIKit का उपयोग करके iOS के लिए एक उच्च गुणवत्ता वाला पेशेवर ऐप लिख सकता हूं, लेकिन अगर मैं फुकिया/स्पंदन/डार्ट के लिए विकास कर रहा हूं, तो मैं (लगभग-शून्य प्रदर्शन लागत के साथ) नहीं कर सकता, तो वह होगा एक OS और प्लेटफ़ॉर्म बनें जिसके लिए मैं विकसित नहीं होऊंगा।

मेरी पोस्ट का उद्देश्य फ़्लटर की तुलना अन्य क्रॉस-प्लेटफ़ॉर्म या गैर-क्रॉस-प्लेटफ़ॉर्म लाइब्रेरी से करना नहीं है, यह उन उपयोग मामलों को उजागर करना है जो डेवलपर्स के सबसेट के लिए महत्वपूर्ण हैं।

डार्ट एफएफआई दिलचस्प है, एसक्लाइट उदाहरण के _very_ संक्षिप्त पढ़ने से, यह

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

या C++/WinRT के साथ UWP:

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

धन्यवाद :-)

@Hixie @MarkIngramUK उनमें से कोई भी क्रॉस-प्लेटफ़ॉर्म नहीं है, जो मेरी बात थी।
ऐपकिट केवल ऐप्पल है, जबकि यूडब्ल्यूपी केवल विंडोज़ है।
शायद अगर फ़्लटर ने डार्ट के बजाय स्विफ्ट या सी # का उपयोग किया होता, तो हमारे पास पहले से ही समान स्तर का समर्थन होता, लेकिन यह पूरी तरह से अलग तर्क है।
Xamarin UWP की तुलना में अधिक उपयुक्त तुलना हो सकती है, लेकिन Xamarin के क्रॉस प्लेटफ़ॉर्म दृश्य फ़्लटर के रूप में लगभग अनुकूलन योग्य नहीं थे और अक्सर सभ्य दिखने के लिए बहुत सारे देशी कोड की आवश्यकता होती थी।
मेरा सुझाव अभी भी बना हुआ है: यदि आप सी ++ के साथ फ़्लटर का उपयोग करना चाहते हैं, तो आपको डार्ट टीम के एफएफआई पूर्वावलोकन में भाग लेना चाहिए और हम सभी के लिए समर्थन को बेहतर बनाने में मदद करनी चाहिए

यह समस्या भाषा सुविधा के बारे में है और इसे UI विजेट API डिज़ाइन के साथ मिश्रित नहीं किया जाना चाहिए।

@atsushieno ज़रूर, और इसीलिए डार्ट एफएफआई फोरम पर यह चर्चा अधिक उत्पादक होगी ... स्पंदन ढांचा है। डार्ट भाषा है।

उनमें से कोई भी विशेष रूप से आकर्षक नहीं है जब आप इसकी तुलना निम्नलिखित ओब्जे-सी वर्ग की आसानी से करते हैं:

@MarkIngramUK मुझे यकीन है कि यह ठीक उसी तरह की प्रतिक्रिया है जिसे डार्ट टीम https://groups.google.com/forum/#!forum/dart -ffi पर देखना पसंद करेगी।

मेरे पास ईज़ोर्ड (https://ezored.com) नामक एक परियोजना है जो एसडीके और सी ++ में अनुप्रयोगों के लिए एक सी ++ बूटस्ट्रैप प्रोजेक्ट है। हम मोबाइल प्रोजेक्ट्स (एंड्रॉइड और आईओएस) में उपयोग कर रहे हैं। मैं एक ऐसी परियोजना बनाने के लिए एफएफआई समाप्त होने की प्रतीक्षा कर रहा हूं जो स्पंदन में डिफ़ॉल्ट एसडीके का उपयोग करेगा।

हमें सी ++ के साथ कोई समस्या नहीं है और देव नई सुविधाओं का समय कम हो गया है, क्योंकि एसडीके के पास सभी प्लेटफार्मों में एक ही कोड है, जैसा कि आप डिफ़ॉल्ट कार्यान्वयन (पोको प्रोजेक्ट, ओपनएसएल, एसक्लाइट, विशिष्ट प्लेटफॉर्म कोड एकीकृत) में देख सकते हैं। ब्रिज कोड आदि के साथ)।

मेरे विकल्प में यह सबसे अच्छा तरीका है:

• C++ बैकएंड के साथ iOS और Android (ezored)
• स्पंदन और C++ बैकएंड के रूप में

परियोजना में एक शुरुआत जोड़ने के लिए स्वतंत्र महसूस करें :)

कोटलिन मल्टीप्लेटफार्म एक समाधान हो सकता है, सही विचार नहीं। अभी भी प्रतीक्षा करने की आवश्यकता है https://github.com/dart-lang/sdk/issues/34452

Unity3d लगता है किसी तरह उनके इंजन में स्पंदन पोर्ट कर रहा है जो C# VM [1] पर आधारित है - उस दुनिया में C# और C++ के बीच बात करना सभ्य है। शायद उनके रेपो पर एक नज़र डालने लायक हो कि उन्होंने कुछ मुद्दों को कैसे हल किया। वे कहते हैं: "UIWidgets मुख्य रूप से स्पंदन से प्राप्त होता है"। मैं प्रतिक्रिया देशी शिविर और TurboModules के साथ उनके नए दृष्टिकोण पर भी एक नज़र डालूंगा - उनके समाधान में स्पंदन दृष्टिकोण पर बढ़त हो सकती है क्योंकि यह होगा
1) तुल्यकालिक और अतुल्यकालिक दोनों और
2) कोई मार्शलिंग नहीं होगी और
3) न केवल C बल्कि C++ को सपोर्ट करेगा

मैं दोनों खेमों की जय-जयकार कर रहा हूं।

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

डार्ट 2.5 के अनुसार, यह ( dart:ffi ) अब पूर्वावलोकन में है:
https://medium.com/dartlang/announcing-dart-2-5-super-charged-development-328822024970

बढ़िया खबर!

मम्म... क्या स्पंदन के साथ ओबो का उपयोग करना पर्याप्त होगा?..

https://github.com/google/oboe

@rg4real हाँ! लेकिन, आपको कुछ सी रैपर लिखने होंगे क्योंकि ओबो इंटरफ़ेस सी ++ में है।

आरंभ करने के निर्देशों के लिए आप https://github.com/flutter/flutter/wiki/Binding-to-native-code-via-FFI देख सकते हैं।

आप मेरे oboe-c.so पुन: उपयोग कर सकते हैं जो मैंने अपने सी # बाइंडिंग के लिए लिखा था, अगर वह काम करता है https://github.com/atsushieno/oboe-sharp/tree/master/native

@ sjindel-google, यह कुछ कमाल की खबरें हैं!

तो मुझे कक्षाएं और कार्य बनाकर सी ++ और सी कोड के बीच एक पुल बनाने की जरूरत है। और फिर मैं उन कक्षाओं का उपयोग कर सकता हूं और उस फ़ंक्शन को डार्ट कोड से कॉल कर सकता हूं। मुझे लगता है कि यह सही है।

@atsushieno , धन्यवाद। मैं देख रहा हूँ। मुझे यकीन नहीं है कि मेरे मामले में पुल कैसे बनाया जाए (अनुभव की कमी)। लेकिन क्या आपने ओबो के साथ सटीक खेलने के अपने समग्र लक्ष्य को प्राप्त करने का प्रबंधन किया? क्या यह इतना अच्छा था?

@ rg4real मैं कम विलंबता ऑडियो की तुलना में केवल सरल API (OpenSLES की तुलना में) के लिए कर रहा था। अगर मैं वास्तव में विलंबता के बारे में गंभीर होता तो मैं Xamarin.Android का उपयोग नहीं करता। यदि आप ओबो (या इसके पीछे ऑडियो) के बारे में बात कर रहे हैं, तो मैं इसे फ्लूइडसिंथ में उपयोग करता

स्मृति कैसे प्रबंधित की जाती है इस पर कोई गाइड है?

यदि सी ++ कोड नए/मॉलोक का उपयोग करके मेमोरी बनाता है और डार्ट कोड पर वापस आता है, तो उस मेमोरी को कैसे मुक्त किया जाए।

सी++ कोड
शून्य फू (चार ** बाहर) {
*बाहर = नया चार [25];
}

|आउट| . को सौंपी गई मेमोरी को कैसे डिलीट करें डार्ट कोड से चर?

यदि आप डार्ट 2.5 पर हैं, तो .free() पर Pointer । यदि आप देव/मास्टर शाखा में हैं तो यह विधि package:ffi https://github.com/dart-lang/ffi/blob/master/lib/src/allocation.dart#L70 स्थानांतरित हो गई है

टिप्पणी के अनुसार - "इसका उपयोग केवल [आवंटित] के बराबर तरीके से आवंटित पॉइंटर्स के विरुद्ध किया जा सकता है।" - फ्री () का उपयोग केवल तभी किया जा सकता है जब मेमोरी आवंटित () विधि का उपयोग करके आवंटित की जाती है।

जैसे
एफएफआई.सूचकपीटीआर = एफएफआई। सूचकआवंटित ();
पीटीआर मुक्त ();

क्या यह स्मृति को मुक्त करने का ख्याल रखता है जिसे सी ++ पक्ष में डार्ट कोड से नए या मॉलोक का उपयोग करके आवंटित किया जाता है?

जब तक स्मृति को malloc माध्यम से आवंटित किया गया था, या तो डार्ट या सी ++ के माध्यम से, इसे free मुक्त किया जा सकता है।

डार्ट 2.6 हम का उपयोग DynamicLibrary.lookupFunction("free") परिभाषित करने के लिए free डार्ट में, तो यह हो जाएगा बिल्कुल वैसा ही free कार्यक्रम के सी ++ भाग में के रूप में। (जब तक आप अपने बाइनरी में free कई संस्करणों में लिंक नहीं कर रहे हैं।)

इस समस्या को बंद करना क्योंकि यह सुविधा अब सभी फ़्लटर चैनलों में आम तौर पर (बीटा में) उपलब्ध है। हम इस मुद्दे को सुधारना जारी रख रहे हैं। किसी भी विस्तृत समस्या के लिए, कृपया उन्हें https://github.com/dart-lang/sdk/issues/new पर दर्ज करें।

सी ++ कक्षाओं को सी संगतता बनाना गन्दा है। कृपया सी ++ कक्षाओं को सीधे कॉल करने की क्षमता बनाएं

+1 क्या हमारे पास सी ++ समर्थन हो सकता है?

@KaungZawHtet और @fzyzcjy - कृपया इसके लिए एक नया मुद्दा (शायद स्पंदन के बजाय डार्ट-लैंग में) खोलने पर विचार करें।

मैं इस मुद्दे को बंद करने जा रहा हूं - इसमें बहुत से लोगों ने सदस्यता ली है, लेकिन इसका मूल लक्ष्य बहुत स्पष्ट रूप से हल किया गया है।

हां, नए मुद्दों के लिए, कृपया उन्हें इस लिंक का उपयोग करके फाइल करें: https://github.com/dart-lang/sdk/issues/new?labels=library-ffi ,area-vm