Miksi ' ei ole enemmän Qt: llä kirjoitettuja työpöytäsovelluksia? [suljettu]

En tarkoita, että tämä olisi oikea vastaus, mutta syitä teen en käytä henkilökohtaisesti Qt: tä. Siitä on paljon sanottavaa – nimittäin se, että sovellusliittymä toimii suurimman osan ajasta ja että se siltaa saumattomasti alustoja. Mutta en käytä Qt: tä, koska:

1. Joissakin tapauksissa se ei vain näytä natiivien ohjelmien ulkoasulta. Yksittäisen käyttöliittymän suunnittelu kaikille alustoille ei luonnostaan tule näyttämään oikealta, kun siirrät koneesta koneeseen erilaisista visuaalisista syistä. Esimerkiksi Mac-koneissa jaetut palkit ovat yleensä suhteellisen paksuja ja painikkeet ovat pieniä ja pyöristettyjä kuvakkeilla. Windows-koneissa jaetut palkit ovat tyypillisesti kapeita ja painikkeet ovat teksteisempiä ja neliömäisempiä. Se, että voit kirjoittaa yhden käyttöliittymän jokaiselle alustalle, ei tarkoita sitä, että sinun pitäisi kirjoittaa useimmille sovelluksille.
2. Qt ei ole vain linkittävä C ++ -kirjastojen joukko. Käytetty koontijärjestelmä edellyttää tiettyjen tiedostojen kääntämistä ylimääräisiksi lähdetiedostoiksi, mikä tekee rakennusprosessista paljon monimutkaisemman verrattuna useimpiin muihin kirjastoihin.
3. (2), C ++ IDE-tiedostojen ja työkalujen seurauksena voi ilmoittaa Qt-lausekkeista virheinä, koska ne eivät ymmärrä Qt: n erityispiirteitä. Tämä pakottaa melkein käyttämään QtCreatoria tai vain tekstimuokkainta, kuten vim.
4. Qt on suuri määrä lähdettä, jonka on oltava läsnä ja esiasennettu mihin tahansa koneeseen, jota käytät ennen kääntämistä. Tämä voi tehdä rakennusympäristön asettamisesta paljon ikävämmän.
5. Osille on myönnetty enimmäkseen LGPL-lisenssi, mikä tekee yhden binaarisen asennuksen käyttäminen on vaikeaa, kun julkaisu joudutaan julkaisemaan tiukemmalla tai vähemmän rajoittavalla lisenssillä.
6. Se tuottaa erittäin suuria käännettyjä binäärejä verrattuna vastaavasti kirjoitettuihin " plain ol ”natiivisovellukset " (lukuun ottamatta kirjoitussovelluksia kymmenen KDE: lle).

Kommentit

• @Dehumanizer: Siellä ' LGPL-lisenssi ja siellä ' s kaupallinen lisenssi. Kaupallinen lisenssi on lisenssinsaajan tuhansia dollareita, eikä se salli uudelleenjakoa jne. Avoimen lähdekoodin hankkeille, kuten BSD, MIT tai Boost, joissa tekijät eivät ole ' t ansaitsevat tonnia rahaa ja haluavat vapauttaa koodinsa liberaalin lisenssin nojalla, riippuvuus LGPL: stä on kohtuutonta, mutta kyseisillä kehittäjillä ei yleensä ole varaa kaupallisiin lisensseihin.
• # 6 on suurin syystä vältän sitä. Tarkoitan, en halua ' halua isoa, kömpelöä ohjelmaa ja en halua ' olla sidottu tiettyyn lisenssiin, mutta se ' todellakin puuttuu hyvästä, alkuperäisestä ulkonäöstä ja tunteesta, joka ' saisi minua.Viimeisimmät OSX- ja Windows-versiot ovat tehneet loistavan työn tekemällä natiivirajapintansa kauniiksi, nopeaksi ja toimivaksi, ja minä ' d mieluummin hyödyntän kaikkea työtä, jonka he ' olen jo tehnyt minulle; Huomaan, että monet ohjelmat, joissa ei ole alkuperäistä ulkoasua, tuntuvat minulle halvoilta ja hakkerilta (ei aina, mutta se vie minut hieman pois).
• Numerosi 6 olisi pitänyt olla numero 1. Tämän on kirjoittanut selvästi Qt: n suurin ongelma. Monissa tapauksissa se ei yksinkertaisesti käytä alkuperäisiä sovellusliittymiä. Pidän ohjelmistostani näyttävän alkuperäiseltä. Myös käyttäjät pitävät siitä. En ' ole koskaan nähnyt Qt: llä luotua Mac-sovellusta, joka näytti Mac-sovellukselta. Kummallakaan muulla Mac-käyttäjällä ei ole, ja he ' valitsevat tällaisen asian. Menetät kaiken edun siitä, että " ylität alustan ", jos ' uudelleen käyttää sitä vain Linux-sovellusten luomiseen, mikä on suunnilleen ainoa paikka, jossa se näyttää natiivilta, koska siellä ei ole mitään natiivia.
• lukuun ottamatta ' natiivin ' ulkoasua ei enää ole. Windows-sovellusten vanha johdonmukaisuus on nyt hölynpölyä kaikista WPF: n ja silverlightin tarjoamista ainutlaatuisista läiskistä, hehkuista ja animaatioista. Katsokaa Office- tai Windows 7 -käyttöjärjestelmää ' s Ohjauspaneeli vain nähdäksesi, kuinka jopa MS: n lipputuotteella on epäjohdonmukainen käyttöliittymä nykyään. Mac-käyttäjät – sinulla on hyvin piste siinä.
• @TrevorBoydSmith: Anteeksi, mutta olet ' väärässä. Qt on ainoa kehys, joka käyttää esikäsittelyä. Aika. Tarkista GNOME, FLTK, WX ja ystävät ja näytä minulle esikäsittelyvaihe. Et löydä ' sitä. Joissakin muissa kirjastoissa on erilaiset koontijärjestelmät, mutta päivän päätteeksi ne ovat C ++ -kirjastoja, jotka voi rakentaa mikä tahansa C ++-kääntäjä. Mitä tulee " raakaan win32: een, jota ei ole syissäni ", se on syissäni läsnä # 5 ja # 6.

