So che in alcune aree (l'industria dei videogiochi, per esempio), l'uso di 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 ++?
Posso pensare ad un solo motivo valido ed è davvero raro: duro tempo reale. Molte cose nella libreria standard allocano memoria internamente e non sono abbastanza deterministiche per le applicazioni in tempo reale, quindi devono essere evitate. Queste applicazioni sono in genere piuttosto semplici, anche se richiedono un tempo sproporzionato per lo sviluppo a causa della revisione e dei test molto rigorosi.
Riesco a pensare a una ragione non valida, ma molto comune: gli sviluppatori che non comprendono la complessità computazionale, utilizzano in modo errato STL e quindi danno la colpa alla libreria.
STL è in genere più veloce in fase di esecuzione rispetto a soluzioni in stile C con richiami di callback o soluzioni basate su polimorfismo con metodi virtuali ( vedi anche questo keynote di Bjarne Stroustrup ). Tuttavia, quando lo sviluppatore non comprende le specifiche di complessità fornite e utilizza in modo errato la libreria creando qualcosa come vettori 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 una tale percezione, può vivere a lungo nell'organizzazione.
Ovviamente non puoi usare nulla che la piattaforma che stai bersagliando non supporti. Tuttavia, attualmente stiamo prendendo di mira quattro piattaforme mobili più comuni (Android, iOS, Bada e vecchia WinCE) e utilizziamo la libreria standard e alcune parti di Boost su tutti loro.
Gran parte della libreria standard non era supportata da Microsoft all'inizio di WinCE (gli iostreams IIRC venivano pubblicati solo con Visual Studio 2005), ma era possibile utilizzare STLport molto prima invece. E di solito puoi farlo compilare per qualsiasi cosa. Quindi chiamerei anche questo motivo invalido.
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 aumento già da molti anni. Se volessi abbandonarlo e utilizzare i miei strumenti personalizzati, la motivazione sarebbe:
C'è una grande ragione valida per non usare la libreria di template standard C ++: una delle piattaforme di destinazione non ha un'implementazione pienamente conforme (o nessuna implementazione di essa) e sai che non lo farà averne uno entro i prossimi anni.
Non conosco la complessità (efficienza dell'implementazione) ma sto usando estesamente contenitori e stringhe Qt invece di quelli standard e funzionano bene. Trovo anche l'implementazione Qt di set ed elenchi più facile da usare.
Quindi, può essere pratico abbandonare l'AWL se è possibile utilizzare un'altra libreria che si adatta alle proprie esigenze.
Patrick ha menzionato il motivo per non utilizzare l'intero STL, ovvero la tua piattaforma / le tue non ne ha uno.
Tutto sommato penso che alla domanda manchi il punto. Per lo più non è una decisione tutto o niente, ma uno di scegliere. Potresti decidere di andare con i contenitori e gli algoritmi, ma decidere di utilizzare qualcosa al di fuori di Std Lib per le stringhe e i / o.
Non è pratico, a meno che non ci sia un motivo pesante per farlo. Alcuni di questi motivi che posso pensare includono solo l'implementazione parziale o mancante di STL (o qualsiasi altra parte della libreria standard) o una limitazione delle risorse (memoria, velocità della CPU, archiviazione, ...) che è necessario aggirare rotolare i tuoi strumenti che aderiscono a ciò che devi realizzare.
Nel settore dei videogiochi la maggior parte degli studi (anche se in misura minore) hanno le loro librerie interne e implementazioni di molte parti di librerie standard che sono altamente personalizzate per la piattaforma di destinazione e in alcuni casi si rivolgono all'engnie o addirittura al 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 assemblaggi fatti a mano per una ragione. È molto importante ridurre al minimo tutti i tipi di impronte di risorse nel codice in modo che il gioco funzioni più velocemente, consentendo più contenuti nel mondo di gioco (o in un mondo più grande, ad esempio) che si spera producano un prodotto migliore.
"Ogni partita di successo inizia lanciando la tua implementazione della lista collegata."