क्यूटी के साथ अधिक डेस्कटॉप ऐप क्यों नहीं लिखे गए हैं? [बन्द है]

Question

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

Comments

यह देशी C ++ है। अधिकांश डेवलपर्स उच्च स्तरीय भाषाओं जैसे C # को पसंद करेंगे।

— user16764

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

— eda-qa mort-ora-y

@ user16764: "सबसे"?

— ऑर्बिट

मुझे नहीं लगता कि TIOBE इंडेक्स वास्तव में सटीक उपाय है, क्योंकि यह लोकप्रियता को मापता है, उपयोग नहीं। GitHub, Bitbucket, Codeplex, और Sourceforge जैसे ओपन सोर्स रिपॉजिटरी में कोड की मात्रा की तुलना करना अधिक सटीक माप देगा। (और मेरा मानना ​​है कि उन अधिक सटीक मापों ने # 1 और # 2 स्थानों में C और C ++ डाला - जावा को TIOBE सूचकांक में एक अनुचित लाभ है क्योंकि यह नए कॉलेज के पाठ्यक्रमों के लिए उपयोग किया जाता है, और नए प्रोग्रामर अनुभवी लोगों की तुलना में अधिक चर्चा करते हैं)

— बिली ओनली

@ जियोर्जियो: एर्म, आपको सी # में ऐसी चीजों के बारे में सोचना होगा। "जो इसका मालिक है" की अवधारणा "कॉल करने वाले delete" से कहीं आगे जाती है । यह तथ्य कि स्मार्ट पॉइंटर्स स्पष्ट करते हैं कि कोई भाषा विफल नहीं है; और यदि आप ऐसी चीजों के बारे में नहीं सोचते हैं जो आप किसी भी उच्च स्तरीय भाषा में कचरा उत्पन्न करने जा रहे हैं, तो मैंने भी देखा है।

— बिली ओनेल

Answer 1

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

1. कुछ मामलों में, यह सिर्फ देशी कार्यक्रमों की तरह नहीं दिखता है। विभिन्न विज़ुअल स्टाइलिंग कारणों से मशीन से मशीन में स्थानांतरित होने पर स्वाभाविक रूप से सभी प्लेटफार्मों के लिए एक ही यूआई डिज़ाइन करना सही नहीं लग रहा है। उदाहरण के लिए, मैक मशीनों पर, स्प्लिट बार आमतौर पर अपेक्षाकृत मोटे होते हैं, और बटन छोटे और आइकनों के साथ गोल होते हैं। विंडोज मशीनों पर, स्प्लिट बार आम तौर पर संकीर्ण होते हैं, और बटन अधिक पाठ डिजाइन होते हैं, जिसमें अधिक वर्ग डिजाइन होते हैं। सिर्फ इसलिए कि आप प्रत्येक प्लेटफ़ॉर्म के लिए एक यूआई लिख सकते हैं इसका मतलब यह नहीं है कि आपको अधिकांश अनुप्रयोगों के लिए होना चाहिए।
2. Qt एक C ++ लाइब्रेरी नहीं है। इसके लिए एक अलग संकलन चरण की आवश्यकता होती है, जो अधिकांश अन्य पुस्तकालयों की तुलना में बिल्ड प्रक्रिया को अधिक जटिल बनाता है।
3. (2) के परिणामस्वरूप, C ++ IDE और उपकरण Qt अभिव्यक्तियों को त्रुटियों के रूप में चिह्नित कर सकते हैं, क्योंकि वे Qt की बारीकियों को नहीं समझते हैं। यह लगभग QtCreator का उपयोग करता है या जैसे केवल एक पाठ संपादक का उपयोग करता है vim।
4. क्यूटी एक बड़ी मात्रा में स्रोत है, जिसे संकलन से पहले आपके द्वारा उपयोग की जाने वाली किसी भी मशीन पर मौजूद और पूर्वस्थापित होना चाहिए। यह एक बिल्ड वातावरण को और अधिक थकाऊ बना सकता है।
5. यह केवल LGPL के तहत उपलब्ध है, जो एकल-बाइनरी-परिनियोजन का उपयोग करना मुश्किल बनाता है जब किसी को अधिक प्रतिबंधात्मक या कम प्रतिबंधात्मक लाइसेंस के तहत जारी करने की आवश्यकता होती है।
6. यह बहुत बड़े संकलित बायनेरिज़ का उत्पादन करता है जब इसकी तुलना "सादे ol 'देशी अनुप्रयोगों" (केडीई के लिए लिखे गए पाठ्यक्रम अनुप्रयोगों को छोड़कर) के साथ की जाती है।

Comments

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

— बिली ओनेल

# 6 सबसे बड़ा कारण है जिससे मैं बचता हूं। मेरा मतलब है, मैं एक बड़ा, भद्दा कार्यक्रम नहीं चाहता हूं, और मुझे एक विशिष्ट लाइसेंस के लिए बाध्य होना पसंद नहीं है, लेकिन यह वास्तव में मेरे लिए एक अच्छा, देशी लुक-एंड-फील की कमी है। ओएसएक्स और विंडोज के हाल के संस्करणों ने विशेष रूप से अपने देशी इंटरफेस को सुंदर, तेज और कार्यात्मक बनाने का एक शानदार काम किया है, और मैं उन सभी कामों का लाभ उठाऊंगा जो उन्होंने मेरे लिए पहले ही किए हैं; मुझे लगता है कि बिना देशी दिखावे के कई कार्यक्रम मुझे सस्ते लगते हैं और मेरे लिए (हमेशा नहीं, लेकिन यह मुझे थोड़ा बाहर निकालता है)।

— ग्रेग जैक्सन

आपका नंबर 6 नंबर 1 होना चाहिए था। यह अब तक Qt के साथ सबसे बड़ी समस्या है। कई मामलों में, यह मूल एपीआई का उपयोग नहीं करता है। मुझे देशी दिखना मेरा सॉफ्टवेयर पसंद है। उपयोगकर्ताओं को भी पसंद है। मैंने कभी नहीं देखा है कि एक मैक एप्लीकेशन क्यूटी के साथ बनाया गया है जो मैक एप्लीकेशन की तरह दिखता है। न ही किसी अन्य मैक उपयोगकर्ता हैं, और वे उस तरह के बारे में picky हैं। आप इसे "क्रॉस-प्लेटफ़ॉर्म" होने के सभी लाभ खो देते हैं यदि आप केवल लिनक्स अनुप्रयोगों को बनाने के लिए इसका उपयोग कर रहे हैं, जो कि केवल उसी जगह के बारे में है जो मूल दिखता है क्योंकि वास्तव में मूल कुछ भी नहीं है।

— कोड़ी ग्रे

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

— gbjbaanb

@TrevorBoydSmith: क्षमा करें, लेकिन आप गलत हैं। क्यूटी एकमात्र ढांचा है जो प्रीप्रोसेसिंग का उपयोग करता है। अवधि। GNOME, FLTK, WX और दोस्तों की जाँच करें, और मुझे एक प्रीप्रोसेसिंग चरण दिखाएं। आपको एक नहीं मिलेगा। कुछ अन्य पुस्तकालय अलग-अलग बिल्ड सिस्टम के साथ आते हैं, लेकिन दिन के अंत में, वे C ++ लाइब्रेरी हैं जो किसी भी C ++ कंपाइलर द्वारा बनाए जा सकते हैं। जैसा कि "मेरे कारणों में कच्चे win32 मौजूद नहीं है", यह मेरे कारणों में # 5 और # 6 के रूप में मौजूद है।

— बिली ओनेल

Answer 2

जैसा कि लोग कहते हैं, प्रत्येक उपकरण प्रत्येक समस्या और स्थिति के लिए फिट बैठता है ...

लेकिन अगर आप C ++ प्रोग्रामर हैं, तो Qt आपकी रूपरेखा है। कोई प्रतिद्वंद्वी नहीं।

हम एक जटिल मेडिकल इमेजिंग कमर्शियल एप्लीकेशन विकसित करते हैं, और क्यूटी धारण करते हैं।

मैं यह नहीं कहता कि लोग इसके बारे में जो 'विपक्ष' कहते हैं वह गलत है, लेकिन मुझे लगता है कि उन्होंने लंबे समय तक क्यूटी की कोशिश नहीं की है (इसके प्रत्येक नए संस्करण में लगातार सुधार ...) और, ज्यादातर यदि आप ध्यान रखते हैं तो वे जिन मुद्दों पर टिप्पणी करते हैं वे सभी समस्या नहीं हैं।

UI प्लेटफ़ॉर्म असंगतता: केवल अगर आप UI विजेट्स का उपयोग करते हैं, तो वे 'बिना किसी अनुकूलन या कस्टम आर्ट' के हैं।

Qt पूर्वप्रक्रमक अधिभार: केवल तभी जब आप सिग्नल-स्लॉट तंत्र का दुरुपयोग करते हैं, या QObject वंशानुक्रम, जब वास्तव में कोई आवश्यकता नहीं होती है।

वैसे, हम अभी भी C # .NET में एप्लिकेशन लिखते हैं, और लंबे समय से कर रहे हैं। इसलिए मुझे लगता है कि मेरे पास दृष्टिकोण है।

जैसा कि मैंने कहा, प्रत्येक स्थिति के लिए प्रत्येक उपकरण,

लेकिन Qt कोई संदेह नहीं है कि एक सुसंगत और उपयोगी रूपरेखा है।

Comments

+1 थाक्स! मैं बस वही लिखना चाहता था। सबसे बकवास "गैर खुला स्रोत / वाणिज्यिक तर्क" है। आश्चर्यजनक, कितने लोग ओपन-सोर्स शब्द को समझते हैं। क्यूटी ओपन-सोर्स था क्योंकि मैं इसका इस्तेमाल करता हूं (1.4)। और इसके पास सबसे उचित लाइसेंस होता था: Qt -> वेतन के साथ पैसा कमाते थे।

— वैलेंटाइन हेनित्ज

ओह और मैं वास्तव में 50 एमबी कला और वीडियो ट्यूटोरियल और डेटा के 200 एमबी से अधिक के आवेदन के लिए 10 एमबी डीएलएल को जोड़ने के बारे में परवाह नहीं करता हूं :)