Kuten ihmiset sanovat, jokainen työkalu sopii jokaiseen ongelmaan ja tilanteeseen …

Mutta jos olet C ++ -ohjelmoija, Qt on sinun kehyksesi. Ei kilpailijaa.

Kehitämme monimutkaisen lääketieteellisen kuvantamisen kaupallisen sovelluksen, ja Qt pitää kiinni.

En sano sitä ”miinukset”, joita ihmiset sanovat siitä, ovat vääriä, mutta minusta tuntuu, että he eivät ole kokeilleet Qt: tä pitkään aikaan (sen parantaminen jatkuvasti jokaisessa uudessa versiossa …) Ja enimmäkseen kaikki kommentoidut asiat eivät ole ongelma, jos huolehdit.

Käyttöliittymän alustan epäjohdonmukaisuus: vain, jos käytät käyttöliittymän widgettejä sellaisina kuin ne ovat, ilman mukautusta tai mukautettua taidetta.

Qt-esiprosessorin ylikuormitus : Vain, jos väärinkäytät signaalipaikkamekanismia tai QObject-perintöä, kun todellista tarvetta ei ole.

Muuten, Kirjoitamme sovelluksia edelleen C # .NET -versioon ja olemme olleet tekemällä sitä pitkään. Joten mielestäni minulla on kattava näkökulma.

Kuten sanoin, jokainen työkalu jokaiseen tilanteeseen,

mutta Qt on epäilemättä yhtenäinen ja hyödyllinen kehys.

Kommentit

• +1 Kiitos! Halusin vain kirjoittaa saman. Eniten hölynpölyä on " ei avoimen lähdekoodin / kaupallinen argumentti ". Hämmästyttävää, kuinka väärässä monet ihmiset ymmärtävät termin Open-Source. Qt oli avoimen lähdekoodin, koska käytän sitä (1.4). Ja sillä oli ennen kaikkein oikeudenmukaisin lisenssi: ansaitse rahaa Qt: llä – > maksaa.
• Voi ja en todellakaan halua ' t Huolehdi 10 Mt: n DLL-tiedostojen lisäämisestä sovellukseen, joka sisältää 50 Mt taidetta ja 200 Mt lisää video-oppaita ja tietoja 🙂
• Qt: lle tarvittava tila on nykyään halpaa.
• Tämä vastaa melkein kokemustani Qt: stä (widget-kehykset, en ole ' käyttänyt QML / QtQuickia tähän mennessä vakavaan asiaan). Se soveltuu kirjoittamaan suuria sovelluksia, joissa on monimutkaiset käyttöliittymävaatimukset. Kun olet oppinut sen, voit olla erittäin tuottava. Mainitut haitat (erillinen kääntövaihe mocingille, ui-tiedostoille jne.) Eivät ole ongelma, jos koontijärjestelmä on määritetty oikein. Voin suositella joko qmakea tai cmakea.
• Qt 5.8: sta jälkeenpäin on projekti nimeltä Qt Lite, joka minimoi erittäin Qt tarpeisiisi. tämä on kaupallinen ominaisuus;)

