Contenitori STL o Qt?

Quali sono i pro ei contro di utilizzare contenitori Qt ( QMap, QVector, ecc) sul loro STL equivalente?

Vedo un motivo per preferire Qt:

• I contenitori Qt possono essere passati ad altre parti di Qt. Ad esempio, possono essere utilizzati per popolare a QVariante quindi a QSettings(con qualche limitazione, tuttavia, vengono accettati solo QListe QMap/ le QHashcui chiavi sono stringhe).

Ce n'è un altro?

Modifica : supponendo che l'applicazione si basi già su Qt.

Ho iniziato utilizzando std::(w)stringesclusivamente i contenitori STL e convertendoli in / dagli equivalenti Qt, ma sono già passato a QStringe trovo che utilizzo sempre più i contenitori Qt.

Quando si tratta di stringhe, QStringoffre funzionalità molto più complete rispetto a std::basic_stringed è completamente compatibile con Unicode. Offre anche un'efficace implementazione delle COW , su cui sono arrivato a fare molto affidamento.

I contenitori di Qt:

• offre la stessa implementazione COW di in QString, che è estremamente utile quando si tratta di usare la foreachmacro di Qt (che fa una copia) e quando si usano meta-tipi o segnali e slot.
• può usare iteratori in stile STL o iteratori in stile Java
• sono streaming con QDataStream
• sono ampiamente utilizzati nell'API di Qt
• avere un'implementazione stabile su tutti i sistemi operativi. Un'implementazione STL deve obbedire allo standard C ++, ma per il resto è libera di fare ciò che gli pare (vedi la std::stringcontroversia sulle COW). Alcune implementazioni STL sono particolarmente dannose.
• fornire hash, che non sono disponibili se non si utilizza TR1

La QTL ha una filosofia diversa dalla STL, che è ben riassunta da J. Blanchette: "Mentre i contenitori di STL sono ottimizzati per la velocità pura, le classi di contenitori di Qt sono state attentamente progettate per offrire praticità, utilizzo minimo della memoria ed espansione minima del codice".
Il link sopra fornisce ulteriori dettagli sull'implementazione del QTL e quali ottimizzazioni vengono utilizzate.

Questa è una domanda a cui è difficile rispondere. Può davvero ridursi a una discussione filosofica / soggettiva.

Detto ciò...

Consiglio la regola "Quando a Roma ... fai come fanno i romani"

Ciò significa che se sei nella terra di Qt, codifica come fanno i Qt'ians. Questo non è solo per problemi di leggibilità / coerenza. Considera cosa succede se memorizzi tutto in un contenitore stl, quindi devi passare tutti quei dati a una funzione Qt. Vuoi davvero gestire un sacco di codice che copia le cose dentro / fuori dai contenitori Qt. Il tuo codice è già fortemente dipendente da Qt, quindi non è come se lo rendessi più "standard" usando i contenitori stl. E qual è il punto di un contenitore se ogni volta che vuoi usarlo per qualcosa di utile, devi copiarlo nel corrispondente contenitore Qt?

I contenitori Qt sono più limitati di quelli STL. Alcuni esempi di dove quelli STL sono superiori (tutti questi che ho colpito in passato):

• STL è standardizzato, non cambia con ogni versione di Qt (Qt 2 aveva QList(basato sul puntatore) e QValueList(basato sul valore); Qt 3 aveva QPtrListe QValueList; Qt 4 ora ha QList, e non è affatto come QPtrList o QValueList ).
  Anche se finisci per usare i contenitori Qt, usa il sottoinsieme API compatibile con STL (cioè push_back(), no append(); front()no)first() , ...) per evitare porting ancora una volta venire Qt 5. In entrambi Qt2-> 3 e Qt3-> 4 transizioni, i cambiamenti nei contenitori Qt erano tra quelli che richiedevano la maggior quantità di abbandono del codice.
