Gli unici ambienti che posso pensare sono quelli indipendenti (sistema operativo e programmi incorporati a processo singolo). Certo, alcuni sviluppatori evitano attivamente di usare l'STL, ma questa è più una decisione progettuale che una mancanza di supporto nell'ambiente. Credo che il più grande ostacolo in questi ambienti vincolati sia il supporto alle eccezioni (che molte funzioni STL generano). Per ottenere supporto per questi è necessario effettuare il porting di un ABI C++ e una libreria di unwind (per eseguire lo stack unwinding e goto alla dichiarazione catch). Non c'è nulla che impedisca di implementare questi bit richiesti, ma sono più dipendenze che ovviamente risultano gonfiate solo per il supporto di base per qualcosa come le liste concatenate. Per portare l'ABI vedere the OSDEV wiki entry.
Esistono altre dipendenze per i nuovi standard C++ (da C++ 11 in poi). Posso immaginare che std::thread richieda un'implementazione di threading come pthreads. std::chrono probabilmente avrà bisogno di un livello intermedio implementato tra esso e il tempo di libreria standard C. Probabilmente ci sono più funzionalità STL che richiedono il supporto del sistema operativo.
La parte modello parte di STL è anche abbastanza importante. I modelli spesso aumentano notevolmente le dimensioni binarie finali. Nel caso di un std::list ad esempio, std::list<MyClass1> e std::list<MyClass2> si otterrà la specializzazione di due diversi contenitori. Il codice apparirà molto simile ma verrà duplicato per gestire in modo specifico il loro tipo di elemento.Altre implementazioni di liste collegate spesso usano un puntatore void per collegare i nodi e quindi lanciarlo nella classe appropriata quando richiesto. In questo modo, esiste una classe di lista istanziata per ints, char *, MyClass1, ecc. La maggiore dimensione binaria è spesso inaccettabile negli ambienti incorporati, ma si deve notare che diventa anche un problema quando LibA implementa LibA :: LinkedList e LibB LibB :: LinkedList.
Attualmente la qualità delle implementazioni è diventata meno problematica. È inoltre utile che GCC si rivolga a molte architetture in modo che i nuovi standard del compilatore siano disponibili (come sopra, è ancora necessario portare alcune funzionalità dell'STL). Il GCC più vecchio che ho usato era GCC v4.3 o qualcosa del genere per un dispositivo PowerPC incorporato. Questo è stato rilasciato nel 2010 e aveva pieno supporto STL.
In sintesi, la necessità di librerie con un set di funzionalità molto focalizzato può ancora aiutare, ma a mio parere riducono il numero di piattaforme a cui il progetto si rivolge se forniscono funzionalità che avvolgono il comportamento dipendente dal sistema operativo. Per la struttura dei dati grezzi e il supporto dell'algoritmo non puoi sbagliare. Alla fine, devi indirizzare alcuni sottoinsiemi di piattaforme. In C++ 11 credo che tu abbia come target il 99% dei sistemi operativi desktop/server usati e il 99% dei dispositivi Linux incorporati. Come evidenziato in un'altra risposta, Android è stato un problema, ma il this page sembra evidenziare per ottenere tutti i bit necessari per ottenere un ambiente davvero moderno.
Le persone che progettano ambienti embedded a volte evitano l'STL. Rilevante: http://stackoverflow.com/questions/2226252/embedded-c-to-use-stl-or-not – computerfreaker
@computerfreaker Vero, ma sono preoccupato per le librerie che mirano a * supportare * i sistemi incorporati, ma non a scapito delle piattaforme desktop di supporto o simili. – JesseTG
L'industria dei giochi è preoccupata per le regressioni di prestazioni causate dall'allocazione dell'heap. Evitano spesso l'utilizzo della libreria standard. E stiamo parlando di minuscoli overheads come quello dell'allocazione nel puntatore condiviso per il conteggio ref. – Alex