Kaikista asioista, joista en pidä Qt: ssä, se, että se ei pelaa hyvin malleilla, aiheuttaa minulle eniten vikoja. Et voi tehdä tätä:

template < typename T > struct templated_widget : QWidget { Q_OBJECT; public signals: void something_happened(T); }; 

Se ei myöskään toimi hyvin esiprosessorin kanssa. Et voi tehdä tätä:

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

Se sekoitettuna siihen, että kaiken, joka reagoi signaaliin, on oltava Q_OBJECT, tekee Qt: stä vaikean työskennellä Ihmiset, jotka ovat tottuneet Java- tai Python-tyyppiseen ohjelmointiin, ovat todennäköisesti oikeastaan paremmin.

Käytin itse asiassa paljon aikaa ja vaivaa tutkimalla ja suunnittelemalla tapaa saada takaisin tyyppiturva ja liittää Qt-signaali mihin tahansa funktoriobjektiin: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals-in-qt-step-1.html

Tällainen asia, jonka haluan tehdä, on jokapäiväinen C ++ -kehitys, jonka Qt-moc tekee melkein mahdottomaksi … joka itse on Täysin tarpeetonta nyt, jos se on koskaan ollut.

Suoraan sanottuna olen juuttunut siihen, koska jos haluat tehdä automaattisen käyttöliittymän testauksen, Qt on melkein ainoa peli kaupungissa, joka ei sisällä MFC: tä. ..joka on niin 1980 (se imee töitä siinä paskassa todella kovaa) .Jotkut saattavat sanoa WX, mutta sillä on vielä vakavampia ongelmia. GTKmm olisi ollut ensimmäinen valintani, mutta koska sen kaikki omistajat piirtävät eikä tee esteettömyyttä … sitä ei voida ohjata alan standardien mukaisilla testausohjelmistoilla. Qt on tarpeeksi kova tältä osin ( tuskin toimii, kun muokkaat esteettömyyslaajennusta).

Kommentit

• Kiinnostuksen kohteena, mitä pidät WX: n pääongelmina?
• @Tom – huono dokumentointi etenkin uusille jutuille. AUI-komponentit on tuskin dokumentoitu lainkaan, ja suuria osia puuttuu, mikä tekee siitä vaikean käyttää tuotantoympäristössä. Tapahtumaprosessin dokumentaatio on periaatteessa virheellinen ainakin polussa Win32. Vietetty paljon aikaa huutamalla tietokoneella, " Tämän pitäisi toimia !!! " ennen kuin pääset syvälle prosessointikoodiin saadaksesi selville, että se, mitä WX tekee, ei ' seuraa dokumentteja ja mitä tein, EI KOSKAAN toimi.
• Olin häiritsee myös omaisuuden ruudukon kirjaston hyväksyminen pääriville. Käytin kirjastoa, ja siinä ilmeni lukuisia perustavanlaatuisia suunnitteluvikoja sen lisäksi, että todellinen tiedon puute oli sen kirjoittaneen ohjelmoijan puolesta (kutsutaan esimerkiksi virtuaalitoiminnoksi rakentajissa). Se ja AUI: n huono tila osoittivat suuntausta heikompiin standardeihin. En myöskään ole ' staattisten tapahtumataulukoiden suuri fani, vaikka ainakin siellä ' on toinen tapa vastata tapahtumiin … toisin kuin MFC, joka WX on aivan liian paljon mielenkiintoista joka tapauksessa.
• Kiitos. Olen ' käyttänyt sitä vain vähän ja wxPython-sovellusliittymän kautta, missä se tuntui aika hyvältä. Ymmärrän, että se piilottaisi osan pahasta, mutta myös siitä, että en ole vain ' ollut mukana riittävän syvällisesti voidakseni kohdata vakavampia ongelmia. Jotain minun on oltava tietoinen.
• kaiken, mikä reagoi signaaliin, on oltava Q_OBJECT, Ei nykyään … Nyt staattiset toiminnot, toiminnot ja jopa lambda-toiminnot voivat vastaamaan signaaliin (voit käyttää toiminto-osoittimia aukkoina). No-QObject-luokilla voi olla myös jäsenpaikkoja, jos muodostat yhteyden std :: bind-toiminnolla muuntaa ilmentymän jäsen funktiosoittimeksi.

Yksi syy Qt: n käyttämättä jättämiseen on, että jos kirjoitat vain yhdelle arkkitehtuurille, kuten Windows, kannattaa ehkä käyttää C # /. NET: ää (tai Cocoa Macissa), koska ne käyttävät aina pystyä hyödyntämään käyttöjärjestelmän uusimpia kelloja ja vihellyksiä.