• Tutti i contenitori bidirezionali STL hanno rbegin() / rend(), rendendo l'iterazione inversa simmetrica rispetto all'iterazione in avanti. Non tutti i contenitori Qt li hanno (quelli associativi no), quindi l'iterazione inversa è inutilmente complicata.
• I contenitori STL possono insert()variare da diversi tipi di iteratori, ma compatibilistd::copy() molto meno necessario.
• I contenitori STL hanno un Allocatorargomento template, rendendo la gestione della memoria personalizzata banale (typedef richiesto), rispetto a Qt (fork di QLineEditrichiesto per s/QString/secqstring/). EDIT 20171220 : questo interrompe Qt dei progressi nella progettazione degli allocatori a seguito di C ++ 11 e C ++ 17, cfr. ad esempio il discorso di John Lakos ( parte 2 ).
• Non esiste un Qt equivalente a std::deque.
• std::listha splice(). Ogni volta che mi trovo a usare std::list, è perché ne ho bisogno splice().
• std::stack, std::queueAggregare adeguatamente la loro sottostante contenitore, e non ereditano, come QStack, QQueuefare.
• QSetè come std::unordered_set, non come std::set.
• QListè semplicemente strano .

Molti di questi argomenti potrebbero essere risolti abbastanza facilmente in Qt , ma al momento la libreria di container in Qt sembra sperimentare una mancanza di attenzione allo sviluppo.

EDIT 20150106 : Dopo aver trascorso un po 'di tempo a provare a fornire il supporto C ++ 11 alle classi container Qt 5, ho deciso che non valeva il lavoro. Se osservi il lavoro che viene messo nelle implementazioni della libreria standard C ++, è abbastanza chiaro che le classi Qt non raggiungeranno mai. Abbiamo rilasciato Qt 5.4 ora eQVector ancora non sposta elementi sulle riallocazioni, non haemplace_back()o valore-push_back()... Di recente abbiamo anche rifiutato unQOptionalmodello di classe, aspettandostd::optionalinvece. Allo stesso modo perstd::unique_ptr. Spero che questa tendenza continui.

Analizziamo queste affermazioni in fenomeni misurabili reali:

• Più leggero: i contenitori Qt utilizzano meno memoria dei contenitori STL
• Più sicuro: i contenitori Qt hanno meno opportunità di essere utilizzati in modo improprio
• Più facile: i contenitori Qt presentano meno di un carico intellettuale

Più facile

L'affermazione fatta in questo contesto è che l'iterazione in stile java è in qualche modo "più semplice" rispetto allo stile STL, e quindi Qt è più facile da usare grazie a questa interfaccia aggiuntiva.

Stile Java:

QListIterator<QString> i(list);
while (i.hasNext())
    qDebug() << i.next();

Stile STL:

QList<QString>::iterator i;
for (i = list.begin(); i != list.end(); ++i)
    qDebug << *i;

Lo stile iteratore Java ha il vantaggio di essere un po 'più piccolo e più pulito. Il problema è che questo non è più lo stile STL.

Stile C ++ 11 STL

for( auto i = list.begin(); i != list.end(); ++i)
    qDebug << *i;

o

C ++ 11 foreach style

for (QString i : list)
    qDebug << i;

Che è così drasticamente semplice che non c'è motivo di usare altro (a meno che non si supporti C ++ 11).

Il mio preferito, tuttavia, è:

BOOST_FOREACH(QString i, list)
{
    qDebug << i;
}

Quindi, come possiamo vedere, questa interfaccia non ci guadagna nulla se non un'interfaccia aggiuntiva, in aggiunta a un'interfaccia già elegante, snella e moderna. Aggiunta di un livello di astrazione non necessario oltre a un'interfaccia già stabile e utilizzabile? Non è la mia idea di "più facile".

Inoltre, le interfacce Qt foreach e java aggiungono sovraccarico; copiano la struttura e forniscono un livello non necessario di indiretta. Questo potrebbe non sembrare molto, ma perché aggiungere un livello di sovraccarico per fornire un'interfaccia non molto più semplice? Java ha questa interfaccia perché java non ha un sovraccarico dell'operatore; C ++ lo fa.

Safer

La giustificazione fornita da Qt è il problema della condivisione implicita, che non è né implicito né un problema. Implica tuttavia la condivisione.

QVector<int> a, b;
a.resize(100000); // make a big vector filled with 0.

QVector<int>::iterator i = a.begin();
// WRONG way of using the iterator i:
b = a;
/*
Now we should be careful with iterator i since it will point to shared data
If we do *i = 4 then we would change the shared instance (both vectors)
The behavior differs from STL containers. Avoid doing such things in Qt.
*/

Innanzitutto, questo non è implicito; stai assegnando esplicitamente un vettore a un altro. Le specifiche dell'iteratore STL indicano chiaramente che gli iteratori appartengono al contenitore, quindi abbiamo chiaramente introdotto un contenitore condiviso tra b e a. Secondo, questo non è un problema; fintanto che verranno seguite tutte le regole delle specifiche dell'iteratore, nulla andrà per il verso sbagliato. L'unica volta che qualcosa va storto è qui:

b.clear(); // Now the iterator i is completely invalid.

Qt lo specifica come se significasse qualcosa, come un problema sorge de novo da questo scenario. Non L'iteratore è invalidato e, proprio come tutto ciò a cui è possibile accedere da più aree disgiunte, è così che funziona. In effetti, ciò accadrà facilmente con gli iteratori in stile Java in Qt, grazie alla sua forte dipendenza dalla condivisione implicita, che è un antipattern come documentato qui e in molte altre aree . Sembra particolarmente strano che questa "ottimizzazione" venga messa in atto in un framework sempre più orientato al multithreading, ma questo è marketing per te.

Accendino

Questo è un po 'più complicato. L'uso delle strategie di condivisione e crescita implicite di copia e scrittura rende molto difficile fornire effettivamente garanzie sulla quantità di memoria che il contenitore utilizzerà in un determinato momento. Questo è diverso dall'STL, che offre forti garanzie algoritmiche.

Sappiamo che il limite minimo di spazio sprecato per un vettore è la radice quadrata della lunghezza del vettore , ma sembra che non ci sia modo di implementarlo in Qt; le varie "ottimizzazioni" che supportano impedirebbero questa importantissima funzione di risparmio di spazio. L'STL non richiede questa funzionalità (e la maggior parte utilizza una crescita raddoppiata, che è più dispendiosa), ma è importante notare che potresti almeno implementare questa funzionalità, se necessario.

Lo stesso vale per gli elenchi doppiamente collegati, che potrebbero utilizzare il collegamento XOr per ridurre drasticamente lo spazio utilizzato. Ancora una volta, questo è impossibile con Qt, a causa dei suoi requisiti di crescita e COW.

Le COW possono davvero rendere qualcosa di più leggero, ma anche i contenitori intrusivi, come supportati da boost , e Qt li usavano frequentemente nelle versioni precedenti, ma non vengono più utilizzati tanto perché sono difficili da usare, non sicuri e impongono un onere sul programmatore. COW è una soluzione molto meno invadente, ma poco attraente per le ragioni sopra esposte.

Non vi è alcun motivo per cui non è possibile utilizzare contenitori STL con lo stesso costo di memoria o meno dei contenitori di Qt, con l'ulteriore vantaggio di sapere effettivamente quanta memoria si sprecherà in un determinato momento. Sfortunatamente, è impossibile confrontare i due nell'uso della memoria non elaborata, poiché tali benchmark mostrerebbero risultati incredibilmente diversi in diversi casi d'uso, che è esattamente il tipo di problema che l'STL è stato progettato per correggere.

In conclusione

Evita l'uso dei contenitori Qt quando possibile, senza imporre un costo di copia, e usa l'iterazione del tipo STL (forse attraverso un wrapper o la nuova sintassi), quando possibile.

Contenitori STL:

• Avere garanzie di prestazione
• Può essere utilizzato negli algoritmi STL che hanno anche garanzie di prestazioni
• Può essere sfruttato da librerie C ++ di terze parti come Boost
• Sono standard e probabilmente sopravvivranno a soluzioni proprietarie
• Incoraggiare la programmazione generica di algoritmi e strutture di dati. Se si scrivono nuovi algoritmi e strutture di dati conformi a STL, è possibile sfruttare ciò che STL fornisce già gratuitamente.

I contenitori Qt usano un linguaggio copia-scrittura.

Uno dei problemi principali è che l'API di Qt si aspetta che tu fornisca dati nei contenitori di Qt, quindi puoi anche semplicemente usare i contenitori di Qt piuttosto che trasformarti avanti e indietro tra i due.

Inoltre, se stai già utilizzando i contenitori Qt, potrebbe essere leggermente più ottimale usarli esclusivamente, poiché non dovresti includere i file di intestazione STL e potenzialmente collegarti nelle librerie STL. Tuttavia, a seconda della tua toolchain, ciò può accadere comunque. Solo dal punto di vista del design, la coerenza è generalmente una buona cosa.

Se i dati con cui stai lavorando vengono utilizzati principalmente per guidare l'interfaccia utente basata su Qt, utilizza sicuramente i contenitori Qt.