— Пет dataр Петров

क्यूटी के लिए आवश्यक स्थान इन दिनों सस्ता है।

— त्रिशूक्र

यह बहुत अधिक Qt (विगेट्स फ्रेमवर्क के साथ मेरे अनुभव से मेल खाता है, मैंने अब तक किसी भी गंभीर चीज के लिए QML / QtQuick का उपयोग नहीं किया है)। यह जटिल यूआई आवश्यकताओं के साथ बड़े अनुप्रयोगों को लिखने के लिए उपयुक्त है। एक बार जब आप इसे सीख लेते हैं, तो आप बहुत उत्पादक हो सकते हैं। यदि बिल्ड सिस्टम ठीक से ठीक है, तो उल्लेख किया गया विपक्ष (एमओपी आईएनजी, यूआई फाइलें, आदि के लिए अलग संकलन चरण) कोई समस्या नहीं है। मैं या तो qmake या cmake की सिफारिश कर सकता हूँ।

— Nils

Qt 5.8 से बाद में Qt Lite नाम का एक प्रोजेक्ट आता है जो आपकी विशिष्ट जरूरतों के लिए बेहद क्यूटी को कम करता है। यह एक वाणिज्यिक विशेषता है;)

— SMMousavi

Answer 3

उन सभी चीजों में से, जिन्हें मैं क्यूटी के बारे में पसंद नहीं करता हूं, यह तथ्य कि यह टेम्पलेट्स के साथ अच्छा नहीं खेलता है, मुझे सबसे ज्यादा परेशान करता है। आप ऐसा नहीं कर सकते:

template < typename T >
struct templated_widget : QWidget
{
  Q_OBJECT;

public signals:
  void something_happened(T);
};

यह प्रीप्रोसेसर के साथ भी अच्छा नहीं खेलता है। आप ऐसा नहीं कर सकते:

#define CREATE_WIDGET(name,type) \
struct name ## _widget : QWidget \
{ \
  Q_OBJECT; \
\
public signals: \
  void something_happened(type); \
}

इस तथ्य के साथ, कि एक सिग्नल के प्रति प्रतिक्रिया करने वाली प्रत्येक चीज़ को Q_OBJECT होना चाहिए, Qt को C ++ प्रोग्रामर के लिए काम करना कठिन बनाता है। जावा या पायथन शैली की प्रोग्रामिंग के लिए लोग शायद वास्तव में बेहतर थे।

मैंने वास्तव में बहुत समय और प्रयास किए और शोध किया और एक प्रकार से सुरक्षा हासिल करने का तरीका तैयार किया और किसी भी फ़नकार वस्तु से एक Qt सिग्नल कनेक्ट किया: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-ignignals -इन-क्यूटी कदम-1.html

जिस तरह की चीज मैं करना चाहता हूं, वह बुनियादी है, रोज़ सी ++ विकास जो कि क्यूटी मॉक द्वारा असंभव के बगल में बनाया गया है ... जो कि अब पूरी तरह से अब अनावश्यक है, अगर यह वास्तव में कभी था।

सच कहूँ तो, मैं इसके साथ फंस गया हूँ क्योंकि अगर आप स्वचालित UI परीक्षण करना चाहते हैं, तो Qt, MFC के शहर के एकमात्र गेम में बहुत अधिक गेम है ... जो कि 1980 है (यह उस बकवास में काम करना बहुत मुश्किल है)। कुछ WX कह सकते हैं, लेकिन यह और भी गंभीर समस्या है। GTKmm मेरी पहली पसंद होता, लेकिन चूंकि यह सभी स्वामी द्वारा तैयार किया गया है और यह एक्सेसिबिलिटी नहीं करता है ... इसलिए उद्योग मानक परीक्षण सॉफ्टवेयर द्वारा संचालित नहीं किया जा सकता है। Qt उस संबंध में काफी कठिन है ( बमुश्किल काम करता है जब आप एक्सेसिबिलिटी प्लगइन को संशोधित करते हैं)।

Comments

ब्याज से बाहर, आप WX के साथ मुख्य समस्याओं के रूप में क्या देखते हैं?

— टॉम एंडरसन

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

— एडवर्ड स्ट्रेंज

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

— एडवर्ड स्ट्रेंज

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

— टॉम एंडरसन

एक सिग्नल पर प्रतिक्रिया देने वाली हर चीज को Q_OBJECT होना चाहिए, आजकल नहीं ... अब, स्थैतिक कार्य, फ़ंक्शन और यहां तक ​​कि लैम्ब्डा फ़ंक्शन भी सिग्नल का जवाब दे सकते हैं (आप फ़ंक्शन पॉइंटर्स को स्लॉट के रूप में उपयोग कर सकते हैं)। यदि आप उन्हें एक std का उपयोग करके कनेक्ट करते हैं तो नो-QObject क्लास में सदस्य स्लॉट भी हो सकते हैं। उदाहरण के सदस्य को फ़ंक्शन पॉइंटर में बदलने के लिए बाँधें।

— विनियस ए। जोर्ज

Answer 4

क्यूटी का उपयोग न करने का एक कारण यह है कि यदि आप केवल एक आर्किटेक्चर के लिए लिखते हैं, जैसे कि विंडोज, तो आप C # /। NET (या मैक पर कोको) का उपयोग करना चाह सकते हैं क्योंकि वे हमेशा नवीनतम घंटियों का लाभ उठा पाएंगे। -वाइस के ओएस।

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

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

हालाँकि नियम कहते हैं कि मुझे इस सवाल का जवाब देने पर ध्यान केंद्रित रखना चाहिए, मैं बिली ओनेल द्वारा उठाए गए कुछ मुद्दों का खंडन करना चाहता हूं, जो मुझे लगता है कि क्यूटी का उपयोग नहीं करने के लिए आमतौर पर उद्धृत कारणों को संक्षेप में प्रस्तुत करना अच्छा काम करता है:

1. Qt वास्तव में एक C ++ लाइब्रेरी / फ्रेमवर्क / हेडर फाइलें हैं। यह संवर्धित हैमैक्रो प्रोसेसर (moc) द्वारा जो कई अन्य चीजों के बीच सिग्नल और स्लॉट को सक्षम करता है। यह अतिरिक्त मैक्रो कमांड (जैसे Q_OBJECT) को रूपांतरित करता है ताकि कक्षाओं में आत्मनिरीक्षण और अन्य प्रकार की अन्य अच्छाइयाँ हो जो आप C-++ में उद्देश्य-सी कार्यक्षमता जोड़ने के बारे में सोच सकते हैं। यदि आप सी ++ के बारे में पर्याप्त जानते हैं कि शुद्धता की कमी के कारण आप परेशान हैं, तो आप एक समर्थक हैं, तो 1) Q_OBJECT का उपयोग न करें और इसका ilk या 2) आभारी रहें कि यह ऐसा करता है, और बहुत ही सीमित मामलों के आसपास कार्यक्रम करता है जहाँ यह एक समस्या का कारण बनता है। "सिग्नल और स्लॉट के लिए बूस्ट का उपयोग करें" कहने वाले लोगों के लिए! तब मैं प्रतिशोध करूंगा कि आप एक "समस्या" का दूसरे के लिए आदान-प्रदान कर रहे हैं। बूस्ट बहुत बड़ा है, और इसके अपने सामान्य तौर पर उद्धृत मुद्दे हैं जैसे खराब प्रलेखन, भयावह एपीआई और क्रॉस-प्लेटफॉर्म भयावहता (जीसी 3 जैसे पुराने संकलक सोचते हैं)।

