QT-C ++ vs C ++ generico e STL [chiuso]

Non mi asterrò dall'usare Qt solo per queste ragioni. Non è necessario utilizzare tutte le classi di utilità di Qt; per quelli che sostituiscono lo STL, sarai al massimo costretto a usare QString e, possibilmente, QStringList. Inoltre, di solito c'è molto di più per un programma rispetto alla GUI. È sempre possibile utilizzare esclusivamente C ++ generico per il resto del programma e utilizzare Qt solo per la GUI.

Secondo me, lavorare con STL è più di capire quali strutture di dati sottostanti vengono utilizzate e le loro complessità, e di conseguenza a che ora si dovrebbe usare ogni contenitore. E quando si parla di programmazione in C ++, si tratta soprattutto di sapere come usare l'essenziale < algoritmo > intestazione, che dovrebbe funzionare anche sui contenitori di Qt, poiché sono compatibili con STL.

Non vedo molti danni nell'usare tutte quelle estensioni fornite da Qt, purché tu sappia (o abbiate almeno un'idea generale di) come sono implementate internamente. Assicurati di sapere che cose come Q_OBJECT, SIGNAL (), SLOT (), foreach (), non sono magiche, ma macro che si espandono in dichiarazioni C ++ valide. Ad esempio, non è poi così complicato capire come vengono implementate le classi implicitamente condivise e le relazioni genitore-figlio che fanno sentire Qt più simile a Java. Puoi sempre provare a ricreare alcune funzionalità in un progetto separato solo per vedere se potresti farlo con il C ++ generico, e quindi non sentirti male per usarle in Qt.

Inoltre, dai un'occhiata alle librerie Boost. Forniscono utility aggiuntive che la libreria standard C ++ non offre e sono un ottimo modo per avvicinarsi un po 'al C ++ generico, poiché essenzialmente seguono le stesse convenzioni del C ++ generico. Alcune librerie hanno classi di modelli abbastanza complesse, e semplicemente provare a capire come funzionano è, di per sé, un buon studio in C ++. Boost ha molte utilità che non possono essere trovate in Qt e altre che implementano concetti uguali o simili a quelli di alcune classi di Qt e possono essere utilizzate al loro posto.

Se colpisci il mercato del lavoro lavorando con C ++, è probabile che lavorerai con Qt o un altro framework che, analogamente ad esso, avrà le sue classi di utilità che tentano di rendere il C ++ più semplice.

Sono d'accordo con la maggior parte degli elogi di Qt, ma la domanda era Qual è la migliore struttura GUI da usare che permetta / richieda il maggior uso del C ++ generico e dello STL? Sotto questo aspetto Qt è un po 'schizofrenico: duplica i contenitori STL e gli algoritmi con le proprie torsioni. Fornisce anche contenitori, che sono diversi da STL. L'interoperabilità tra Qt e STL non è sempre scorrevole. In alcuni casi sono necessarie alcune chiamate di funzione per passare da std::string a QString e viceversa.

wxWidgets ha un'opzione per STL build, che utilizza esclusivamente contenitori STL - non esiste un universo parallelo con sostituzioni autocostruite come nel caso di Qt. Compilano anche con un compilatore C ++ standard senza bisogno di estensioni non standard. È una struttura GUI di qualità che vale la pena considerare.

Puoi anche dare un'occhiata a gtkmm, che è un wrapper C ++ attorno a GTK +. È più vicino a soddisfare il tuo primo requisito di Qt.

Non mi preoccuperei troppo di non usare specifici librerie STL come std :: string o std :: iostream o std :: vector. Gli equivalenti QT hanno un sapore diverso, ma non sono così lontani da creare problemi.

La differenza più idiomatica a mio parere sembra essere lo stile di programmazione pesante sull'uso di new per l'allocazione. Mentre per un programma QT questo potrebbe andar bene per la parte Gui, la virtù di C ++ e RAII è che puoi effettivamente tenere molti dati sullo stack invece dell'heap. Quando si passa alla scrittura di codice non-GUI dovresti ricordarlo.