Jos kirjoitat alustojen välisiä sovelluksia, sinulla saattaa olla jo vahvasti jokin muu tekniikka, kuten Java (eli työskentelet ”Java Shopissa”). Teknologiavalintasi saattaa sanella kehitettävä ekosysteemi, kuten kielikohtaiset sovellusliittymät. Tällaisissa tapauksissa tekniikoiden määrän minimointi voi olla hyödyllistä.

Kolmas syy, jonka voin ajatella, on se, että Qt perustuu C ++: n ympärille ja C ++ on suhteellisen vaikea / vaarallinen kieli ohjelmoitavaksi Mielestäni se on ammattilaisten kieli. Jos tarvitset huippusuorituskyvyn ja pystyt olemaan huolellinen, C ++ on todennäköisesti edelleen kaupungin paras peli. Itse asiassa Qt korjaa paljon muistinhallintaongelmia, jos asetat asiat kuulumaan soveltamisalan ulkopuolelle. Qt itse tekee myös hyvää työtä eristämällä käyttäjän monista ikävistä C ++ -ongelmista. Jokaisella kielellä ja kehyksellä on hyvät ja huonot puolensa. Se on hyvin, hyvin monimutkainen asia, joka yleensä voidaan tiivistää ruokailijoiden usein nähdyllä lisäyksellä: nopeus, laatu ja hinta (mutta voit valita vain kaksi).

Vaikka sääntöjen mukaan minun pitäisi pitää keskittyen kysymykseen vastaamiseen, haluan kumota joitain Billy ONealin esille tuomia asioita, jotka mielestäni tekevät hyvää työtä tiivistämällä yleisesti mainitut syyt Qt: n käyttämättä jättämiseen:

1. Qt on todellakin C ++ – kirjasto / kehys / otsikkotiedostot. Se on täydennetty makroprosessorilla (moc), joka mahdollistaa signaalit ja paikat mm. Se muuntaa ylimääräisiä makrokomentoja (kuten Q_OBJECT) siten, että luokilla on itsetutkiskelu ja kaikenlaisia muita herkkuja, joiden saatat ajatella lisäävän Objective-C-toiminnallisuutta C ++: een. Jos tiedät tarpeeksi C ++: sta loukkaantua tästä puhtauden puutteesta, ts.olet ammattilainen, sitten 1) älä käytä Q_OBJECTia ja sen tapaa tai 2) ole kiitollinen siitä, että se tekee tämän, ja ohjelmoi hyvin rajoitettujen kulmien ympärille, jos tämä aiheuttaa ongelmia. Ihmisille, jotka sanovat ”Käytä Boostia signaaleille ja kolikkopelit! ”Sitten vastaisin, että vaihdat yhden” ongelman ”toiseen. Boost on valtava, ja sillä on omat yleisesti siteeratut ongelmansa, kuten huono dokumentaatio, kauhistuttava sovellusliittymä ja alustojen väliset kauhut (ajattele vanhoja kääntäjiä, kuten gcc 3.3 ja suuret rautakääntäjät, kuten AIX).

2. Editointitukea varten tämä seuraa myös kohdasta 1, olen jonkin verran samaa mieltä. Itse asiassa Qt Creator on IMHO paras graafinen C ++ -editori, jakso , vaikka et käyttäisikään Qt-tavaraa. Monet ammattimaiset ohjelmoijat käyttävät emac- ja vim-tiedostoja. Luulen myös, että Eclipse hoitaa ylimääräisen syntaksin. Siksi Qt-makroissa (Q_OBJECT) tai signaalien / aikavälien lisäyksissä ei ole ongelmia. Et todennäköisesti löydä näitä makroja Visual Studiosta, koska (myönnän) ne ovat C ++: n lisäyksiä. Mutta yleisesti ottaen C # /. NET-ihmiset eivät silti käytä Qt: tä, koska heillä on paljon toimintoja, jotka on peitetty omilla omilla tekniikoillaan.

3. Qt-lähteen koosta, niin kauan kuin se kokoaa yön yli, kuka välittää? Käännin Qt 4: n kaksoisydin MacBookissani ”alle yhdessä yössä”. Toivon varmasti, että tämä ei aja päätöstäsi käytä tai älä käytä tiettyä tekniikkaa. Jos tämä on todella ongelma, voit ladata Macin, Linuxin ja Windowsin valmiiksi käännetyt SDK: t Qt-verkkosivustolta.