2. संपादक के समर्थन के लिए, यह भी 1 से अनुसरण करता है, मैं कुछ हद तक सहमत हूं। वास्तव में, क्यूटी क्रिएटर IMHO सबसे अच्छा ग्राफिकल सी ++ संपादक है, अवधि, भले ही आप क्यूटी सामान का उपयोग न करें। कई पेशेवर प्रोग्रामर emacs और विम का उपयोग करते हैं। इसके अलावा, मुझे लगता है कि एक्लिप्स अतिरिक्त सिंटैक्स को संभालता है। इस प्रकार, क्यूटी मैक्रोज़ (Q_OBJECT) या सिग्नल / स्लॉट परिवर्धन के साथ कोई समस्या नहीं है। आप शायद इन मैक्रोज़ को विज़ुअल स्टूडियो में नहीं पाएंगे, क्योंकि (मैं मानता हूं) वे सी ++ के अतिरिक्त हैं। लेकिन और बड़े, C # /। नेट के लोग वैसे भी Qt का उपयोग नहीं करने जा रहे हैं, इस तथ्य के कारण कि उनकी अपनी स्वामित्व तकनीकों के साथ बहुत अधिक कार्यक्षमता है।

3. क्यूटी स्रोत के आकार के रूप में, यह रात भर में संकलित करता है, कौन परवाह करता है? मैंने अपने दोहरे कोर मैकबुक पर "रात से भी कम समय में क्यूटी 4 संकलित किया।" मुझे निश्चित रूप से उम्मीद है कि यह वह नहीं है जो किसी विशेष तकनीक का उपयोग करने या न करने के आपके निर्णय को चला रहा है। यदि यह वास्तव में एक समस्या है, तो आप Qt वेबसाइट से मैक, लिनक्स और विंडोज के लिए पूर्वनिर्धारित एसडीके डाउनलोड कर सकते हैं।

4. लाइसेंसिंग तीन विकल्पों में उपलब्ध है: 1) यदि आप Qt ITSELF को संशोधित करना चाहते हैं या नहीं, तो इस तथ्य को छिपाएं कि कोई व्यक्ति Qt का उपयोग कर रहा है और अटेंशन देने के लिए तैयार नहीं है (ब्रांडिंग और छवि के लिए बहुत महत्वपूर्ण हो सकता है!) 2 ) जीपीएल और 3) एलजीपीएल। हां, स्थैतिक लिंकिंग (सभी क्यूटी को बाइनरी में रोल करना) के साथ समस्याएं हैं - लेकिन मुझे लगता है कि यह अधिक है क्योंकि कोई अंदर नहीं झांक सकता है और नोटिस कर सकता है कि आप क्यूटी (एट्रिब्यूशन!) का उपयोग कर रहे हैं। मैंने डिगिया से एक स्वामित्व लाइसेंस खरीदने की कोशिश की, और उन्होंने मुझसे कहा "आप जो कर रहे हैं, उसके लिए आपको वास्तव में इसकी आवश्यकता नहीं है।" वाह। एक व्यवसाय से जो लाइसेंस बेचने के व्यवसाय में है।

5. बाइनरी / बंडल का आकार इसलिए है क्योंकि आपको क्यूटी सामान उन लोगों को वितरित करना होगा जिनके पास नहीं है: विंडोज पहले से ही है? विजुअल स्टूडियो सामान या आपको रन-टाइम इंस्टॉल करना होगा। मैक पहले से ही विशाल कोको के साथ आता है, और गतिशील रूप से जुड़ा हो सकता है। हालाँकि, मैं बहुत अधिक वितरण नहीं करता, फिर भी मैंने ~ 50 मेगाबाइट स्थिर फ़ाइल (जो मैं बाइनरी स्ट्रिपर / कुछ यूपीएक्स जैसी संपीड़न उपयोगिताओं के साथ छोटा भी बना सकता हूं) को वितरित करने के साथ बहुत अधिक समस्या नहीं पाई है। मुझे ऐसा करने के लिए पर्याप्त परवाह नहीं है, लेकिन अगर बैंडविड्थ कभी भी एक मुद्दा था, तो मैं अपनी बिल्ड स्क्रिप्ट में एक UPX कदम जोड़ूंगा।

6. क्या "मूल रूप और अनुभव को परिभाषित करता है?" मुझे लगता है कि "सबसे" सहमत होगा कि मैक एकीकृत रूप और अनुभव के करीब आता है। लेकिन यहाँ मैं सफ़ारी, आईट्यून्स, एपर्चर, फ़ाइनल कट प्रो, पेज आदि देख रहा हूँ और वे इस तथ्य के बावजूद एक जैसे नहीं दिखते कि वे OS विक्रेता द्वारा बनाए गए हैं। मुझे लगता है कि "फील" पहलू अधिक प्रासंगिक है: विजेट स्टाइलिंग, जवाबदेही, आदि। यदि आप जवाबदेही की परवाह करते हैं, तो यहां जावा, या कुछ अन्य अत्यधिक गतिशील भाषा के बजाय C ++ का उपयोग करने का एक अच्छा कारण है। (उद्देश्य सी भी चट्टानों, लेकिन मैं क्यूटी के बारे में मिथकों को दूर करने की कोशिश कर रहा हूं)

