Jedyne środowiska, w których mogę myśleć, to te wolnostojące (systemy operacyjne i programy wbudowane z jednym procesem). Oczywiście niektórzy programiści aktywnie unikają używania STL, ale jest to raczej decyzja projektowa niż brak wsparcia w środowisku. Uważam, że największą przeszkodą w tych ograniczonych środowiskach jest obsługa wyjątków (które rzucają wiele funkcji STL). Aby uzyskać wsparcie dla tych, należy przesłać ABI ABI i rozwinąć bibliotekę (aby odwijać stos i przechodzić do instrukcji catch). Nic nie stoi na przeszkodzie, aby wprowadzić te wymagane bity, ale jest to więcej zależności, które w oczywisty sposób powodują wzdęcia tylko dla podstawowego wsparcia dla czegoś takiego jak listy połączone. Aby przesłać ABI, patrz: the OSDEV wiki entry.
Istnieją inne zależności dla nowszych standardów C++ (C++ 11 i nowsze). Mogę sobie wyobrazić, że std::thread wymaga implementacji wątków, takich jak pthreads. std::chrono prawdopodobnie będzie potrzebował jakiejś pośredniej warstwy implementowanej między nim a czasem standardowej biblioteki C. Prawdopodobnie istnieje więcej funkcji STL, które wymagają obsługi systemu operacyjnego. Niezwykle ważna jest część STL, która jest częścią składową STL. Szablony często znacznie zwiększają ostateczny rozmiar binarny. Na przykład w przypadku std::list, std::list<MyClass1> i std::list<MyClass2> spowoduje specjalizację dwóch różnych pojemników. Kod będzie wyglądać bardzo podobnie, ale zostanie zduplikowany, aby obsługiwać ich typ elementu.Inne implementacje połączonych list często używają pustego wskaźnika do łączenia węzłów, a następnie w razie potrzeby przesyłają je do odpowiedniej klasy. W ten sposób istnieje jedna instancja klasy list dla ints, char *, MyClass1 itd. Zwiększony rozmiar binarny jest często niedopuszczalny w środowiskach osadzonych, , ale należy zauważyć, że staje się on również problemem, gdy LibA implementuje LibA :: LinkedList i LibB LibB :: LinkedList.
Jakość wdrożeń stała się obecnie mniejszym problemem. Pomocne może być również to, że GCC kieruje się do wielu architektur, dzięki czemu dostępne są nowe standardy kompilacji (jak wyżej, nadal trzeba portować niektóre funkcje STL). Najstarszym GCC, którego użyłem, było GCC v4.3 lub coś podobnego do wbudowanego urządzenia PowerPC. Zostało wydane w 2010 roku i miało pełne wsparcie STL.
Podsumowując, zapotrzebowanie na biblioteki z bardzo zogniskowanym zestawem funkcjonalnym może nadal być pomocne, ale moim zdaniem zmniejszają one liczbę platform, na które są projektowane, jeśli zapewniają funkcjonalności, które obejmują zachowanie zależne od systemu operacyjnego. W przypadku nieprzetworzonej struktury danych i obsługi algorytmów nie można popełnić błędu. Koniec końców, musisz trafić na pewien podzbiór platform. W C++ 11 wierzę, że celujesz w 99% używanych systemów operacyjnych na komputery/serwery i 99% wbudowanych urządzeń linuksowych. Jak podkreślono w innej odpowiedzi, Android był problemem, ale wydaje się, że uwydatnia się this page, aby uzyskać wszystkie bity wymagane do uzyskania naprawdę nowoczesnego środowiska.
Osoby projektujące środowiska osadzone czasami unikają STL. Istotne: http://stackoverflow.com/questions/2226252/embedded-c-to-use-stl-or-not – computerfreaker
@computerfreaker Prawda, ale martwię się bibliotekami, które mają na celu * wspieranie * systemów wbudowanych, ale nie ze szkodą dla wsparcia platform komputerowych lub podobnych. – JesseTG
Branża gier obawia się pogorszenia wydajności spowodowanej alokacją sterty. Często unikają użycia standardowej biblioteki. I mówimy tutaj o małych kosztach, takich jak przydział w współdzielonej wskazówce dla liczenia ref .. – Alex