4. Lisensointi on saatavana kolmessa eri vaihtoehdossa: 1) Oma lisenssi, jos haluat muokata Qt ITSELF etkä jakaa, tai piilottaa tosiasian, että joku käyttää Qt: tä eikä halua antaa attribuutiota (voi olla erittäin tärkeää tuotemerkinnän kannalta) ja kuva!) 2) GPL ja 3) LGPL. Kyllä, staattisessa linkityksessä on ongelmia (koko Qt: n vieminen binääriin) – mutta mielestäni se on enemmän, koska ei voi kurkistaa sisälle ja huomata, että olet u laulaa Qt (attribuutio!). Yritin ostaa oman lisenssin Digialta, ja he kertoivat minulle ”mitä teet, et todellakaan tarvitse sitä.” Vau. Yritykseltä, joka myy lisenssejä.

5. Binaarin / paketin koko johtuu siitä, että sinun on jaettava Qt-sisältö ihmisille, joilla sitä ei ole: Windowsilla on jo? Visual Studio -juttuja tai sinun on asennettava ajoaika. Macissa on jo valtava kaakao, ja se voidaan yhdistää dynaamisesti. Vaikka en jaa paljon, en ole koskaan löytänyt paljon ongelmaa ~ 50 megatavun staattisen tiedoston jakamisesta (jonka voin tehdä vielä pienemmäksi joidenkin binaaristen strippareiden / pakkausapuohjelmien, kuten UPX) kanssa. En vain ”t” tarpeeksi varovainen tämän tekemiseen, mutta jos kaistanleveys olisi koskaan ongelma, lisäisin UPX-vaiheen koontikomentosarjaan.

6. Mikä määrittelee ”Native Look and Feel?” Luulen, että ”useimmat” olisivat yhtä mieltä siitä, että Mac on lähinnä yhtenäistä ulkoasua. Mutta täällä istun katsomalla Safaria, iTunesia, Aperturea, Final Cut Pro: ta, Pagesia jne., Ja ne eivät näytä olevan samanlaisia huolimatta siitä, että ne ovat käyttöjärjestelmän toimittajan tekemiä. Mielestäni ”tuntuu” -kohta on merkityksellisempi: widgetin muotoilu, reagoivuus jne. Jos välität herkkyydestä, tässä on hyvä syy käyttää C ++: a Java: n tai jonkin muun erittäin dynaamisen kielen sijaan. (Myös tavoite C rokkaa, mutta yritän hajottaa myyttejä Qt: stä)

Yhteenvetona voidaan todeta, että kyseessä on monimutkainen asia. Mutta haluaisin huomauttaa, että mielestäni on vähemmän syitä ”Qt: n käyttämättä jättämiseen”, kuten voidaan ajatella myyttien ja vuosikymmenien vanhentuneiden tietojen perusteella.

Kommentit

• Mitä en saa ' ei saa, miksi nämä rajat ylittävät kirjastot eivät ole ' t yksinkertaisesti käärefunktioita tai jopa parempi; jos defs Cocoa-, Win32-, KDE / Gnome-toimintojen ympärillä varmistavat parhaan näköisen käyttöliittymän kaikilla sen ominaisuuksilla '.
• @MarcusJ Kääreen kirjoittaminen ympärille yksi työkalupakki on selvästi ei-triviaali, älä välitä 4: stä tai useammasta – mutta jos luulet sen ' olevan niin helppoa, ' olet tervetullut yrittää. Ajatuksesta, jonka mukaan tämä voidaan saavuttaa käyttämällä vain ehdollista esikäsittelyä … sinun täytyy vitsailla, eikö?
• @MarcusJ libui on täsmälleen niin (tosin ilman KDE-tukea).
• Haluan lisätä, että voit nyt käyttää Qt / QML: ää .NET: n kanssa. Sinun ' ei tarvitse koskettaa C ++. github.com/qmlnet/qmlnet PS: Olen ' kirjoittaja.

Osa siitä on lisensointia. Katso osa lisenssihistoriasta kohdasta https://en.wikipedia.org/wiki/Qt_(software) #Licensing . Vuoteen 2000 asti ihmiset, jotka välittivät voimakkaasti avoimesta lähdekoodista, eivät käyttäneet Qt: tä. Aika. (Tämä oli itse asiassa alkuperäinen motivaatio Gnomen kehittämiselle.) Vuoteen 2005 asti ihmiset, jotka halusivat pystyä julkaisemaan ilmaisia ohjelmistoja Windowsille, eivät käyttäneet Qt: tä.Jopa tuon päivän jälkeen ihmisillä, jotka halusivat ilmaisia ohjelmistoja muuhun kuin GPL: ään, ei yksinkertaisesti ollut mahdollisuutta käyttää Qt: tä. Siksi mikään kyseisiä päivämääriä vanhempi ilmainen ohjelmistoprojekti ei voinut käyttää Qt: tä. Ja tietysti omaa koodia kirjoittavien ihmisten oli maksettava etuoikeus.

