Megjegyzések
- Ez ' natív C ++. A legtöbb fejlesztő a magasabb szintű nyelveket részesíti előnyben, például a C # szót.
- A két élű, kompatibilis kard miatt a Qt sok anakronizmussal, javíthatatlan hibával és egyéb rossz viselkedéssel járt.
- @ user16764 : " A legtöbb "?
- Nem gondolom ' a TIOBE index valóban pontos mérőszám, mert a népszerűséget méri, nem pedig a felhasználást. A kód mennyiségének összehasonlítása olyan nyílt forráskódú tárházakban, mint a GitHub, Bitbucket, Codeplex és Sourceforge, pontosabb méréseket eredményezne. (És úgy gondolom, hogy ezek a pontosabb mérések a C és C ++ értékeket az 1. és a 2. helyre helyezik – a Java tisztességtelen előnyt élvez a TIOBE indexben, mert ' az elsőéves főiskolai tanfolyamoknál , és az új programozók több hangot adnak, mint a tapasztaltak)
- @Giorgio: Ööö, ilyen dolgokra gondolnia kell C # -ben. " fogalma, aki ennek birtokában van, " messze túlmutat " = “1e602625d8″>
". Az a tény, hogy az intelligens mutatók ezt a kifejezettet teszik, nem ' t egy nyelv meghibásodása; és ha nem ' nem gondolkodik ilyen dolgokon, akkor szemetet fog generálni bármely magas szintű nyelven, amelyet én ' láttam.
Válasz
Nem igazán szándékozom ezt lesújtó válasznak tekinteni, de ezek az okok nem használom személyesen a Qt-t. Rengeteg jó mondanivaló van róla – nevezetesen az, hogy az API legtöbbször működik, és hogy zökkenőmentesen áthidalja a platformokat. De én nem használom a Qt-t, mert:
- Bizonyos esetekben nem úgy néz ki, mint a natív programok. Ha egyetlen felhasználói felületet tervezünk minden platformra, akkor az eredetileg nem tűnik megfelelőnek, ha gépről gépre mozgatjuk, különféle vizuális stílusbeli okokból. Például Mac gépeken az osztott sávok általában viszonylag vastagok, a gombok pedig kicsik és lekerekítettek ikonokkal. A Windows gépeken az osztott sávok általában keskenyek, a gombok szövegesebbek és több négyzet alakúak. Az, hogy minden platformhoz egy felhasználói felületet írhat, még nem jelenti azt, hogy a legtöbb alkalmazáshoz ezt kellene tennie.
- A Qt nem csak linkelésre képes C ++ könyvtárak készlete. A használt építési rendszer megköveteli bizonyos fájlok lefordítását extra forrásfájlokká, ami a bonyolultabb bonyolultabbá teszi a többi könyvtárral összehasonlítva.
- A (2), C ++ IDE-k és eszközök eredményeként hibaként jelölheti meg a Qt kifejezéseket, mert nem értik a Qt sajátosságait. Ez szinte kényszeríti a QtCreator vagy egy csak szöveges szerkesztő használatát, például a
vim. - Qt nagy mennyiségű forrás, amelynek a fordítás előtt minden használt gépen jelen kell lennie és előre telepítenie kell. Ez sokkal fárasztóbbá teheti az építési környezet beállítását.
- Az alkatrészeket többnyire az LGPL engedélyezi, ami miatt nehéz egyszeres bináris telepítést használni, ha szigorúbb vagy kevésbé korlátozó licenc alapján kell kiadni.
- Rendkívül nagy lefordított bináris fájlokat hoz létre, összehasonlítva a hasonlóan írt " plain ol “natív alkalmazások " (kivéve természetesen a write alkalmazásokat tíz a KDE-hez).
Megjegyzések
- @Dehumanizer: Ott ' LGPL licenc, és ott ' s a kereskedelmi licenc. A kereskedelmi licenc dollár ezer dollár az engedélyes részéről, és nem engedélyezi az újraelosztást stb. Olyan liberális licencekkel rendelkező nyílt forráskódú projekteknél, mint a BSD, az MIT vagy a Boost, ahol a szerzők nem ' t rengeteg pénzt keresnek, és liberális licenc alapján szeretnék kiadni kódjukat, az LGPL-től való függőség ésszerűtlen, de a szóban forgó fejlesztők általában nem engedhetik meg maguknak a kereskedelmi engedélyeket.
- # 6 a legnagyobb miért kerülöm. Úgy értem, nem ' nem akarok nagy, ügyes programot, és nem szeretem, ha ' egy meghatározott licenchez kötődnék, de ' valóban hiányzik egy jó, natív megjelenés, amely ' számomra üzletkötő.Az OSX és a Windows legújabb verziói kifejezetten fantasztikus munkát végeztek abban, hogy natív interfészeik csinosak, gyorsak és működőképesek legyenek, és én ' inkább az összes munkát kihasználom, amit ' már megtettem helyettem; Azt tapasztalom, hogy sok natív megjelenés nélküli program számomra olcsónak és hackernek tűnik (nem mindig, de kissé elterjeszt).
- A 6-os számodnak az 1-esnek kellett volna lennie. Ezt írta messze a Qt legnagyobb problémája. Sok esetben egyszerűen nem használja a natív API-kat. Szeretem, ha a szoftverem natívnak tűnik. Az ilyen felhasználók is. ' még soha nem láttam Qt-vel létrehozott Mac-alkalmazást, amely Mac-alkalmazásnak tűnt volna. Nincs más Mac-felhasználó sem, és ' válogatósak az ilyesmiben. Minden előnyét elveszíti, ha " platformokon átívelő ", ha ' újra csak Linux-alkalmazások létrehozására használja, ami körülbelül az egyetlen hely, amely natívnak tűnik, mert valójában nincs semmi natív.
- kivéve az ' natív ' megjelenés már nincs meg. A Windows-alkalmazások régi konzisztenciája mára a WPF és a silverlight által kínált egyedi foltok, ragyogások és animációk szemétláda. Vessen egy pillantást az Office vagy a Windows 7 ' s Vezérlőpultra, hogy lássa, hogy az MS-ek zászlóshajó termékének manapság milyen következetlenségei vannak. Mac-felhasználók – nos, nagyon érvényes pontod van ott.
- @TrevorBoydSmith: Elnézést, de ' tévedsz. A Qt az egyetlen olyan keret, amely az előfeldolgozást használja. Időszak. Ellenőrizze a GNOME-ot, az FLTK-t, a WX-t és a barátait, és mutasson nekem egy előfeldolgozási lépést. Nem fogsz ' találni. Néhány más könyvtár eltérő felépítési rendszerrel rendelkezik, de a nap végén C ++ könyvtárak, amelyeket bármely C ++ fordító felépíthet. Ami az " nyers win32-t illeti, ami nem szerepel az okaimban ", az okaimban # 5 és # 6 néven szerepel.
Válasz
Ahogy az emberek mondják, minden eszköz illeszkedik az egyes problémákhoz és helyzetekhez …
De ha Ön C ++ programozó, akkor a Qt a keretrendszere. Nincs vetélytársa.
Komplex orvosi képalkotó alkalmazást fejlesztünk ki, és a Qt kitart.
Nem mondom, hogy a “hátrányok”, amelyeket az emberek mondanak róla, hamisak, de az az érzésem, hogy sokáig nem próbálták ki a Qt-t (minden új verziónál folyamatosan javul …) És főleg az összes általuk kommentált kérdés nem okoz gondot, ha vigyáz.
A felhasználói felület inkonzisztenciája: csak akkor, ha a felhasználói felület widgetjeit “olyanokként használja”, amelyekhez nincs testreszabás vagy egyedi rajzolás.
Qt az előfeldolgozó túlterhelése : Csak akkor, ha visszaél a jel-slot mechanizmussal vagy a QObject örökségével, amikor nincs igazán szükség.
Egyébként továbbra is C # .NET-be írunk alkalmazásokat, és sokáig csinálva. Tehát úgy gondolom, hogy van perspektívám.
Mint mondtam, minden eszköz minden helyzethez,
de a Qt kétségtelenül következetes és hasznos keretrendszer.
Megjegyzések
- +1 Thaks! Csak ugyanezt akartam írni. A leghülyeség a " nem nyílt forráskódú / kereskedelmi érv ". Megdöbbentő, mennyire tévesen értik az Open-Source kifejezést. A Qt nyílt forráskódú volt, mivel használom (1.4). És régen a legtisztességesebb licenccel rendelkezett: pénzt keres Qt – > fizetéssel.
- Ja és tényleg nem ' t VIGYÁZZA a 10 MB-os DLL-ek hozzáadását olyan alkalmazásokhoz, amelyek 50 MB művészeti elemet, valamint további 200 MB-os video oktatóanyagokat és adatokat tartalmaznak.
- A Qt-hez szükséges hely manapság olcsó.
- Ez nagyjából megfelel a Qt-vel kapcsolatos tapasztalataimnak (a widgetek keretrendszere, eddig nem használtam a QML / QtQuick-ot semmi komoly dologhoz). Alkalmas nagy alkalmazások írására, összetett felhasználói felület követelményekkel. Miután megtanulta, nagyon produktív lehet. Az említett hátrányok (külön fordítási lépés a mocinghoz, ui fájlok stb.) Nem jelentenek problémát, ha a build rendszer megfelelően van beállítva. Vagy a qmake-et, vagy a cmake-et tudom ajánlani.
- Utána az 5.8-as Qt-ból van egy Qt Lite nevű projekt, amely minimalizálja a Qt-t az Ön speciális igényeinek megfelelően. ez egy kereskedelmi szolgáltatás;)
Válasz
Azokból a dolgokból, amelyek nem tetszenek a Qt-ben, az a tény, hogy nem játszik jól a sablonokkal, engem hibázik a legjobban. Ezt nem lehet megtenni:
template < typename T > struct templated_widget : QWidget { Q_OBJECT; public signals: void something_happened(T); }; Nem is játszik jól az előprocesszorral. Ezt nem lehet megtenni:
#define CREATE_WIDGET(name,type) \ struct name ## _widget : QWidget \ { \ Q_OBJECT; \ \ public signals: \ void something_happened(type); \ } Ez, vegyítve azzal a ténnyel, hogy mindannak, ami egy jelre reagál, Q_OBJECT-nek kell lennie, megnehezíti a Qt munkáját A Java vagy Python stílusú programozáshoz szokott emberek valójában jobbak.
Valójában sok időt és erőfeszítést töltöttem el, hogy kutassam és megtervezzem a módját annak, hogy visszanyerjem a típusbiztonságot, és Qt jelet kössek bármilyen functor objektumhoz: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals-in-qt-step-1.html
Az a fajta dolog, amit ott szeretnék csinálni, az az alapvető, mindennapi C ++ fejlesztés, amelyet a Qt moc szinte lehetetlenné tett … ami maga is napjainkban teljesen felesleges, ha valaha is az volt.
Őszintén szólva azért ragaszkodtam hozzá, mert ha automatizált felhasználói felület tesztelést szeretne végezni, akkor a Qt nagyjából az egyetlen játék a városban, MFC nélkül. ..mi olyan 1980 (nagyon szívósan dolgozik ebben a szarban). Néhányan mondhatják, hogy WX, de még súlyosabb problémákat okoz. A GTKmm lett volna az első választásom, de mivel az összes tulajdonos rajzolja és nem teszi hozzáférhetővé … nem vezérelheti az iparági szabvány tesztelő szoftver. A Qt ebben a tekintetben elég nehéz ( alig akkor működik, amikor módosítja az akadálymentességet segítő bővítményt.)
Megjegyzések
- Érdeklődés nélkül mit lát a WX fő problémájaként?
- @Tom – gyenge dokumentáció, főleg az új anyagokra vonatkozóan. Az AUI-alkatrészek egyáltalán alig vannak dokumentálva, nagy részek hiányoznak, ami megnehezíti a felhasználást termelési környezetben. Az eseményfolyamat dokumentációja alapvetően hibás a követett út tekintetében legalább a win32-en. Sok időt töltött a számítógépen való kiabálással, " Ennek működnie kellene !!! " mielőtt belemennék a mély feldolgozási kódba, hogy megtudja, hogy amit a WX csinál, az nem ' követi a dokumentumokat, és amit én csináltam, SOHA nem fog működni.
- voltam zavarta az ingatlan rácskönyvtár fővonalba történő befogadása is. Ezt a könyvtárat használtam, és számos alapvető tervezési hibát mutatott ki az ismeret hiánya mellett a programozó nevében, aki megírta (például a konstruktorokban virtuális függvényeknek hívták). Ez és az AUI rossz állapota a gyengébb színvonalú tendenciát mutatta. Én ' szintén nem vagyok nagy rajongója a statikus eseménytábláknak, bár legalább van ' egy másik módja az eseményekre reagálásnak … ellentétben az MFC-vel, amely a WX egyébként is túlságosan szereti izgalmas lenni.
- Köszönöm. <
csak egy kicsit használtam, és a wxPython API-n keresztül, ahol nagyon szépnek tűnt. Nagyra értékelem, hogy ez elrejtené a gonoszságot, de azt is, hogy éppen nem voltam olyan mélyen érintett, hogy a komolyabb problémákkal szembesülhessek. Valamit tudatában kell lennem.
Válasz
A Qt használatának egyik oka az, hogy ha csak egy architektúrához írsz, például Windowshoz, akkor érdemes használni a C # /. NET-et (vagy Mac-en a Cocoa-t), mert azok mindig képes legyen kihasználni az operációs rendszer legújabb harangjait és sípjait.
Ha több platformon futó alkalmazásokat ír, akkor valószínűleg már erősen át van ruházva egy másik technológiával, például a Java-val (azaz „Java Shopban” dolgozik). A választott technológiát az ökoszisztéma szabhatja meg, amelyben fejleszt, például a nyelvspecifikus API-k. Ilyen esetekben előnyös lehet a technológiák számának minimalizálása.
A harmadik ok, amire gondolni tudok, az az, hogy a Qt a C ++ körüli alapú, a C ++ pedig viszonylag nehéz / veszélyes nyelv programozni Azt hiszem, ez egy nyelv a szakemberek számára. Ha csúcsteljesítményre van szükséged, és képesek vagányak lenni, akkor a C ++ valószínűleg még mindig a legjobb játék a városban. Valójában a Qt sok memóriakezelési problémát enyhít, ha úgy állítja be, hogy a dolgok kívül esjenek. Ezenkívül a Qt maga is jó munkát végez, és elszigeteli a felhasználót a csúnya C ++ problémáktól. Minden nyelvnek és keretrendszernek megvannak az előnyei és hátrányai. Ez egy nagyon-nagyon bonyolult kérdés, amelyet általában összefoglalhatunk az étkezőknél gyakran előforduló adalékokkal: sebesség, minőség és ár (de csak kettőt választhat).
Bár a szabályok szerint meg kell tartanom a kérdés megválaszolására összpontosítva, meg akarom cáfolni néhány kérdést, amelyet Billy ONeal vetett fel, aki szerintem jó munkát végez, összefoglalva a Qt használatának leggyakrabban idézett okait:
-
A Qt valóban egy C ++ könyvtár / keret / fejléc fájl. kibővíti egy makroprocesszor (moc), amely lehetővé teszi többek között a jeleket és a réseket. Átalakítja a további makroparancsokat (például Q_OBJECT), így az osztályok önvizsgálattal és mindenféle egyéb finomsággal rendelkeznek, amelyekről azt gondolhatja, hogy az Objective-C funkcionalitást adja hozzá a C ++ -hoz. Ha elég sokat tud a C ++ -ról, hogy megsértődjön ez a tisztasághiány, azaz.profi vagy, akkor 1) ne használd a Q_OBJECT-et és hasonlatait, vagy 2) légy hálás, hogy ezt megteszi, és programozz a nagyon korlátozott sarkok körül, ahol ez problémát okoz. Azok számára, akik azt mondják, hogy “Jelzéshez használja a Boost slots! “, akkor visszavágnám, hogy az egyik” problémát “kicseréli egy másikra. A Boost hatalmas, és megvannak a maga által gyakran emlegetett kérdései, például a gyenge dokumentáció, az iszonyatos API és a platformokon átívelő borzalmak 3.3 és olyan nagy vas-fordítók, mint az AIX).
-
A szerkesztő támogatásához ez az 1-ből is következik, kissé egyetértek. Valójában a Qt Creator az IMHO a legjobb grafikus C ++ szerkesztő, időszak , még akkor is, ha nem használja a Qt dolgokat. Sok profi programozó használja az emacs és a vim programokat. Ezenkívül úgy gondolom, hogy az Eclipse kezeli a további szintaxist. Így nincs probléma a Qt makrókkal (Q_OBJECT) vagy a jelek / bővítőhelyek hozzáadásával. Valószínűleg nem fogja megtalálni ezeket a makrókat a Visual Studio-ban, mert (elismerem) ezek a C ++ kiegészítései. Nagyjából azonban a C # /. A NET-emberek amúgy sem fogják használni a Qt-t, annak a ténynek köszönhető, hogy sok saját funkcionalitásuk van lefedve saját, saját tulajdonú technikájukkal.
-
Ami a Qt forrás méretét illeti, mindaddig, amíg egyik napról a másikra összeáll, kit érdekel? A Qt 4-et kétmagos Macbookomon “kevesebb, mint egyik napról a másikra” állítottam össze. Remélem, hogy remélem, hogy nem ez ösztönzi döntését használjon vagy ne használjon egy adott technológiát. Ha ez valóban probléma, akkor letöltheti az előre lefordított Mac, Linux és Windows SDK-kat a Qt webhelyről.
-
A licencelés háromféle választási lehetőség áll rendelkezésre: 1) Saját tulajdonú licenc abban az esetben, ha módosítani akarja a Qt ITSELF t, és nem osztja meg, vagy elrejti azt a tényt, hogy valaki Qt-t használ, és nem hajlandó megadni hozzárendelést (a márkaépítés szempontjából nagyon fontos lehet) és kép!) 2) GPL és 3) LGPL. Igen, vannak problémák a statikus összekapcsolással (az egész Qt binárisba forgatása) – de szerintem ez inkább azért van, mert nem lehet belenézni és észrevenni, hogy ön u énekelje Qt (hozzárendelés!). Megpróbáltam megvásárolni egy saját licencet a Digiától, és azt mondták nekem, “amire te vagy, arra valóban nincs szükséged.” Wow. Olyan vállalkozástól, aki licencek eladásával foglalkozik.
-
A bináris / csomag mérete azért van, mert el kell terjesztenie a Qt tartalmat azoknak az embereknek, akiknek nincs: A Windows már rendelkezik? a Visual Studio cuccait, vagy telepítenie kell a futási időt. A Mac már a hatalmas kakaóval érkezik, és dinamikusan összekapcsolható. Habár nem sok terjesztést végzek, még soha nem találtam sok problémát az ~ 50 megabájtos statikus fájl terjesztésével (amelyet még kisebbre tehetek néhány bináris sztriptíz / tömörítő segédprogrammal, például az UPX-szel). elég gondos ehhez, de ha valaha is probléma lenne a sávszélességgel, akkor hozzáadnék egy UPX lépést a build szkriptemhez.
-
Mi határozza meg a “natív megjelenést és érzetet”? Azt hiszem, “a legtöbb” egyetértene abban, hogy a Mac áll a legközelebb az egységes megjelenéshez. De itt ülök, nézegetem a Safarit, az iTunes-ot, az Aperture-t, a Final Cut Pro-t, a Pages-et stb., És semmiben sem hasonlítanak annak ellenére, hogy az operációs rendszer gyártója gyártotta őket. Úgy gondolom, hogy az “érzés” szempont relevánsabb: widget stílus, reagálóképesség stb. Ha érdekel a válaszkészség, akkor itt van egy jó ok arra, hogy a C ++ szót használja a Java helyett, vagy valamilyen más rendkívül dinamikus nyelvet. (A C célkitűzés is ringat, de megpróbálom eloszlatni a Qt-ról szóló mítoszokat)
Összefoglalva: ez egy bonyolult kérdés. De szeretném felhívni a figyelmet arra, hogy szerintem kevesebb oka van a “Qt nem” használatának, mint azt a mítoszok és az évtizedek óta elavult információk alapján gondolhatnánk.
Kommentárok
- Amit nem kapok ', ezért ezek a platformokon átívelő könyvtárak nem ' egyszerűen burkoló funkciók , vagy még jobb; ha def-ek vannak a Cocoa, Win32, KDE / Gnome körül, biztosítva a legkiválóbb felhasználói felületet, az összes funkcióval. ' s funkciókkal.
- @MarcusJ Burkoló írása az egyik eszköztár egyértelműen nem triviális, ne felejtse el a 4-et vagy annál többet – de ha úgy gondolja, hogy ' ennyire könnyű, akkor ' üdvözöljük megpróbálni. Ami azt az elképzelést illeti, hogy ezt csak feltételes előfeldolgozással lehet elérni … viccelned kell, igaz?
- @MarcusJ libui pontosan ezt (bár KDE támogatás nélkül).
- Szeretném hozzáfűzni, hogy most már használhatja a Qt / QML-t a .NET-mel. Nem szükséges, hogy ' megérintse a C ++ elemet. github.com/qmlnet/qmlnet PS: Én ' írtam a szerzőt.
Válasz
Ennek egy része licencelés. A licencelési előzmények egy részét lásd: https://en.wikipedia.org/wiki/Qt_(software) #Licensing . 2000-ig azok az emberek, akik nagyon törődtek a nyílt forráskóddal, nem használták a Qt-t. Időszak. (Valójában ez volt az eredeti motiváció a Gnome fejlesztésére.) 2005-ig azok az emberek, akik ingyenes szoftvereket akartak kiadni a Windows számára, nem használták a Qt-t.Még azok után is, akik ingyenes szoftvert akartak a GPL kivételével, egyszerűen nem volt lehetőségük használni a Qt-t. Így minden, az említett dátumnál régebbi ingyenes szoftver projekt nem használhatja a Qt-t. És természetesen a saját kódot íróknak fizetniük kellett a privilégiumért.
Továbbá nem mintha létezne nincs más lehetőség. Például: WxWidgets , GTK + és Tk mind nyílt forráskódú, platformokon átívelő eszközkészletek.
Ezenkívül a Windows sokáig annyira domináns volt az asztalon, hogy sok szoftver csak tartalomként működött Windows rendszeren. Ha telepíti a Microsoft eszköztárat, akkor egyszerűbb a Microsoft saját tartalmát használni, mint bármi más miatt aggódni, és sok programozó éppen ezt tette.
Megjegyzések
- @btilly: A GTK + több platformon fut. Például a Pidgin IM kliens a GTK + -ra van írva.
- Ok, azonban lehetséges ' valahogy ' a Windows rendszeren való futtatáshoz 🙂
- Csak telepítse a GIMP-t a Windows-ra, és nézzen utána.
- Igen, és a GIMP jól működik Windows rendszeren, de természetesen nem ' nem illeszkedik a Windows 7 felhasználói felület megjelenésébe &.
- A Pidgin valószínűleg jobb példa a GTK-ra Windows rendszeren. Nem csinál ' semmi fantáziát, de belefér és talán 10 évig vagy tovább?
Válasz
Egyetértek a fentiekben ismertetett okok szinte mindegyikével, azonban itt sokan azt mondták, hogy a Qt-t nem fogják használni a vele járó többletköltségek miatt. Nem értek egyet ezzel, mert manapság az összes legelterjedtebb nyelv (Java, C # és Python) meglehetősen sok rezsit hordoz magában.
Másodszor, a Qt a C ++ programozását olyan könnyűvé és egyszerűvé teszi, hogy kiegyenlíti a extra erőforrásokat használ. Sok egyszerű Qt-ben írt konzolalkalmazással találkoztam, nem pedig a standard C ++ – val, a könnyű írhatóságuk miatt.
Azt mondanám, hogy a Qt produktivitása nagyobb, mint a C / C ++, de kevesebb, mint a Pythoné.
Megjegyzések
- Feltételezem, hogy ' mindez az egyéni ' tapasztalathoz viszonyul, mert a C ++ 14-ben kódolhatok OK, de minden alkalommal, amikor valamilyen Qt-kódra pillantok, erősen hunyorítanom kell, hogy azonos nyelvként ismerjem fel … szóval biztosan nem ' nem gondolom, hogy ' s az egyhangú termelékenységnövelő, amelyet ' itt megemlít.
- @underscore_d nyilvánvalóan, ha nagyon jól ismeri a C ++ -ot, és nem ' t Qt, ez utóbbival nem leszel produktívabb. De amikor megismered a C ++ -ot és a Qt-t is, a keretrendszer valóban sok mindent megkönnyít és gyorsabban megvalósít (a C ++ 11, 14 stb. Kitöltik a hiányt, de még nem teljesen).
Válasz
Ez valóban nem kísérlet a lángháború megindítására, csak néhány kérdéssel szerettem volna foglalkozni.
Valószínűleg az az oka, hogy a Qt nincs szélesebb körben használva, hogy C ++ és kevesebb ember használja a c ++ -t asztali alkalmazásokhoz.
A Qt nem C ++ könyvtár. Külön fordítási lépést igényel, ami a bonyolultabb bonyolultságot teszi a többi könyvtárhoz képest.
A vs-addin for visual studio ezt automatikusan megcsinálja, csakúgy, mint a Qt saját parancssori készítési folyamata. Az MFC párbeszédablakainak elkészítéséhez használt erőforrás-fordító szintén külön lépés, de ez még mindig c ++.
A Qt nagy mennyiségű forrás, amely a fordítás előtt minden használatban lévő gépen jelen kell lennie, és előre telepítenie kell. Ez sokkal unalmasabbá teheti az építési környezet beállítását.
Van egy bináris letöltés A vizuális stúdió és a forrásból történő összeállítás minden verziója egyetlen parancs. Nem látom, hogy az SDK forrásmérete manapság annyira sok dolog. A Visual Studio mostantól az összes C ++ lib-et telepíti, ahelyett, hogy hagyná a választást, ennek eredményeként a fordító telepítési mérete> 1 GB.
It ” s csak az LGPL alatt érhetők el, ami megnehezíti az egy bináris telepítés használatát, ha szigorúbb vagy kevésbé korlátozó licenc alapján kell kiadni.
Az LGPL csak a lib-re vonatkozik, nem befolyásolja a kódodat. Igen, ez azt jelenti, hogy egyetlen bináris fájl helyett DLL-eket kell szállítania (hacsak nem fizet), de egy olyan világban, ahol le kell töltenie egy Java futásidőt vagy .Net frissítést egy apró felhasználásért, ez nem olyan nagy dolog. “kevesebb probléma az egyetlen ABI-t használó platformokon is, így más Qt-alkalmazások megoszthatják a lib-eket.
Bizonyos esetekben egyszerűen nem” Úgy néz ki, mint a natív programok.Az összes felhasználói felület egyetlen felhasználói felületének megtervezése eredetileg nem tűnik megfelelőnek, ha gépről gépre helyezzük, különféle vizuális stílusú okokból.
Ez feltételezhető natív widgetek és témák használatához. El kell ismernem, hogy főleg technikai alkalmazásokat használok, így a felhasználóim nem aggódnak a stílus miatt. Különösen a windowson az az új divat, hogy minden okostelefon-widgetként stílusos, azt jelenti, hogy amúgy is egyre kevesebb a szabvány.
Megjegyzések
- Elég sok nagy szoftvergyártó cég épít kereskedelmi alkalmazásokat C ++ nyelven, de én ' nem ismerek sok olyan személyt, akik QT-t használnak. Tehát, bár megértem, hogy a nem C ++ fejlesztők elkerülhetik a QT-t, más okok is vannak a QT elkerülésére, még akkor is, ha C ++ alkalmazást írsz, úgy tűnik. Valójában nincs ' t olyan cross-platform nyelv és GUI eszköztár, amelyben ' nem találnék hibát. Úgy tűnik, hogy a platformok közötti fejlesztés CSAK JELENLEG KEMÉNYES, és hogy ezt jól megcsinálni soha nem könnyű vagy ingyenes, és hogy a QT ígérete (Írja le egyszer a GUI-t, és mindenhol használja újra ezt a GUI-t) / div> t elég.
- A legtöbb asztali C ++ szoftver vagy MFC-ben van, mert 20 évvel ezelőtt indult, vagy egy 20 évvel ezelőtt indított belső eszköztárat használ az MFC elkerülésére (pl. MS-Office vagy Autocad). Kétlem, hogy nagyon sokat írnak C ++ / CLR-ben WPF-fel. De a platformok közötti megfontolások nélkül is a Qt-t találom a legjobb (vagy legkevésbé a legrosszabb!) Asztali eszközkészletnek. A legtöbb emberhez hasonlóan mi is egy webes kezelőfelület (esetleg QtQuick / QML formátumban) és egy C ++ szerver háttérprogram felé haladunk – amelyek valószínűleg Qt jeleket / slotokat fognak használni, de guit nem.
- Egyetértek. Legrosszabb. És csak a Windows rendszerű alkalmazásokban is ' inkább a QT problémákat, mint az MFC problémákat keresem.
- @WarrenP – igen, nem ' ne hagyja ki az MFC-ből hiányzó összes anyag keresését. De az MSFT ' újfajta megtalált szeretetével a natív kód iránt – ők nem tettek sokat azért, hogy könnyebben megírják a guit.
Válasz
Az ok egyszerű: nem rendelkezik jó kötéssel az összes mainstream nyelvhez, és nem varázslatos mindig megfelelő az adott munkához.
Használja a munkához megfelelő eszközt. Ha egyszerű parancssori alkalmazást írok, miért duzzasztanám fel ezt a Qt-vel csak azért, hogy kedvéért tegyem?
Általánosabb válaszként (amit megadhatok, mert itt releváns vagyok) ), néhány programozó egyszerűen soha nem engedte meg, és úgy döntött, hogy használja. Bizonyos esetekben nincs különösebb ok, kivéve, ha a programozó soha nem talált rá igényt és utánanézett.
Megjegyzések
- De a Qt biztosítja csak konzolos alkalmazások írásának képessége. Nem ' ez?
- @Dehumanizer: Fogalmam sincs. De miért használnám egy kis segédprogramhoz? Milyen előnyökkel járna ez számomra, amikor triviálisan meg tudom írni az alkalmazást csak szabványos C ++ nyelven? Úgy tűnik, hogy ' újra okot keres a könyvtár használatára, ami visszafelé történő programozási mód.
- @Dehumanizer: As Azt mondtam, hogy ' hátrafelé irányul. Amikor szükség van egy könyvtárra, ' tudni fogja, majd elmehet és kipróbálhat néhányat, és megnézheti, mi felel meg jobban az igényeinek. Bolond ' s, ha megpróbál véleményt gyűjteni egy könyvtárról, ha nincs ' nincs használati esete . megbízás.
- " Ha ' m egyszerű parancssori alkalmazást írok, miért duzzasztanám fel ezt a Qt-vel csak a kedvéért " van legalább egy nagyon híres nem gui eszköz, amely Qt-be van írva – Doxygen 🙂
- Például @Dehumanizer amikor fájlokkal kell foglalkoznod, xml, unicode, json, regexp, konkurencia, adatbázisok stb., stb., nagyon gyorsan, és ne ' ne akarj tucat 3.-at letölteni, elfogadni, fenntartani. pártkönyvtárak.
Válasz
A Qt-hez hasonló keretrendszerek megfelelőek, ha jobban érdekli a termék keresése ugyanazok minden platformon, mint amikor terméke jobbra néz minden platformon. Manapság egyre gyakrabban lépnek át az ilyen típusú alkalmazások a webalapú technológiákra.
Válasz
saját véleményem szerint a C ++ programozás megtanulása egyszerűbb, mint más, összetettségüket elrejtő nyelvekre esni, és a programozó nem tudja, mi valóban a háttérben történik. A Qt viszont bizonyos előnyökkel jár a C ++ -val szemben, hogy magasabb szintre emelje, mint a natív C ++. Így a Qt C ++ nagyszerű keretrendszer azok számára, akik alacsony szintű vagy magas szintű feladatokat akarnak azonos módon kidolgozni. A C ++ (egyes gyakorlatok szerint) összetett és egyszerű nyelv. Komplex, aki nem akar vele kihívást jelenteni, egyszerű annak, aki szereti.Ne hagyja bonyolultabbá!
Válasz
Egyetértek azzal, hogy a Qt egy szép keretrendszer, amellyel együtt lehet dolgozni. Ennek ellenére számos kérdésem van vele:
- C ++ nyelven íródott, ami egy nagyon alacsony szintű nyelv. Önmagában az a tény, hogy C ++, minden Qt programozót lényegesen kevésbé produktívvá tesz a más nyelveken írt keretrendszerekhez képest. A legfontosabb marhahúsom C ++ -val, mint GUI fejlesztési nyelvvel, az, hogy nincs fogalma az automatikus memóriakezelésről, ami sokkal hajlamosabbá teszi a hibákat. Ez nem önvizsgálat, ami sokkal megnehezíti a hibakeresést. A többi jelentős grafikus felhasználói felület eszköztár nagy részében van némi fogalom az automatikus memóriakezelésről és az önellenőrzésről.
- Minden platformon átívelő eszköztár abban a problémában szenved, hogy csak az összes támogatott platform legkevesebb közös nevezőjét képes megvalósítani. Ez és a különböző platformokon található különböző felhasználói felület-irányelvek nagyon megkérdőjelezik a cross-platform GUI-k egészének kívánatosságát.
- A Qt nagyon az összes felhasználói felület kódolására összpontosít. Annak ellenére, hogy használhatja a QtDesigner programot a kezelőfelület egyes részeinek felépítéséhez, ez komolyan hiányzik például a (Cocoa / Obj-C) interfészkészítőhöz vagy a .Net eszközökhöz képest.
- Annak ellenére, hogy a Qt nagyon sok alacsony szintű alkalmazásfunkciót tartalmaz, nem hasonlítható össze azzal, hogy egy keretrendszert kézzel szabtak egy bizonyos platformra. A natív operációs rendszer könyvtárak mind a Windows, mind az OSX számára lényegesen erőteljesebbek, mint a Qt implementációi. (Gondoljunk az audiokeretekre, az alacsony szintű fájlrendszerhez való hozzáférésre stb.)
Ennek ellenére szeretem használni PyQt gyors prototípus-készítéshez vagy házon belüli alkalmazásokhoz. A Python használata az összes kódoláshoz enyhíti a C ++ problémáit, és valójában a Qt-t nagyon kellemes hellyé teszi.
Szerkesztés, válaszként néhány megjegyzésre:
Amikor arról írtam, hogy a Qt C ++ nyelven írják, nem annyira a Qt-re panaszkodtam , de többet arról a környezetről, amelyben él. Igaz, hogy a Qt nagyon jól kezeli a saját erőforrásait, de az összes GUI-val kapcsolatos, de nem Qt kódot C ++ nyelven is meg kell írni. Még ott is a Qt sok szép eszközök, de végső soron a C ++ -val kell ezen a szinten foglalkoznia. A Qt elviselhetővé teszi a C ++ -ot, de még mindig C ++.
Ami az önellenőrzést illeti, a következőre gondolok: A legnehezebb hibakeresés amikor te legyen mutatója valamilyen tárgyra, amely nem úgy viselkedik, ahogy gondolja. A C ++ használatával a hibakereső képes lehet kissé belenézni az objektumba (ha véletlenül a típusinformációk vannak a tht ponton), de még ez sem mindig működik. Vegyük viszont a kakaót ugyanabban a helyzetben. A Cocoa / Obj-C rendszerben üzeneteket (“hívásfunkciók”) küldhet egy objektumnak közvetlenül a hibakeresőben. Megváltoztathatja az objektumok állapotát, lekérdezheti az attribútumait, kérheti típust és függvényneveket … Ez sokkal kényelmesebbé teheti a hibakeresést. A Qt / C ++ -nak ehhez még nincs semmi köze.
Megjegyzések
- 1. A Qt önmagában törődik a memóriakezeléssel, nem kell minden '
new '. 1a. A C ++ NEM alacsony szintű nyelv, hanem magas szintű nyelv, alacsony szintű ' képességekkel '. 3. Egyetértek, de a Qt rendelkezik egy felhasználói felület létrehozásával a QtDesigner és ' egyszerű kóddal ' egyidejűleg. 4. Ismételten állapodj meg, de a Qt előírja a natív API-k használatát is. - az 1. pontodig. Azt hiszem, a c ++ -nak van egyfajta félautomata memóriakezelése: ha olyan intelligens mutatókat használ, mint az vagy boost :: shared_ptr stb., általában nem kell törődnöd a memória felszabadításával. Ilyen típusú tárolók készíthetők más erőforrásokhoz is (fájlok, rendszererőforrások, amelyeket fel kell szabadítani). A RAII-minta használata nagyon sokat segít a memóriakezelésben, és ahogy beléd nő, nem igazán kell aggódnod a memória miatt.
- " A tény önmagában a C ++ minden Qt programozót lényegesen kevésbé produktívvá tesz a más nyelveken írt keretrendszerekhez képest. " [idézet szükséges]
- @ SK-logic: Bár szerintem Értem a harmadik mondatod összes szavát, fogalmam sincs, mit mondasz. Mi az " absztrakciós korlát " szintje? Ezzel kapcsolatban az első mondatod hamis, figyelembe véve a Wikipedia " alacsony szintű nyelv " definícióját.
- @ SK-logic: A sablon metaprogramozása Turing-teljes, és vannak olyan emberek, akik elég okosak és hozzáértők ahhoz, hogy ezt kihasználják. A RAII nem ' nem nagy szemétszállítás, de az a tény, hogy mindenféle erőforrásnál működik, nagyjából kompenzálja ezt.Pontosabban, milyen absztrakció működik a Java-ban, de a C ++ nem?
Válasz
A legfontosabb, de nem említett dolog. Nagy projektben egy dolog sok problémát és nem szükséges kódot okoz. A Qt jelhely-mechanizmusai hatástalanok. A Qt-kütyü nem biztosítja a szükséges jeleket az egyszerű esemény-widgetekhez. Például nem állíthat be jeleket az onHover, onMouseEnter, onMouseLeave, onKeyReleased, onLostFocus, onGainFocus stb. A QTreeWidget egy vagy két rendkívül egyszerű haszontalan jelet szolgáltat.
Igen, használhatja az eseményeket, DE !!! új osztályt hozott létre minden egyes widgethez egyéni eseményekkel. Ez hatalmas hatékonyságot veszített el;
- Minden testreszabott widget-objektum eseményt átírt, kisebb változások vannak.
- Minden Qt Designer anyagot elveszít. Minden widgetet egyedi eseményekkel kell népszerűsítenie.
- A projekt nagyobbá vált és nehezen karbantartható.
- Emiatt kezdte nem szeretni a qt-t. És arról kezdett beszélni, hogy a .net miként biztosítja a küldötteket, hogyan sokkal jobb, mint a jelhely, hogyan .net A komponensek (widgetek) általában minden eseményt biztosítanak, amit csak elképzelhetsz. És stb.
Az egyik egyetemem írt új kombinációs doboz osztályt készített minden egyes kombinációs doboz widgethez, mert valamilyen nem szignál eseményt kellett használnia. Igaz történet …
Azonban a Qt a legjobb C ++ felhasználói felület keretrendszer, lejtőkkel és emelkedésekkel.
Hozzászólások
- Az eseményekkel és új osztályok létrehozásával kapcsolatban: használhat eseményszűrőket olyan osztályokban, amelyeknek reagálniuk kell rájuk.
- " Igen, használhatja az eseményeket, DE !! ! minden osztályhoz új osztályt hozott létre egyedi eseményekkel. Ez hatalmas hatékonyságvesztés; " – NEM PONTOSAN. Végül a bool eventFilter-rel foglalkozom, amely több widgetet kezel, majd az összes gyermek-widgetre telepíti azEventFilter (ezt). És ez nem ' nem veszíti el a hatékonyságot és a programozási teljesítményt! Valójában soha nem használok " Promotált widgeteket " … Csak egy üres widgetet dobok le, ezt telepítem eventFilter-ként, és újratelepítem a legtöbbet eseményeim a fő cpp osztályomon belül. Próbáld ki, nem okozott ' t fájdalom 🙂 A Qt-ben szinte MINDENT személyre szabhatsz anélkül, hogy bármikor új osztályokat hoznál létre
Válasz
Nagyon szeretem a Qt-t, de ez sok alkalmazáshoz kissé nehézsúlyú. Néha nem csak erre a bonyolultságra van szükség. Néha csak valami egyszerűre van szükséged, anélkül, hogy a Qt teljes költsége lenne. Nem minden alkalmazásnak kell eseményvezéreltnek lennie, és a C ++ ésszerű sablonkészletet biztosít. A Boost egy másik nagyon jó készletet tartalmaz, és sok olyan alacsony szintű funkciót (fájlt, socketet, felügyelt mutatókat stb.) Tartalmaz, mint a QT.
Más alkalmazások licencelési követelményekkel rendelkeznek, amelyek nem játszanak jól a GPL-vel. , LGPL vagy Qt kereskedelmi engedélye. A GPL nem megfelelő a kereskedelmi szoftverekhez. Az LGPL nem megfelelő a statikusan összekapcsolt szoftverekhez, és a kereskedelmi licenc pénzbe kerül – amit sokan nem hajlandók fizetni.
Egyesek biztonsági vagy stabilitási megfontolásokat vetnek fel, amelyek nem teszik lehetővé olyan összetett könyvtárak használatát, mint a Qt.
A források előzetes feldolgozásához futtatnia kell az moc szoftvert. Ez nem óriási probléma, de ijesztő lehet az új felhasználó számára. Sok programozó úgy gondolja, hogy kell használnia a qmake-et a Qt-vel, de ez helytelen elnevezés. A Qt-t meglehetősen könnyen lehet beépíteni más build rendszerekbe.
Néhány célpont nagyon a memória vagy a CPU korlátozott.
Van néhány platformspecifikus gotcha benne. A legtöbb getcha nincs dokumentálva. Készítsen egy kellően nagy alkalmazást, és belefutsz, és kíváncsi leszel, mi folyik itt (felelősség kizárása, utoljára több mint 18 hónappal ezelőtt használtam haragban a Qt-t, ezért javulhatott).
Csak C ++. Más nyelvi kötések léteznek, de általában elrejtik vagy rosszul teszik ki a olyan funkcionalitás, amelyhez Qt szeretne.
Sok oka van annak, hogy ne használja a Qt-t, ezért vannak alternatívák. Ha csak egy kalapács van, akkor minden probléma körömnek fog kinézni.
Megjegyzések
- " Az LGPL nem megfelelő a statikusan összekapcsolt [zárt forráskódú] szoftverekhez " – ez pontatlannak tűnik, mivel valójában az LGPL és a statikus összekapcsolás jogilag lehetséges ( lásd ).
- Helyesnek tűnik a pozíciója. Lásd: gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic De ez ' további munkákat és extra dolgokat szállítani. Megúszhatja? Igen. El akarja tölteni az erőfeszítést? Esetleg nem.
Válasz
A tényleges ok nem technikai.
Emberek előfordulnak másnak lenni. Így vannak a választásaik is. Az egységesség nem emberi tulajdonság.
Hozzászólások
- Ezért jár minden ember a lábán? Nos, akinek legalább lába van …