Se i dati vengono principalmente utilizzati internamente nell'app e non è probabile che tu porti via Qt, quindi escludendo i problemi di prestazioni, usa i contenitori Qt perché renderà più facili da gestire i bit di dati che vanno all'interfaccia utente.

Se i dati vengono utilizzati principalmente in combinazione con altre librerie che conoscono solo i contenitori STL, utilizzare i contenitori STL. Se hai questa situazione, sei nei guai, qualunque cosa accada, perché eseguirai molto il porting avanti e indietro tra i tipi di container, qualunque cosa tu faccia.

Oltre alla differenza COW, i contenitori STL sono molto più ampiamente supportati su una varietà di piattaforme. Qt è abbastanza portatile se si limita il proprio lavoro alle piattaforme "mainstream", ma l'STL è disponibile anche su molte altre piattaforme più oscure (ad esempio, i DSP di Texas Instruments).

Poiché lo STL è standard anziché controllato da una singola società, ci sono, in generale, più programmatori che possono facilmente leggere, comprendere e modificare il codice STL e più risorse (libri, forum online, conferenze, ecc.) Per supportarli in facendo questo che ci sono per Qt. Questo non vuol dire che si dovrebbe rifuggire da Qt solo per questo motivo; solo che, a parità di tutte le altre cose, dovresti impostare di default l'STL, ma ovviamente tutte le cose raramente sono uguali, quindi dovrai decidere nel tuo contesto quale ha più senso.

Per quanto riguarda la risposta di AlexKR: le prestazioni STL sono garantite entro certi limiti, ma una determinata implementazione può fare uso di dettagli dipendenti dalla piattaforma per accelerare il loro STL. Quindi, in tal senso, potresti ottenere risultati diversi su piattaforme diverse, ma non sarà mai più lento della garanzia esplicita (bug del modulo).

I miei cinque centesimi: i contenitori Qt dovrebbero funzionare in modo simile su piattaforme diverse. Mentre i contenitori STL dipendono dall'implementazione STL. Potresti ottenere risultati di prestazione diversi.

EDIT: non sto dicendo che STL è "più lento", ma indico gli effetti di vari dettagli di implementazione.
Per favore, controlla questo e poi forse questo .
E non è un vero problema di STL. Ovviamente, se si ha una differenza significativa nelle prestazioni, allora c'è un problema nel codice che utilizza STL.

Immagino che dipenda dal modo in cui usi Qt. Se lo usi su tutto il tuo prodotto, probabilmente ha senso usare i contenitori Qt. Se lo si contiene solo (ad esempio) nella parte dell'interfaccia utente, potrebbe essere preferibile utilizzare contenitori standard C ++.

Sono dell'opinione che STL sia un eccellente software, tuttavia se devo fare un po 'di programmazione relativa a KDE o Qt, Qt è la strada da percorrere. Inoltre dipende dal compilatore che stai utilizzando, con GCC STL funziona abbastanza bene, tuttavia se devi usare diciamo SUN Studio CC, molto probabilmente STL ti causerà mal di testa a causa del compilatore e non dell'STL in sé. In quel caso, dal momento che il compilatore ti farà male alla testa, basta usare Qt per salvarti il ​​disturbo. Solo i miei 2 centesimi ...

C'è una (a volte) grande limitazione in QVector. Può allocare solo byte int di memoria (si noti che il limite è in byte e non in numero di elementi). Ciò implica che il tentativo di allocare blocchi di memoria contigui di dimensioni superiori a ~ 2 GB con un QVector porterà a un arresto anomalo. Questo succede con Qt 4 e 5. std :: vector non ha questa limitazione.

Il motivo principale per utilizzare i contenitori STL per me è se è necessario un allocatore personalizzato per riutilizzare la memoria in contenitori molto grandi. Supponiamo ad esempio di avere una QMap che memorizza 1000000 voci (coppie chiave / valore). In Qt ciò implica esattamente 1000000 milioni di allocazioni (new chiamate), non importa quale. In STL è sempre possibile creare un allocatore personalizzato che alloca internamente tutta quella memoria in una sola volta e assegnarla a ciascuna voce quando viene popolata la mappa.

Il mio consiglio è di utilizzare i contenitori STL durante la scrittura di algoritmi critici per le prestazioni nella logica aziendale e di convertirli nuovamente in contenitori Qt quando i risultati sono pronti per essere visualizzati dai controlli e dai moduli dell'interfaccia utente, se necessario.