संक्षेप में, यह एक जटिल मुद्दा है। लेकिन मैं यह बताना चाहता हूं कि मुझे लगता है कि "क्यूटी का उपयोग नहीं करने" के कम कारण हैं क्योंकि कोई मिथकों और दशक के बाहर की जानकारी के आधार पर सोच सकता है।

Comments

जो कुछ मुझे नहीं मिलता है वह यह है कि ये क्रॉस प्लेटफॉर्म लाइब्रेरीज़ केवल आवरण कार्यों, या इससे बेहतर क्यों नहीं हैं; अगर कोको, Win32, KDE / सूक्ति कार्यों के आसपास दोष है, तो यह सभी सुविधाओं के साथ सबसे अच्छी दिखने वाली UI को सुनिश्चित करता है।

— मार्कस जे।

@MarcusJ एक टूलकिट के चारों ओर एक आवरण लिखना विशिष्ट रूप से गैर-तुच्छ है, कभी भी 4 या अधिक का मन नहीं करता है - लेकिन अगर आपको लगता है कि यह इतना आसान है, तो आप कोशिश करने के लिए स्वागत करते हैं। इस विचार के लिए कि यह केवल सशर्त प्रीप्रोसेसिंग का उपयोग करके प्राप्त किया जा सकता है ... आपको मज़ाक करना चाहिए, है ना?

— अंडरस्कोर_ड

@MarcusJ libui ठीक यही है (हालांकि केडीई समर्थन के बिना)।

— डेमी

मैं यह जोड़ना चाहता हूं कि अब आप .NET के साथ Qt / QML का उपयोग कर सकते हैं। आपको C ++ को छूने की आवश्यकता नहीं है। github.com/qmlnet/qmlnet PS: मैं लेखक हूं।

— पॉल नोपफ

Answer 5

इसमें से कुछ लाइसेंस है। कुछ लाइसेंसिंग इतिहास के लिए https://en.wikipedia.org/wiki/Qt_(software)#Licensing देखें । 2000 तक, जो लोग खुले स्रोत के बारे में दृढ़ता से परवाह करते थे, उन्होंने क्यूटी का उपयोग नहीं किया। अवधि। (यह वास्तव में, ग्नोम के विकास के लिए मूल प्रेरणा थी।) 2005 तक, जो लोग विंडोज के लिए मुफ्त सॉफ्टवेयर जारी करने में सक्षम होना चाहते थे, उन्होंने क्यूटी का उपयोग नहीं किया। उस तारीख के बाद भी जो लोग GPL के अलावा किसी अन्य चीज के तहत मुफ्त सॉफ्टवेयर चाहते थे, उनके पास केवल Qt का उपयोग करने का विकल्प नहीं था। इस प्रकार कोई भी मुफ्त सॉफ्टवेयर परियोजना जो उन तारीखों से पुरानी है, Qt का उपयोग नहीं कर सकती है। और, ज़ाहिर है, मालिकाना कोड लिखने वाले लोगों को विशेषाधिकार के लिए भुगतान करना पड़ता था।

इसके अलावा ऐसा नहीं है कि अन्य विकल्पों की कमी है। उदाहरण के लिए WxWidgets , GTK + , और Tk सभी खुले स्रोत, क्रॉस-प्लेटफ़ॉर्म टूलकिट हैं।

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

Comments

@btilly: GTK + क्रॉस प्लेटफॉर्म है। उदाहरण के लिए, Pidgin IM क्लाइंट GTK + पर लिखा गया है।

— बिली ओनेल

ठीक है, हालाँकि, यह संभव है 'किसी तरह' विंडोज पर चलने के लिए :)

— डीह्यूमनाइज़र

बस विंडोज पर GIMP इंस्टॉल करें और एक नज़र डालें।

— user281377

हाँ, और जीआईएमपी विंडोज पर अच्छा काम करता है, लेकिन यह निश्चित रूप से विंडोज 7 यूआई लुक और फील के साथ फिट नहीं होता है।

— एलन बी

Pidgin शायद विंडोज पर GTK का एक बेहतर उदाहरण है। यह कुछ भी कल्पना नहीं करता है, लेकिन इसमें फिट बैठता है और शायद 10 साल या उससे अधिक के लिए है?

— ब्रेंडन लॉन्ग

Answer 6