Lisäksi ei ole kuin olisi olemassa pulaa muista vaihtoehdoista. Esimerkiksi WxWidgetit , GTK + ja Tk ovat kaikki avoimen lähdekoodin, alustojen välisiä työkalupaketteja.

Lisäksi Windows oli pitkään niin hallitseva työpöydällä, että suuri osa ohjelmistoista oli sisältöä, jota voitiin käyttää vain Windowsissa. Jos asennat Microsoft-työkaluketjun, on helpompaa käyttää vain Microsoftin omistamia juttuja kuin huolehtia mistään muusta, ja monet ohjelmoijat tekivät juuri sen.

Kommentit

• @btilly: GTK + on alustojen välinen. Esimerkiksi Pidgin IM -asiakas on kirjoitettu GTK +: een.
• Ok, se on kuitenkin mahdollista ' jotenkin ' ajaa Windowsissa 🙂
• Asenna vain GIMP Windowsiin ja katso.
• Joo, ja GIMP toimii hyvin Windowsissa, mutta se ei todellakaan ole ' ei sovi Windows 7 -käyttöliittymän ulkoasuun &.
• Pidgin on todennäköisesti parempi esimerkki GTK: sta Windowsissa. Se ei tee ' mitään hienoa, mutta se sopii ja on ehkä ollut vähintään 10 vuotta?

