È pratico abbandonare STL nello sviluppo di C ++? [chiuso]

So che in alcune aree (industria dei giochi, ad esempio), STL non è raccomandato. Quindi la mia domanda è: è davvero una buona pratica non usare STL in alcuni casi? In tal caso, quali sono i principali motivi per non utilizzare il moderno STL del C ++?

• Mi viene in mente solo un motivo valido ed è davvero raro: tempo reale difficile. Molte cose nella libreria standard allocano la memoria internamente e questo non è abbastanza deterministico per le applicazioni in tempo reale, quindi devono essere evitati. Queste applicazioni sono in genere piuttosto semplici, anche se richiedono tempi sproporzionati per lo sviluppo a causa di test e revisioni molto rigorosi.

• Mi viene in mente una ragione non valida, ma molto comune: gli sviluppatori che non comprendono la complessità computazionale, usano in modo improprio STL e quindi danno la colpa alla libreria.

  L'STL è solitamente più veloce in fase di runtime rispetto alle soluzioni in stile C con puntatori di callback o soluzioni basate sul polimorfismo con metodi virtuali ( vedi anche questo keynote di Bjarne Stroustrup ). Tuttavia, quando lo sviluppatore non capisce le specifiche di complessità fornite e abusa della libreria creando qualcosa come vettore di vettori di alcuni oggetti complessi (in C ++ 11 non è più un problema, però!), Causa un problema di prestazioni e si difende con "vedi, i vettori sono piuttosto lenti", può causare la percezione che la libreria standard sia lenta. E una volta che i manager ottengono tale percezione, possono vivere molto a lungo nell'organizzazione.

• Ovviamente non puoi usare nulla che la piattaforma che stai prendendo di mira non supporta. Tuttavia, al momento stiamo prendendo di mira quattro piattaforme mobili più comuni (Android, iOS, Bada e WinCE precedente) e utilizziamo la libreria standard e alcune parti di Boost su tutte.

  Gran parte della libreria standard non era supportata da Microsoft all'inizio di WinCE (gli iostreams IIRC uscivano solo con Visual Studio 2005), ma era possibile utilizzare STLport molto prima. E di solito puoi farlo compilare per qualsiasi cosa. Quindi definirei invalido anche questo motivo.

  Inoltre, per molto tempo non è "STL", ma ANSI C ++ Standard Library. È definito dallo stesso documento standard che definisce la lingua stessa. Tutto ciò che non lo supporta non merita davvero di essere chiamato C ++.

Sto usando STL e boost già da molti anni. Se volessi abbandonarlo e utilizzare i miei strumenti personalizzati, la motivazione sarebbe:

1. Riduzione del tempo di compilazione (75%). Solo l'inclusione di iostreams può aggiungere 1 milione di righe di codice al tuo modulo. Sì, le intestazioni precompilate aiutano molto, ma rallentano ancora molto la compilazione nei grandi progetti. A lungo termine, fa perdere molto tempo a chiunque ci lavori.
2. Prestazione. (25%) STL è scritto per funzionare in generale, ma è possibile ottimizzare le strutture affinché funzionino esattamente come si desidera. Ad esempio, potresti avere una struttura dati con milioni di stringhe brevi. Potrebbe essere molto più veloce utilizzare la classe di stringhe personalizzata basata sul principio di boost :: small_vector (piccolo vettore locale statico di dati, allocazione dinamica solo per stringhe più grandi), questo tipo di modifiche può far funzionare le sezioni critiche del codice molte volte più velocemente.

Esiste un motivo valido per non utilizzare la libreria di modelli standard C ++: una delle tue piattaforme di destinazione non ha un'implementazione pienamente conforme (o nessuna implementazione) e sai che non ne otterrà una entro i prossimi anni.

Non conosco la complessità (efficienza dell'implementazione) ma sto usando ampiamente contenitori e stringhe Qt invece di quelli standard e funzionano bene. Trovo anche l'implementazione Qt di set ed elenchi più facile da usare.

Pertanto, può essere pratico abbandonare l'STL se è possibile utilizzare un'altra libreria adatta alle proprie esigenze.

Patrick ha menzionato il motivo per non utilizzare l'intero STL, vale a dire che le piattaforme non ne hanno una.

Tutto sommato, penso che alla questione manchi il punto. Per lo più non è una decisione tutto o niente, ma una scelta. Potresti decidere di utilizzare i contenitori e gli algoritmi, ma decidere di utilizzare qualcosa al di fuori dello Std Lib per stringhe e I / O.

Non è pratico, a meno che non ci sia una ragione pesante per farlo. Alcuni di questi motivi che posso pensare includono solo un'implementazione parziale o mancante di STL (o qualsiasi altra parte della libreria standard) o una limitazione delle risorse (memoria, velocità della CPU, memoria, ...) che devi aggirare rotolare i tuoi strumenti che aderiscono a ciò che devi realizzare.

Nell'industria dei videogiochi la maggior parte degli studi (anche più piccoli in una certa misura) hanno le loro librerie interne e le implementazioni di molte parti di librerie standard che sono altamente personalizzate per la piattaforma di destinazione e in alcuni casi il target di gioco o persino il gioco stesso. In poche parole, quando si sviluppa un gioco per console, l'hardware è molto limitato dagli standard odierni. Ci sono migliaia e migliaia di linee di assemblaggio artigianale per un motivo. È molto importante ridurre al minimo tutti i tipi di impronte di risorse nel tuo codice in modo che il gioco funzioni più velocemente, il che consente più contenuti nel mondo di gioco (o un mondo più grande, ad esempio) che si spera si traduca in un prodotto migliore.

"Ogni gioco di successo inizia con l'implementazione della tua lista di link collegati."