मैं ऊपर वर्णित सभी कारणों से सहमत हूँ, हालाँकि यहाँ बहुत सारे लोगों ने कहा है कि वे अतिरिक्त ओवरहेड की वजह से Qt का उपयोग नहीं करेंगे जो यह अपने साथ लाता है। मैं इससे सहमत नहीं हूं क्योंकि आज (जावा, सी # और पायथन) सभी सबसे आम भाषाएं अपने आप में काफी हद तक ऊपर ले जाती हैं।

दूसरे, क्यूटी C ++ के साथ प्रोग्रामिंग को इतना आसान और सीधे-आगे बनाता है कि यह अतिरिक्त संसाधनों का उपयोग करता है। मैं मानक C ++ के बजाय क्यूटी में लिखे गए कुछ सांत्वना अनुप्रयोगों के कारण आया हूं क्योंकि वे आसानी से लिखे जा सकते हैं।

मैं कहूंगा कि Qt की उत्पादकता C / C ++ से अधिक है लेकिन पायथन जैसी भाषाओं से कम है।

Comments

मुझे लगता है कि यह सभी व्यक्ति के अनुभव के सापेक्ष है, क्योंकि मैं सी ++ 14 में ओके कोड कर सकता हूं, लेकिन हर बार जब मैं किसी क्यूटी कोड को देखता हूं, तो मुझे इसे उसी भाषा के रूप में पहचानने के लिए कड़ी मेहनत करनी होगी ... इसलिए मैं निश्चित रूप से डॉन लगता है कि यह सर्वसम्मत उत्पादकता बूस्टर है जो आप यहां लगा रहे हैं।

— underscore_d

@underscore_d स्पष्ट रूप से यदि आप C ++ को अच्छी तरह से जानते हैं और आप Qt नहीं करते हैं, तो आप बाद वाले के साथ अधिक उत्पादक नहीं होंगे। लेकिन जब आपको सी ++ और क्यूटी दोनों का पता चलता है, तो रूपरेखा वास्तव में बहुत सी चीजों को आसान और त्वरित रूप से लागू करने के लिए बना रही है (सी ++ 11, 14 आदि) अंतराल को भर रहे हैं, लेकिन अभी तक पूरी तरह से नहीं।

— यमोरो

Answer 7

यह वास्तव में एक लौ युद्ध शुरू करने का प्रयास नहीं है, मैं सिर्फ कुछ बिंदुओं को संबोधित करना चाहता था।

संभवतः वास्तविक कारण यह है कि क्यूटी अधिक व्यापक रूप से उपयोग नहीं किया जाता है, यह है कि यह सी ++ है और कम लोग डेस्कटॉप ऐप के लिए सी ++ का उपयोग करते हैं।

Qt एक C ++ लाइब्रेरी नहीं है। इसके लिए एक अलग संकलन चरण की आवश्यकता होती है, जो अधिकांश अन्य पुस्तकालयों की तुलना में बिल्ड प्रक्रिया को अधिक जटिल बनाता है।

दृश्य स्टूडियो के लिए vs-addin यह स्वचालित रूप से करता है जैसा कि Qt की अपनी कमांडलाइन प्रक्रिया बनाती है। MFC के लिए संवाद बनाने के लिए उपयोग किया जाने वाला संसाधन संकलक भी एक अलग चरण है लेकिन यह अभी भी c ++ है।

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

दृश्य स्टूडियो के प्रत्येक संस्करण के लिए एक द्विआधारी डाउनलोड है और स्रोत से निर्माण एक एकल आदेश है। मुझे नहीं लगता कि एसडीके स्रोत का आकार इन दिनों बहुत अधिक है। विजुअल स्टूडियो अब आपको चुनने और चुनने के बजाय सभी सी ++ कामों को स्थापित करता है, परिणामस्वरूप संकलक का इंस्टॉल आकार> 1 जीबी है।

यह केवल LGPL के तहत उपलब्ध है, जो एकल-बाइनरी-परिनियोजन का उपयोग करना मुश्किल बनाता है जब किसी को अधिक प्रतिबंधात्मक या कम प्रतिबंधात्मक लाइसेंस के तहत जारी करने की आवश्यकता होती है।

LGPL केवल lib पर लागू होता है, यह आपके कोड को प्रभावित नहीं करता है। हां इसका मतलब है कि आपको एक एकल बाइनरी (जब तक आप भुगतान नहीं करते हैं) के बजाय डीएलएल को जहाज करना होगा, लेकिन एक ऐसी दुनिया में जहां आपको एक छोटे से उपयोग के लिए जावा रनटाइम या। नेट अपडेट डाउनलोड करने की आवश्यकता है यह इतना बड़ा सौदा नहीं है। यह एक एकल ABI के साथ प्लेटफार्मों पर एक समस्या से भी कम है ताकि अन्य Qt एप्लिकेशन लिबास साझा कर सकें।

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

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

Comments

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

— वॉरेन पी

अधिकांश डेस्कटॉप सी ++ सॉफ्टवेयर या तो एमएफसी में है क्योंकि यह 20 साल पहले शुरू हुआ था या एमएफसी से बचने के लिए 20 साल पहले शुरू किए गए आंतरिक टूलकिट का उपयोग करता है (जैसे एमएस-ऑफिस या ऑटोकैड)। मुझे संदेह है कि WPF के साथ C ++ / CLR में बहुत कुछ लिखा जा रहा है। लेकिन यहां तक ​​कि क्रॉस-प्लेटफॉर्म विचार के बिना मुझे Qt सबसे अच्छा लगता है (या कम से कम सबसे खराब!) डेस्कटॉप टूलकिट। ज्यादातर लोगों की तरह हम एक वेबबी फ्रंट एंड की ओर बढ़ रहे हैं (संभवतः QtQuick / QML में) और एक C ++ सर्वर बैकएंड - जो शायद Qt सिग्नल / स्लॉट्स का उपयोग करेगा लेकिन कोई gui

— मार्टिन बेकेट

मैं सहमत हूँ। सबसे खराब। और यहां तक ​​कि विंडोज-केवल ऐप पर मैं एमएफसी मुद्दों की तुलना में क्यूटी मुद्दों पर डिबग करना चाहता हूं।

— वॉरेन पी

@WarrenP - हाँ, मैं MFC से लापता सभी सामानों के लिए कोडप्रोजेक्ट खोजने से नहीं चूकता। लेकिन MSFT के मूल कोड के नए प्यार के साथ - उन्होंने किसी भी आसान को लिखने के लिए बहुत कुछ नहीं किया है।

— मार्टिन बेकेट

Answer 8

कारण सरल है: इसमें सभी मुख्यधारा की भाषाओं के लिए अच्छी बाइंडिंग नहीं है, और यह जादुई रूप से हमेशा नौकरी के लिए उपयुक्त नहीं है ।

इस काम के लिए सही उपकरण का उपयोग करें। अगर मैं एक साधारण कमांड-लाइन एप्लिकेशन लिख रहा हूं, तो मैं इसे क्यूटी के साथ सिर्फ ब्लॉट क्यों करूंगा?

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

Comments

लेकिन Qt केवल कंसोल एप्लिकेशन लिखने की क्षमता प्रदान करता है। है ना?

— डेह्युमनाइजर

@Dehumanizer: मुझे कोई पता नहीं है। लेकिन मैं इसे एक छोटे उपयोगिता उपकरण के लिए क्यों इस्तेमाल करूंगा? जब मैं तुच्छता से सिर्फ मानक C ++ में आवेदन लिख सकता हूँ तो मुझे क्या लाभ होगा? ऐसा लगता है कि आप लाइब्रेरी का उपयोग करने के लिए एक कारण की तलाश कर रहे हैं , जो कि प्रोग्राम का बैकवर्ड तरीका है।

— ऑर्बिट

@Dehumanizer: जैसा कि मैंने कहा, यह एक पिछड़ा दृष्टिकोण है। जब आपको एक पुस्तकालय की आवश्यकता होती है, तो आपको पता चल जाएगा, और फिर आप जाकर कुछ आज़मा सकते हैं और देख सकते हैं कि आपकी ज़रूरत क्या है। जब आपके पास उपयोग का मामला न हो तो लाइब्रेरी पर राय इकट्ठा करने की कोशिश करना एक मूर्खता है।

— ऑर्बिट

"अगर मैं एक साधारण कमांड-लाइन एप्लिकेशन लिख रहा हूं, तो मैं क्यूटी के साथ सिर्फ उसी के लिए ब्लोट क्यों करूंगा" कम से कम एक बहुत ही प्रसिद्ध गैर-गिनी टूल क्यूटी में लिखा गया है - Doxygen :-)