Olen samaa mieltä melkein kaikista edellä mainituista syistä, mutta monet täällä olevat ihmiset ovat sanoneet, etteivät käytä Qt: tä sen aiheuttamien ylimääräisten yleiskustannusten takia. Olen eri mieltä tämän vuoksi, koska kaikilla nykypäivän yleisimmillä kielillä (Java, C # ja Python) on itsessään melko vähän yleiskustannuksia.

Toiseksi Qt tekee C ++: lla ohjelmoinnista niin helppoa ja suoraviivaista, että se korvaa ylimääräisiä resursseja, joita se käyttää. Olen törmännyt moniin Qt: ssä kirjoitettuihin konsolisovelluksiin tavallisen C ++: n sijaan, koska ne ovat helposti kirjoitettavissa.

Sanoisin, että Qt: n tuottavuus on suurempi kuin C / C ++: n, mutta vähemmän kuin Pythonin kaltaiset kielet.

Kommentit

• Luulen, että se on ' kaikki suhteessa yksilön ' kokemukseen, koska osaan koodata OK C ++ 14: ssä, mutta joka kerta kun katson jotain Qt-koodia, minun on karsistettava kovasti tunnistaakseni sen samaksi kieleksi … joten en todellakaan usko sitä ' s yksimielinen tuottavuuden tehostaja, jonka ' tarkoitat täällä.
• @underscore_d tietysti, jos tiedät C ++: n hyvin ja et ' t Qt, et ole tuottavampi jälkimmäisen kanssa. Mutta kun opit tuntemaan sekä C ++: n että Qt: n, kehys tekee todella paljon asioita helpompaa ja nopeampaa toteuttaa (C ++ 11, 14 jne. Täyttävät aukon, mutta eivät vielä täysin).

Tämä ei todellakaan ole yritys aloittaa liekkisota, halusin vain käsitellä joitain kohtia.

Todennäköinen syy siihen, että Qt: tä ei käytetä laajemmin, on se, että sen C ++ ja vähemmän ihmisiä käyttää c ++: ta työpöytäsovelluksissa.

Qt ei ole C ++ -kirjasto. Se vaatii erillisen kääntövaiheen, mikä tekee rakennusprosessista paljon monimutkaisemman verrattuna useimpiin muihin kirjastoihin.

vs-addin for visual studio tekee tämän automaattisesti, samoin kuin Qt: n oma komentorivin valmistusprosessi. MFC: n valintaikkunoiden rakentamiseen käytetty resurssikääntäjä on myös erillinen vaihe, mutta se on edelleen c ++.

Qt on suuri määrä lähdettä, joka on oltava läsnä ja esiasennettuna kaikilla koneilla, joita käytät ennen kääntämistä. Tämä voi tehdä rakennusympäristön asettamisesta paljon ikävämmän.

Binaarinen tiedosto on ladattavissa jokainen visuaalisen studion versio ja lähdekehitys on yksi komento. En näe, että SDK: n lähdekoko on niin paljon käsiteltävänä päivänä. Visual Studio asentaa nyt kaikki C ++ lib-tiedostot sen sijaan, että annat sinun valita ja valita, minkä seurauksena kääntäjän asennuskoko on> 1 Gt.

Se ” Ne ovat saatavana vain LGPL-käyttöjärjestelmässä, mikä vaikeuttaa yhden binaarisen käyttöönoton käyttöä, kun julkaisu on vapautettava tiukemmalla tai vähemmän rajoittavalla lisenssillä.

LGPL koskee vain lib: tä, se ei vaikuta koodiin. Kyllä, se tarkoittaa, että sinun on lähetettävä DLL-tiedostot pikemminkin kuin yksi binääri (ellei maksa), mutta maailmassa, jossa sinun on ladattava Java-ajoaika tai .Net-päivitys pienelle hyödyllisyydelle, tämä ei ole niin iso juttu. ”on myös vähemmän ongelma alustoilla, joilla on yksi ABI, jotta muut Qt-sovellukset voivat jakaa lib-tiedostoja.

Joissakin tapauksissa se vain ei” t näyttävät alkuperäisiltä ohjelmilta.Yhden käyttöliittymän suunnittelu kaikille alustoille ei luonnostaan näytä oikealta, kun se siirretään koneelta koneelle, erilaisista visuaalisista syistä.

Sen oletetaan olevan minun on myönnettävä, että teen enimmäkseen teknisiä sovelluksia, jotta käyttäjät eivät ole liian huolissasi tyylistä. Varsinkin Windowsissa uusi tyyli, että kaikki tyyli itsessään on älypuhelinwidget, tarkoittaa, että standardia on joka tapauksessa vähemmän.

Kommentit

• Melko monet suuret ohjelmistoyritykset rakentavat kaupallisia sovelluksia C ++: ssa, mutta en ' ole tietoinen monista QT: tä käyttävistä. Joten vaikka ymmärrän, että muut kuin C ++ -kehittäjät saattavat välttää QT: tä, näyttää siltä, että QT: n välttämiseksi on muita syitä, vaikka kirjoitatkin C ++ -sovellusta. Itse asiassa ei todellakaan ole ' t mitään alustojen välistä kieltä ja käyttöliittymän työkalupakettia, josta en voi ' löytää vikaa. Näyttää siltä, että alustojen välinen kehitys on VAIN KOVAA ja että sen tekeminen hyvin ei ole koskaan helppoa tai ilmaista, ja että QT: n antama lupaus (Kirjoita GUI kerran ja käytä sitä uudelleen kaikkialla) ei ole ' t tarpeeksi.
• Useimmat työpöydän C ++ -ohjelmistot ovat joko MFC: ssä, koska ne alkoivat 20 vuotta sitten tai käyttävät 20 vuotta sitten aloitettua sisäistä työkalupakettia MFC: n välttämiseksi (esim. MS-Office tai Autocad). Epäilen, että kirjoitetaan paljon C ++ / CLR-muodossa WPF: n kanssa. Mutta jopa ilman alustojen välisiä näkökohtia Qt on mielestäni paras (tai huonoin!) Työpöydän työkalupakki. Kuten useimmat ihmiset, olemme siirtymässä kohti webby-käyttöliittymää (mahdollisesti QtQuick / QML: ssä) ja C ++ -palvelimen taustatietoja – jotka todennäköisesti käyttävät Qt-signaaleja / -paikkoja, mutta ei GUI: ta.
• Olen samaa mieltä. Vähiten pahin. Ja jopa vain Windows-sovelluksissa ' viritin pikemminkin QT-ongelmia kuin MFC-ongelmia.
• @WarrenP – kyllä en ' missaa etsimästä koodiprojektia kaikista MFC: stä puuttuvista asioista. Mutta MSFT: n ' uuden löytämän rakkauden mukaan natiivikoodi – he eivät ole ' t tehneet paljon helpottaakseen gui: n kirjoittamista.

Syy on yksinkertainen: sillä ei ole hyviä siteitä kaikkiin valtavirran kieliin eikä se ole maagisesti aina sopiva käsillä olevaan työhön.

Käytä työhön sopivaa työkalua. Jos kirjoitan yksinkertaisen komentorivisovelluksen, miksi paisuttaisin sen Qt: llä vain sen takia?

Yleisempänä vastauksena (jonka voin antaa, koska minulla on merkitystä tässä ), jotkut ohjelmoijat eivät yksinkertaisesti ole koskaan antaneet sille mennä ja päättäneet käyttää sitä. Joissakin tapauksissa ei ole mitään muuta syytä kuin ohjelmoija ei ole koskaan löytänyt tarvetta sille ja tutkinut sitä.

Kommentit

• Mutta Qt tarjoaa kyky kirjoittaa vain konsolisovellus. Eikö ' ole sitä?
• @Dehumanizer: Minulla ei ole aavistustakaan. Mutta miksi käytän sitä pieneen apuvälineeseen? Mitä hyötyä siitä olisi minulle, kun voin triviaalisesti kirjoittaa hakemuksen vain tavallisella C ++: lla? Näyttää siltä, että ' et etsit syytä käyttää kirjastoa , mikä on taaksepäin tapa ohjelmoida.
• @Dehumanizer: As Sanoin, että ' lähestyy taaksepäin. Kun tarvitset kirjastoa, ' tiedät, ja sitten voit mennä kokeilemaan muutamia ja nähdä, mikä sopii tarpeisiisi paremmin. Yrittää kerätä mielipiteitä kirjastosta kun sinulla ei ole käyttötapaa , on tyhmä ' s asiointia.
• " Jos ' m kirjoitan yksinkertaisen komentorivisovelluksen, miksi minä paisun sen Qt: n kanssa vain sen vuoksi " Qt: hen on kirjoitettu ainakin yksi erittäin kuuluisa ei-gui-työkalu – Doxygen 🙂
• Esimerkiksi @Dehumanizer kun sinun on käsiteltävä tiedostoja, xml, unicode, json, regexp, concurency, tietokannat jne., jne., erittäin nopeasti ja älä ' halua ladata, hyväksyä, ylläpitää tusinaa 3. juhlakirjastot.

Qt: n kaltaiset kehykset ovat sopivia, kun olet enemmän kiinnostunut tuotteesi ulkoasusta sama kaikilla alustoilla kuin tuotteesi, joka näyttää oikealta kaikilla alustoilla. Nykyään tällaiset sovellukset siirtyvät yhä useammin verkkopohjaiseen tekniikkaan.

omasta mielestäni C ++ -ohjelmoinnin oppiminen on yksinkertaisempaa kuin putoaminen muille kielille, jotka kätkevät heidän monimutkaisuutensa, ja ohjelmoija ei tiedä mitä todella tapahtuu taustalla. Qt toisaalta lisää joitain etuja verrattuna C ++: een, jotta se olisi korkeampi kuin alkuperäinen C ++. Siksi Qt C ++ on loistava kehys niille, jotka haluavat kehittää matalan tason tai korkean tason tehtäviä samalla tavalla. C ++ on (joidenkin käytäntöjen mukaan) monimutkainen ja yksinkertainen kieli. Monimutkainen niille, jotka haluavat olla haastamatta sitä, yksinkertainen niille, jotka pitävät siitä.Älä jätä sitä monimutkaisuuteen!

Olen samaa mieltä siitä, että Qt on mukava kehys työskennellä. Silti minulla on useita asioita:

1. Se on kirjoitettu C ++: lla, joka on todella matalan tason kieli. Pelkästään se, että se on C ++, tekee jokaisesta Qt-ohjelmoijasta huomattavasti vähemmän tuottavan verrattuna muilla kielillä kirjoitettuihin kehyksiin. Tärkein naudanlihani C ++: lla GUI-kehityskielenä on, että siinä ei ole automaattisen muistinhallinnan käsitystä, mikä tekee kehitysprosessista paljon alttiimman virheille. Se ei ole itsetarkka, mikä tekee virheenkorjauksesta paljon vaikeampaa. Suurimmalla osalla muista tärkeistä graafisen käyttöliittymän työkalupaketeista on jonkinlainen käsitys automaattisesta muistinhallinnasta ja itsetarkastuksesta.
2. Jokainen alustojen välinen työkalupakki kärsii ongelmasta, että se vain pystyy toteuttamaan kaikkien tuettujen alustojen vähiten yhteisen nimittäjän. Tämä ja erilaiset käyttöliittymän ohjeet eri alustoilla kyseenalaistavat paljon alustojen välisten käyttöliittymien toivottavuuden kokonaisuudessaan.
3. Qt keskittyy hyvin paljon kaikkien käyttöliittymiesi koodaukseen. Vaikka voit käyttää QtDesigneria rakentaaksesi joitain käyttöliittymän osia, se puuttuu vakavasti verrattuna esimerkiksi (Cocoa / Obj-C) Interface Builderiin tai .Net-työkaluihin.
4. Vaikka Qt sisältääkin paljon matalan tason sovellustoimintoja, sitä ei voida verrata siihen, että kehys on räätälöity tietylle alustalle. Natiivien käyttöjärjestelmien kirjastot sekä Windowsille että OSX: lle ovat huomattavasti tehokkaampia kuin Qt: n toteutukset. (Ajattele äänikehyksiä, matalan tason tiedostojärjestelmien käyttöoikeuksia jne.)

Tästä huolimatta rakastan käyttää PyQt nopeaan prototyyppien muodostamiseen tai sisäisiin sovelluksiin. Pythonin käyttäminen kaiken koodauksen suorittamiseen lievittää C ++: n huolenaiheita ja tekee Qt: stä todella miellyttävän paikan.