Si che viene utilizzata, la cosa importante è comunque conoscere molto bene quello che si stà utilizzando e sapere quindi come funziona.
Esistono pure delle implementazioni specifiche, ad esempio la EASTL sviluppata da Electronic Arts.
Forse una domanda più interessante è capire quando è consigliato utilizzarla e quando è sconsigliato, in che contesti ecco.
Dipende dal gioco, dipende dove, dipende come.
Personalmene nelle società dove ho lavorato STL non era usato in codice di gioco.
Nei tool nessun problema ma in un gioco console dove la memoria e' una risorsa molto preziosa usare STL (senza nessuna modifica) non e' una bella idea.
Dare una mano ad STL ed usare custom allocators e' la via giusta. Anche se pero' alla fin fine se di STL si usano array, liste e map tanto vale implementarseli con un po' di classette template e usare nel corso degli anni una propria implementazione.
Implementazione che puo' essere molto piu' smart di funzioni pensate per essere generiche (chiaramente).
Nei miei oltre 20 anni di programmazione C++ ho sempre utilizzato STL, nei contesto dei game engine e senza custom allocators.
Condivido quello che dice Tiziano, specialmente la parte sui custom allocators e sull'implementazione ad hoc. In fondo nei giochi le classi più usate sono strighe, vettori, liste e map. Non sapevo che EA avesse prodotto una propria implementazione di STL.
Personalmente non ci vedo niente di male, la cosa più importante è usare l'algoritmo o il contenitore giusti nel modo giusto. C'è tanto che si può ottimizzare certo, e in tanti casi il guadagno è alto, ma in ogni caso fa parte del C++ ed è bene imparare le cose fondamentali. Se si hanno il tempo e le capacità, si possono re-implementare i contenitori più importanti (map, vector, string). La cosa fondamentale che consiglio però è di rispettare l'interfaccia standard in modo da poter usare i vostri container e algoritmi custom come tipi template e in modo da non disorientare chi non conosce la vostra interfaccia.
Una buona idea, una volta fatto questo, è estendere il tutto con container, metodi e funzioni in più, specifici a certi task. Bisogna ricordarsi che lo scopo di STL è la genericità. Se puoi scrivere codice più adattato a certe situazioni puoi fare assunzioni e quindi ottimizzazioni in più.
Ultima leggenda da sfatare, i template non sono più lenti delle classi "normali". Usare però un template con parametri diversi incrementa la dimensione del codice generato (tranne quando il compilatore riesce a inlinare tutto ovviamente).
A seconda del compilatore, certe funzioni spariscono del tutto, ad esempio non è sbagliato aspettarsi di trovare un memcpy al posto di std::copy
Il mio consiglio è di usare STL senza problemi e, se necessario/possibile, reimplementare i tuoi container alla fine, fare un replace all e tornare indietro per vedere se il nuovo codice può essere usato diversamente.
Per i compilatori Microsoft, ci sono delle macro particolari da dichiarare, pena l'utilizzo della versione debug dell'STL, da cui la leggenda che l'STL è troppo lenta per le applicazioni reali.