— वैलेंटाइन हेनिट्ज

@Dehumanizer उदाहरण के लिए जब आपको फ़ाइलों, xml, यूनिकोड, json, regexp, concurency, डेटाबेस, आदि से निपटना पड़ता है, तो बहुत तेजी से, और 3 डी पार्टी लाइब्रेरीज़ को डाउनलोड, अपनाना, बनाए रखना नहीं चाहते हैं।

— वैलेंटाइन हेनित्ज

Answer 9

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

Answer 10

मैं मानता हूं कि Qt साथ काम करने के लिए एक अच्छा ढांचा है। फिर भी, मेरे पास इसके कई मुद्दे हैं:

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

उस ने कहा, मुझे तीव्र अनुप्रयोग प्रोटोटाइप या इन-हाउस अनुप्रयोगों के लिए PyQt का उपयोग करना पसंद है। सभी कोडिंग करने के लिए पायथन का उपयोग करना C ++ के साथ चिंताओं को कम करता है और वास्तव में Qt को बहुत ही सुखद स्थान बनाता है।

---

कुछ टिप्पणियों के जवाब में संपादित करें:

जब मैंने Q ++ के C ++ में लिखे जाने के बारे में लिखा था, तो मुझे स्वयं Qt के बारे में इतनी शिकायत नहीं थी, लेकिन यह जिस वातावरण में रहता है, उसके बारे में अधिक। यह सच है कि Qt अपने स्वयं के संसाधनों का प्रबंधन करता है, लेकिन आपके सभी GUI- संबंधित-लेकिन नहीं-क्यूटी कोड को C ++ में भी लिखा जाना है। वहां भी, Qt कई अच्छे उपकरण प्रदान करता है, लेकिन अंततः, आपको उस स्तर पर C ++ से निपटना होगा। Qt C ++ को बीरबल बनाता है, लेकिन यह अभी भी C ++ है।

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

Comments

1. क्यूटी अपने आप ही मेमोरी मैनेजमेंट की परवाह करता है, आपको प्रत्येक 'नए' के ​​बाद 'डिलीट' नहीं करना है। 1 क। C ++ निम्न स्तर की भाषा नहीं है, यह निम्न-स्तरीय 'क्षमताओं' वाली उच्च स्तरीय भाषा है। 3. मैं सहमत हूं, लेकिन Qt एक ही समय में QtDesigner के साथ और 'सादा कोड' के साथ एक UI बनाने के लिए प्रदान करता है। 4. फिर से सहमत हैं, लेकिन क्यूटी देशी एपीआई का उपयोग करने के लिए भी प्रदान करता है।

— डिहुमनाइजर

to your point nr 1. मुझे लगता है कि c ++ में अर्ध-स्वचालित मेमोरी प्रबंधन की तरह है: यदि आप स्मार्ट पॉइंटर्स जैसे std :: auto_ptr या boost :: share_ptr आदि का उपयोग करते हैं, तो आपको आमतौर पर मेमोरी को खाली करने की परवाह नहीं है। इस तरह के कंटेनरों को अन्य संसाधनों के लिए भी बनाया जा सकता है (फाइलें, सिस्टम संसाधन जिन्हें मुक्त किया जाना है)। RAII- पैटर्न का उपयोग मेमोरी प्रबंधन में बहुत मदद करता है और जैसे-जैसे यह आप में बढ़ता है, आपको वास्तव में मेमोरी के बारे में चिंता करने की ज़रूरत नहीं है।

— deo

"अकेले तथ्य यह है कि यह सी ++ है, हर क्यूटी प्रोग्रामर को अन्य भाषाओं में लिखे फ्रेमवर्क की तुलना में काफी कम उत्पादक बना देगा।" [उद्धरण वांछित]

— नाथन उस्मान

@ एसके-तर्क: जबकि मुझे लगता है कि मैं आपके तीसरे वाक्य के सभी शब्दों को समझता हूं, मुझे कोई मतलब नहीं है कि आप क्या कह रहे हैं। "अमूर्त टोपी का स्तर" क्या है? उस मामले के लिए, आपका पहला वाक्य गलत है, जिसे "निम्न-स्तरीय भाषा" की विकिपीडिया परिभाषा दी गई है।

— डेविड थॉर्नले

@ एसके-लॉजिक: टेम्प्लेट मेटाप्रोग्रामिंग ट्यूरिंग-पूर्ण है, और ऐसे लोग हैं जो इसका लाभ उठाने के लिए स्मार्ट और जानकार हैं। आरएआईआई महान कचरा संग्रह नहीं है, लेकिन यह तथ्य कि यह सभी प्रकार के संसाधनों के लिए काम करता है, कमोबेश उसी के लिए तैयार होता है। अब, विशेष रूप से, जावा में किस तरह का अमूर्त काम करता है, लेकिन सी ++ नहीं?

— डेविड थॉर्नले

Answer 11

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

अन्य अनुप्रयोगों में लाइसेंसिंग आवश्यकताएं होती हैं जो GPL, LGPL या Qt के वाणिज्यिक लाइसेंस के साथ अच्छा नहीं खेलती हैं। वाणिज्यिक सॉफ्टवेयर के लिए GPL अनुचित है। LGPL सांख्यिकीय रूप से जुड़े सॉफ्टवेयर के लिए अनुपयुक्त है और वाणिज्यिक लाइसेंस के लिए पैसे खर्च होते हैं - ऐसा कुछ जो भुगतान करने के लिए तैयार नहीं है।

कुछ के पास सुरक्षा या स्थिरता के विचार हैं जो क्यूटी जैसे जटिल पुस्तकालयों की अनुमति नहीं देते हैं।

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

कुछ लक्ष्य बहुत मेमोरी या सीपीयू के लिए विवश हैं।

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

यह केवल C ++ है। अन्य भाषा बाइंडिंग मौजूद हैं, लेकिन वे बहुत सारी कार्यक्षमता को छिपाने या खराब करने की प्रवृत्ति रखते हैं जो आप Qt के लिए चाहते हैं।

क्यूटी का उपयोग नहीं करने के कई कारण हैं, यही कारण है कि विकल्प हैं। अगर आपके पास एक हथौड़ा है तो हर समस्या नाखून की तरह दिखाई देगी।

Answer 12

सबसे महत्वपूर्ण लेकिन उल्लेखित बात नहीं। बड़ी परियोजना में एक चीज इतनी समस्याओं और गैर-जरूरी कोड का कारण बनती है। Qt का सिग्नल स्लॉट तंत्र अक्षम है। Qt विजेट्स ईवेंट सिंपल विजेट्स के लिए आवश्यक सिग्नल प्रदान नहीं करते हैं। उदाहरण के लिए आप onHover, onMouseEnter, onMouseLeave, onKeyReleased, onLostFocus, onGainFocus और आदि के लिए सिग्नल सेट नहीं कर सकते हैं। यहां तक ​​कि सबसे जटिल विजेट जैसे कि क्यूट्रीव्यूगेट एक या दो अल्ट्रा सरल बेकार सिग्नल प्रदान करता है।

हाँ, आप घटनाओं का उपयोग कर सकते हैं लेकिन !!! आपने कस्टम इवेंट के साथ प्रत्येक विजेट के लिए नई कक्षा बनाई है। यह बहुत बड़ी दक्षता खो गई है;

• आपके पास प्रत्येक अनुकूलित विजेट ऑब्जेक्ट घटना को फिर से लिखना है जिसमें छोटे परिवर्तन हैं।
• आप सभी Qt डिज़ाइनर सामान खो देते हैं। आपको प्रत्येक विजेट को कस्टम ईवेंट के साथ बढ़ावा देना होगा।
• प्रोजेक्ट बड़ा और बनाए रखना मुश्किल हो गया।
• आप क्यूटी को इस वजह से नापसंद करने लगे। और इस बारे में बात करना शुरू करना कि .net प्रतिनिधि कैसे प्रदान करता है, सिग्नल स्लॉट की तुलना में यह कितना अधिक बेहतर है, कैसे .net घटक (विजेट) आम तौर पर हर घटना प्रदान करता है जिसकी आप कल्पना कर सकते हैं। और आदि।

मेरे एक कॉलेज ने प्रत्येक कॉम्बो बॉक्स विजेट के लिए नया कॉम्बो बॉक्स क्लास लिखा है क्योंकि उसे कुछ नॉन सिग्नल इवेंट का उपयोग करना था। सच्ची कहानी...

हालाँकि, Qt, डाउन और अप के साथ अब तक का सबसे अच्छा C ++ UI फ्रेमवर्क है।

Comments

घटनाओं के बारे में और नई कक्षाएं बनाने के बारे में: आप उन कक्षाओं में ईवेंट फ़िल्टर का उपयोग कर सकते हैं जिनके लिए उन पर प्रतिक्रिया करना आवश्यक है।

— MrFox

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

— Петър Петров

Answer 13

मेरी अपनी राय पर, C ++ प्रोग्रामिंग सीखना अन्य भाषाओं में गिरने से आसान है जो अपनी जटिलता को छिपाते हैं, और प्रोग्रामर को यह नहीं पता है कि पृष्ठभूमि में वास्तव में क्या होता है। दूसरी ओर Qt, C ++ पर कुछ लाभ जोड़ता है, इसे मूल C ++ से उच्च स्तर बनाने के लिए। इस प्रकार क्यूटी सी ++ एक महान ढांचा है जो निम्न-स्तरीय कार्यों, या उच्च-स्तरीय लोगों को एक ही तरीके से विकसित करना चाहता है। C ++ एक जटिल और सरल भाषा है। जो इसे पसंद नहीं करना चाहता है, उसके लिए जटिल, जो इसे पसंद करता है उसके लिए सरल है। इसे जटिलता के लिए मत छोड़ो!

Answer 14

वास्तविक कारण तकनीकी नहीं है।

लोग अलग होते हैं। तो उनकी पसंद हैं। एकरूपता कोई मानवीय विशेषता नहीं है।

Comments

क्या इसीलिए सभी लोग अपने पैरों पर चलते हैं? ठीक है, जिनके पैर कम से कम हैं ...

— dtech